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

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

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

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

在 深度解析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。

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

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

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

成本优化（Operate）从容易到难分为3个阶段：

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

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

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

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

最近在研究descheduler，主要为了解决node节点出现cpu热点问题，即节点的cpu使用率相差特别大，而节点的request分布均匀。我们知道kube-scheduler将pod调度到节点上，而descheduler将pod进行移除，让workload控制器重新生成pod，并再次触发pod调度流程将pod调度到节点。通过这个方法达到pod重调度和节点的平衡目的。

社区的descheduler项目为了解决以下场景：

1. 部分节点利用率过高，需要平衡节点的利用率
2. 在pod调度之后，节点的label、taint不满足pod的pod/node affinity，需要将pod移动到符合的节点
3. 新节点加入集群，需要平衡节点的利用率
4. pod处于failed状态但是没有清理
5. 同一个workload的pod集中在同一节点上

descheduler利用插件机制来扩展它的能力，插件分为Balance（节点平衡）和Deschedule（pod重调度）两个类型。

上篇文章讲了有意思的mirror pod的移除流程，这篇文章来研究static pod的移除流程。

static pod可以来自文件和HTTP服务，而且static pod只在kubelet内部可见，mirror pod是static pod的镜像让外部组件能够捕获static状态。

上篇文章讲了删除mirror pod并不会删除static pod，执行static pod的删除需要通过删除--pod-manifest-path目录下的文件或让--manifest-url的http server返回response body里移除这个pod。