Kubernetes v1.37 Node Lifecycle Conditions 怎么读节点状态

Kubernetes v1.37 的 Node Lifecycle Conditions 解决的是“节点现在处于什么生命周期阶段”这个沟通问题。它新增了 DrainInProgress、Drained、MaintenancePlanned、MaintenanceInProgress 和 GracefulNodeShutdownInProgress 五个约定条件。

官方地址：https://kubernetes.io/

读节点状态时，先看 .status.conditions 中的 type、status、reason 和 message；这些字段说明“发生了什么”，但不会自动完成 cordon、drain 或 taint。v1.37 仍要把观察信号和实际运维动作分开判断。

v1.37 的五个条件分别说明什么

过去，值班人员往往要把 Ready、taint、Pod 终止状态、标签和云厂商维护接口拼在一起，才能猜出节点是否正在下线。新条件提供了一个统一的 Node 状态位置，但它们首先是观察结果，不是新的调度指令。

每个条件都有 status、reason 和 message。其中 reason 应保持稳定、适合机器读取，message 则补充人能看懂的细节。看到 Unknown 时，不要直接推断“节点坏了”，它只说明当前写入方不能确定状态。

用 kubectl 读出节点的完整条件

先用完整视图确认上下文，尤其要同时看 Ready、生命周期条件、节点是否被标记为不可调度，以及最近的心跳时间：

# 先看 Node 的完整状态，确认条件、不可调度标记和时间字段
kubectl describe node 

# 只列出条件类型、状态和稳定原因，便于值班记录或脚本读取
kubectl get node  \
  -o jsonpath='{range .status.conditions[*]}{.type}{"\t"}{.status}{"\t"}{.reason}{"\n"}{end}'

第一条命令适合人工判断，第二条命令适合看板或自动化采集。若结果中出现 MaintenancePlanned=True，它只能证明维护计划已被发布；还要结合维护窗口、授权写入方和 MaintenanceInProgress 判断是否已经动工。

传统条件也不能跳过：Ready=False 说明节点不健康或不接受 Pod，MemoryPressure、DiskPressure 和 PIDPressure 分别提示资源压力。它们回答的是健康和资源问题，与“是否计划维护”不是同一个维度。

为什么设置条件不等于节点已经排空

v1.37 的生命周期条件允许管理员或获得授权的控制器发布共同信号，但 Kubernetes 不替你定义独占写入、锁定或交接机制。生产集群应给每个条件指定唯一维护者，并约定状态结束时写 False 或删除条件，避免多个控制器互相覆盖。

因此，看到 DrainInProgress=True 后，仍要检查 Pod 是否按预期减少；看到 Drained=True 后，也要确认团队定义的排空标准，而不是把它简单等同于“节点上没有任何对象”。

升级到 v1.37 后的检查清单

1. 先确认集群实际运行的 Kubernetes 版本，再按当前版本文档确认 NodeLifecycleConditions 的特性门状态。v1.37 首次提供这组约定条件，文档和发布博客对早期能力边界的表述可能随补丁版本继续更新。
2. 为每个生命周期条件登记写入方、reason 取值和清除规则，避免人工命令与自动化控制器同时改写。
3. 把条件读取接入看板或值班记录，但告警动作仍以 Ready、taint、Pod 终止状态和 drain 结果为证据。
4. 在灰度节点上验证“计划维护—开始维护—排空完成—维护结束”的状态变化，再推广到整组节点。

官方资料入口：https://kubernetes.io/blog/2026/09/09/kubernetes-v1-37-node-lifecycle-conditions/；https://kubernetes.io/docs/reference/node/node-lifecycle-conditions/。如果你的集群仍处在混合版本阶段，先以实际控制面和 kubelet 版本对应的文档为准。

常见问题

Node Lifecycle Conditions 会自动阻止 Pod 调度吗？

不会。它们是状态观察信号；阻止调度要继续使用 cordon、unschedulable 或 taints。

Drained=True 是否代表节点完全没有 Pod？

不一定。它代表管理员选定的排空标准已达到，标准可能允许 DaemonSet 或其他明确保留的对象存在。

看到 Unknown 应该立刻重启 kubelet 吗？

不应直接重启。先确认条件写入方、Node status 更新、Lease 和相关控制器日志，再判断是暂时无法观察还是节点本身异常。