Kubernetes 1.29: 解耦污点管理器与节点生命周期控制器

作者: Yuan Chen (Apple), Andrea Tosatto (Apple)

译者: Allen Zhang

这篇博客讨论在 Kubernetes 1.29 中基于污点的 Pod 驱逐处理的新特性。

背景

在 Kubernetes 1.29 中引入了一项改进，以加强节点上基于污点的 Pod 驱逐处理。 本文将讨论对节点生命周期控制器（node-lifecycle-controller）所做的更改，以分离职责并提高代码的整体可维护性。

变动摘要

节点生命周期控制器之前组合了两个独立的功能：

  • 基于节点的条件为节点新增了一组预定义的污点 NoExecute。
  • 对有 NoExecute 污点的 Pod 执行驱逐操作。

在 Kubernetes 1.29 版本中，基于污点的驱逐实现已经从节点生命周期控制器中移出， 成为一个名为污点驱逐控制器（taint-eviction-controller）的独立组件。 旨在拆分代码，提高代码的可维护性，并方便未来对这两个组件进行扩展。

以下新指标可以帮助你监控基于污点的 Pod 驱逐：

  • pod_deletion_duration_seconds 表示当 Pod 的污点被激活直到这个 Pod 被污点驱逐控制器删除的延迟时间。
  • pod_deletions_total 表示自从污点驱逐控制器启动以来驱逐的 Pod 总数。

如何使用这个新特性？

名为 SeparateTaintEvictionController 的特性门控已被添加。该特性在 Kubernetes 1.29 Beta 版本中默认开启。 详情请参阅特性门控。

当这项特性启用时，用户可以通过在 kube-controller-manager 通过手动设置 --controllers=-taint-eviction-controller 的方式来禁用基于污点的驱逐功能。

如果想禁用该特性并在节点生命周期中使用旧版本污点管理器，用户可以通过设置 SeparateTaintEvictionController=false 来禁用。

使用案例

该特性将允许集群管理员扩展、增强默认的污点驱逐控制器，并且可以使用自定义的实现方式替换默认的污点驱逐控制器以满足不同的需要。 例如：更好地支持在本地磁盘的持久卷中的有状态工作负载。

FAQ

该特性是否会改变现有的基于污点的 Pod 驱逐行为？

不会，基于污点的 Pod 驱逐行为保持不变。如果特性门控 SeparateTaintEvictionController 被关闭， 将继续使用之前的节点生命周期管理器中的污点管理器。

启用/使用此特性是否会导致现有 SLI/SLO 中任何操作的用时增加？

不会。

启用/使用此特性是否会导致资源利用量（如 CPU、内存、磁盘、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)