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)