Kubernetes v1.37 引入节点生命周期条件

技术要点

Kubernetes v1.37 版本的核心新增内容是引入了五个预定义的节点生命周期条件（Node Lifecycle Conditions）。这些条件旨在为节点状态提供一个共享的、Kubernetes 官方定义的描述方式。

具体新增的五个条件及其报告内容如下：

• DrainInProgress：报告节点正在根据管理员选择的排空标准进行主动排空。
• Drained：报告节点已达到管理员选择的排空标准。
• MaintenancePlanned：报告节点预计在未来将 undergo 变更。
• MaintenanceInProgress：报告节点正在 actively undergo 维护。
• GracefulNodeShutdownInProgress：报告节点的优雅节点关闭（Graceful Node Shutdown）正在进行中。

每个条件都使用 status 字段来报告观察结果：True 表示当前观察到该生命周期状态；False 表示当前未观察到；Unknown 表示 Kubernetes 无法确定该状态是否活跃。reason 字段提供稳定的、机器可读的原因，message 字段可提供额外的人类可读细节。

在 v1.37 中，这些条件名称被保留为已知的 NodeConditionType 常量，并引入了 Alpha 特性的 NodeLifecycleConditions feature gate。该 feature gate 默认处于禁用状态。在 v1.37 中，此 gate 实际上是一个无操作（no-op）：它不限制谁可以设置这些条件，也没有核心组件读取它们。它的存在是为了让未来计划的行为——消耗这些条件的控制器——在到达时可以 opt-in。

对于此发布版本，管理员或管理员授权的控制器负责设置和清除生命周期条件。在这个第一个发布版本中，没有核心工作负载控制器会根据这些条件改变其行为。

原理与背景

此次引入节点生命周期条件的根本动机，是为了解决 Kubernetes 集群中节点状态描述分散、缺乏共享上下文的问题。

在 v1.37 之前，Kubernetes 已有多种方式描述节点上发生的情况，例如就绪状态（Readiness）、污点（taints）、Pod 状态、标签（labels）、注解（annotations）以及提供商特定的 API。然而，这些方式各自只暴露了部分信息。缺少一个统一的、Kubernetes 拥有的方式来明确表达节点正在排空（draining）、进行维护（maintenance）或执行优雅关闭（Graceful Node Shutdown）。

这种分散的信号导致集群中的不同组件（如 kubelet、节点生命周期控制器、工作负载控制器、调度器、自动伸缩器、存储操作符和外部维护系统）需要各自从间接信号中重建对节点状态的理解。例如，一个污点可以影响调度或驱逐，但它并不能证明排空正在进行或管理员的排空标准已满足。一个 NotReady 的节点并不能解释原因是意外故障、优雅关闭还是计划维护。

缺乏共享的生命周期上下文，可能导致独立正确的组件做出冲突决策。例如，在优雅关闭期间，DaemonSet 控制器可能会替换 kubelet 有意终止的 Pod；Job 控制器可能会在一个管理员正在移除的节点上无限期等待终端 Pod 阶段；存储操作符可能在排空已经开始后才得知维护信息。

新的节点生命周期条件为这种缺失的上下文提供了一个稳定的位置，作为增强节点生命周期管理更大努力的一部分。它创建了一个 Kubernetes 拥有的地方来发布维护上下文，为未来核心控制器（如 DaemonSet 控制器）利用此信息进行 rollout 排序、可用性计费和状态报告奠定了基础。

落地建议

对于集群管理员和运维工程师，可以基于 v1.37 的新特性采取以下通用做法：

1. 明确使用场景：将新的节点生命周期条件用作状态报告通道，而非操作执行机制。现有的 Kubernetes 机制，如 kubectl cordon、kubectl drain、污点和工作负载特定控制，仍用于改变调度或驱逐行为。
2. 自动化集成：维护自动化脚本或控制器可以在计划维护窗口时设置 MaintenancePlanned 条件，在维护开始时设置为 MaintenanceInProgress。排空自动化可以在开始驱逐 Pod 时设置 DrainInProgress，在满足排空标准后设置为 Drained。
3. 条件设置规范：
   • 当生命周期状态活跃时，使用 True 设置条件。
   • 当状态不再活跃时，将条件设置为 False 或移除它。
   • 使用稳定的 reason 值和清晰的 message，以便人和自动化都能理解条件变化的原因。
4. 避免冲突写入：集群管理员应决定哪个组件拥有每个生命周期条件，以避免冲突写入。例如，可以规定维护控制器负责 Maintenance* 条件，排空控制器负责 Drain* 条件。
5. 渐进式采用：由于 NodeLifecycleConditions feature gate 在 v1.37 中默认关闭且为 no-op，管理员可以开始发布这些条件以提供操作清晰度，而无需立即启用 feature gate。未来当核心组件开始消费这些条件时，再考虑启用该 gate。
6. 关注生态发展：节点生命周期是一个跨领域的问题。关注 Kubernetes SIG Node 和 SIG Apps 的相关工作（如 KEP-5683），了解未来如何利用这些条件改进优雅关闭、排空和维护等场景。