Kubernetes 1.29:将 taint-manager 与 node-lifecycle-controller 解耦
这篇博客讨论了 Kubernetes 1.29 中的一项新功能,以改进基于污点的 Pod 驱逐的处理。
背景
在 Kubernetes 1.29 中,引入了一项改进,以增强节点上基于污点的 Pod 驱逐处理。这篇博客讨论了对 node-lifecycle-controller 所做的更改,以分离其职责并提高整体代码的可维护性。
更改摘要
node-lifecycle-controller 之前结合了两个独立的功能
- 根据节点的状况,向节点添加一组预定义的
NoExecute
污点。 - 在
NoExecute
污点上执行 Pod 驱逐。
在 Kubernetes 1.29 版本中,基于污点的驱逐实现已从 node-lifecycle-controller 中移出,放入一个名为 taint-eviction-controller 的单独且独立的组件中。这种分离旨在解耦代码,增强代码可维护性,并促进未来对任一组件的扩展。
作为更改的一部分,引入了其他指标来帮助您监视基于污点的 Pod 驱逐
pod_deletion_duration_seconds
衡量 Pod 的污点效应被激活到通过 taint-eviction-controller 删除之间的时间延迟。pod_deletions_total
报告自启动以来 taint-eviction-controller 删除的 Pod 总数。
如何使用新功能?
添加了一个新的功能门 SeparateTaintEvictionController
。该功能在 Kubernetes 1.29 中默认以 Beta 状态启用。请参考功能门文档。
启用此功能后,用户可以选择通过在 kube-controller-manager 中设置 --controllers=-taint-eviction-controller
来禁用基于污点的驱逐。
要禁用新功能并在 node-lifecylecycle-controller 中使用旧的 taint-manager,用户可以设置功能门 SeparateTaintEvictionController=false
。
用例
这项新功能将允许集群管理员扩展和增强默认的 taint-eviction-controller,甚至用自定义实现替换默认的 taint-eviction-controller,以满足不同的需求。一个例子是更好地支持在本地磁盘上使用 PersistentVolume 的有状态工作负载。
常见问题解答
此功能是否会更改基于污点的 Pod 驱逐的现有行为?
不会,基于污点的 Pod 驱逐行为保持不变。如果功能门 SeparateTaintEvictionController
被关闭,将继续使用带有 taint-manager 的旧版 node-lifecycle-controller。
启用/使用此功能是否会导致现有 SLI/SLO 所涵盖的任何操作所用时间增加?
不会。
启用/使用此功能是否会导致资源使用(CPU、RAM、磁盘、IO 等)增加?
运行单独的 taint-eviction-controller
所导致的资源使用增加将可以忽略不计。
了解更多
有关更多详细信息,请参考 KEP。
致谢
与任何 Kubernetes 功能一样,从编写 KEP 到实现新控制器以及审查 KEP 和代码,多个社区成员做出了贡献。特别感谢
- Aldo Culquicondor (@alculquicondor)
- Maciej Szulik (@soltysh)
- Filip Křepinský (@atiratree)
- Han Kang (@logicalhan)
- Wei Huang (@Huang-Wei)
- Sergey Kanzhelevi (@SergeyKanzhelev)
- Ravi Gudimetla (@ravisantoshgudimetla)
- Deep Debroy (@ddebroy)