路在脚下--不打工独立生存

三月份被裁之后,找工作不是很顺利。这让我有时间停下来思考接下来的路该怎么走,之前工作时候想法是先扩大自己的技术影响力,觉得自己技术也不错还能靠技术生存,同时在工作时候思考如何独立生存。经过这几个月从刷题、背八股文到投简历面试,证明无法继续靠打工来生存了,需要考虑其他路。

很早之前我以前的同事告诉我要学会独立生存,直到2020年末才真正开始考虑如何独立生存。第一步行动就是写博客,宣传自己。而现在开始下一步,实践摸索。

Koordinator Descheduler的MigrationController插件:确保驱逐后Pod成功调度

由于调度器和descheduler是两个独立工作的组件,两个组件之间并没有任何通讯和协商机制,在descheduler执行pod驱逐后,由驱逐生成pod的调度和非驱逐原因生成的pod的调度(后面简称正常的pod)会存在资源抢占的问题。比如正常的pod和驱逐后生成的新pod需要相同的资源,且集群的剩余可以调度的资源紧张(或者资源碎片),且正常的pod在驱逐后生成的新pod之前调度,会出现pod驱逐后新生成的pod重新调度到原先的节点或无法调度的问题。

MigrationController插件通过Reservation资源跟koordinator scheduler进行通信,让koordinator scheduler进行资源预留,然后再执行驱逐pod,来解决上面这个问题。

仲裁机制是一种干预pod的驱逐过程的机制,它在 v1.4.0 版本中引入。它解决了应用变更维护过程中临时暂停应用pod的驱逐,比如deployment滚动更新的过程中同时descheduler执行pod的驱逐,会对这个应用的稳定性产生影响,甚至没有一个ready的pod。仲裁机制提供了一个方式,在驱逐pod时候增加一道审批的流程,能够进行批准、拒绝等操作。

Windows 11跳过激活后,如何联网不自动激活Windows

最近我在买新的生产力工具,我想全方位评测一下新机器,但是windows 11初次开机后强制要求联网,联网会自动激活windows。虽然使用oobe方法(按Shift+F10FN+Shfit+F10 快捷键,在弹出命令行输入oobe\bypassnro,然后回车,自动重启,重启后,在联网界面会有“我没有Internet连接”选项点击此选项即可跳过联网)可以跳过联网步骤,但是进入系统后依然不能联网,这样就不能愉快的体验新的机器。

在网上没有搜到任何能够联网不激活的有效方法。于是我想自己研究一下,看能不能解决这个问题。

问题总结为”如何在联网情况下,不自动激活windows”,这样就能享受七天无理由退货。

国内的电商平台都有七天无理由退货的服务,但是笔记本里windows激活后和厂家自带软件激活(即已激活/更改/卸载的机器)且没有质量问题是不支持七天无理由退货。如果不联网的情况下,验机就非常的麻烦,需要使用移动设备或者没有互联网的无线传输文件。

koordinator Descheduler的LowNodeLoad插件助力节点平衡与应用稳定性的提升

深度解析descheduler的highNodeUtilization和lowNodeUtilization插件的原理 中研究了kubernetes社区里的descheduler的两个Node utilization插件,而这两个插件用都存在使用request来计算节点的资源使用情况,无法解决节点过热(小部分节点的资源使用高于其他大部分节点)问题。而这篇文章介绍koordinator descheduler的LowNodeLoad插件就是解决这个问题的,它基于节点实际的资源使用值来区分高水位节点、正常节点和低水位节点。

koordinator descheduler兼容社区的descheduler,同时增加了两个插件MigrationController和LowNodeLoad(在Koordinator v1.1中增加的)。

koordinator的LowNodeLoad插件类似lowNodeUtilization插件,都是将高水位节点的pod驱逐到低水位节点上。跟lowNodeUtilization不同的是,它是基于节点的真实负载对节点进行分类,它能够真正解决节点资源过热问题。

MigrationController插件提供资源保留和仲裁机制(拦截机制),通过这两个能力保障descheduler驱逐pod时候的应用稳定性。

这篇文章只介绍LowNodeLoad插件,MigrationController插件后面文章会介绍,本文基于Koordinator v1.4版本和Descheduler v0.28.1

Kubernetes成本优化最佳实践

在降本增效的大环境下,Finops的理念非常符合这个需求。FinOps是一种结合财务、技术和业务的最佳实践方法,旨在优化云计算资源的成本、性能和价值。FinOps的目标是通过合理的资源管理和财务决策,使组织能够更好地理解、控制和优化云计算成本。

FinOps的阶段分为成本观测(Inform)、 成本分析(Recommend)和 成本优化(Operate)。

一般企业内部的成本平台会包含成本观测和成本分析,它将IT成本(云厂商的账单)按照服务类型维度和业务部门维度进行分析。

成本优化(Operate)从容易到难分为3个阶段:

  1. 处理空闲的机器和服务,合理选择服务和资源,包括适当的实例类型和计费模型(定价模型)和储值计划(Reserved Capacity)和套餐折扣。
  2. 应用服务缩容降配、减少冗余资源(三活变双活–“Twitter就是这么干”,双活变冷备,双活变单活、人员优化)
  3. 技术手段优化(提高利用率)

本文关注的技术优化成本阶段,在kubernets下的云原生降本策略。

为什么被驱逐evicted pod未被删除以及如何清理

最近我发现了一个出乎意料的现象:当deployment的replicas缩减为0时,被kubelet驱逐的pod并没有被自动删除。通常情况下,当deployment有副本数时,被驱逐的pod不会被删除,这与我的预期相符。然而,在replicas为0的情况下,驱逐的pod没有被删除,这让我感到意外。这篇文章来讨论evicted pod移除相关的话题。

2023年总结

2023总体感觉自己还在困境中不断的挣扎,但是慢慢看到了一丝希望。就像步履蹒跚的往上爬,抬头看到了坡顶。自己感觉在云原生领域小有积累,可以慢慢的输出自己的知识和思考,同时提升自己的技术影响力。