Kubernetes v1.37：引入节点生命周期状况
内容提要
Kubernetes v1.37 引入五个标准节点状况：DrainInProgress、Drained、MaintenancePlanned、MaintenanceInProgress、GracefulNodeShutdownInProgress，用于统一描述节点排空、维护和优雅关闭状态。该功能为 Alpha 且默认关闭，暂不影响核心组件行为，由管理员或授权控制器设置。它提供共享状态信号，提升运维可见性，避免组件因信息不足而冲突，未来将支持 DaemonSet 滚动更新等场景。
延伸解读
Alpha 阶段的定位与启用建议
NodeLifecycleConditions 特性门控在 v1.37 中为 Alpha 且默认关闭，但当前版本下它实际上不限制谁可以设置这些状况，也没有核心组件读取它们。因此，管理员无需启用该门控即可开始发布这些状况，用于向集群用户传达维护和排空信息。门控的存在主要是为未来版本中消费这些状况的控制器预留启用入口。
与现有节点信号的分工
这些生命周期状况并不替代就绪状态、污点、Pod 状态等现有信号，而是补充它们无法回答的问题。例如，污点可以影响调度或驱逐，但不能表明排空正在进行或管理员设定的排空标准已满足；NotReady 也无法区分意外故障、优雅关闭还是计划维护。推荐做法是用生命周期状况报告状态，而通过 kubectl cordon、kubectl drain、污点等现有机制实际改变调度或驱逐行为。
避免组件间冲突的共享上下文
在缺乏共享生命周期上下文时，各自正确的组件可能做出冲突决策。例如，DaemonSet 控制器可能替换 kubelet 在优雅关闭期间有意终止的 Pod，Job 控制器可能在管理员正在移除的节点上无限等待终态 Pod，存储运维可能直到排空开始后才得知维护。新状况为节点提供了一个稳定位置来发布缺失的上下文，有助于减少这类冲突。
未来应用场景与当前限制
文章以 DaemonSet 滚动更新为例说明长期存在的边缘情况：故障或维护中的节点会占用滚动更新的可用性预算，拖慢或阻塞健康节点上的推进。MaintenanceInProgress 状况为发布该上下文提供了 Kubernetes 原生的位置，未来工作可定义 DaemonSet 控制器如何将其用于滚动排序、可用性核算和状态报告。但当前版本中，没有任何核心工作负载控制器会基于这些状况改变行为，这些行为仍需仔细设计。
Q&A
Kubernetes v1.37 引入了哪些节点生命周期状况？
Kubernetes v1.37 引入了五个标准节点状况：DrainInProgress、Drained、MaintenancePlanned、MaintenanceInProgress 和 GracefulNodeShutdownInProgress。
NodeLifecycleConditions 特性门控在 v1.37 中默认启用吗？
NodeLifecycleConditions 特性门控在 v1.37 中默认禁用，且目前实际上不执行任何操作：它不限制谁可以设置这些状况，也没有核心组件读取它们。
在 v1.37 中，谁负责设置和清除节点生命周期状况？
在 v1.37 中，由管理员或管理员授权的控制器负责设置和清除生命周期状况。
节点生命周期状况的推荐使用模式是什么？
推荐使用生命周期状况来报告状态，而生命周期操作仍通过其他机制管理，例如 kubectl cordon、kubectl drain、污点和特定于工作负载的控制。
为什么需要共享的节点生命周期状况？
因为目前每个组件必须从间接信号（如就绪状态、污点、Pod 状态）重建对节点状态的理解，缺乏共享上下文可能导致组件间做出冲突决策。
节点生命周期状况如何帮助解决 DaemonSet 滚动更新的边缘情况？
MaintenanceInProgress 状况为发布维护上下文提供了 Kubernetes 原生的位置，未来工作可以定义 DaemonSet 控制器如何利用它进行滚动更新排序、可用性核算和状态报告，从而避免管理员手动调整滚动更新。
