节点心跳靠租约维持
在较新的实现里，节点健康由 Lease 对象维持：kubelet 以较短间隔周期性续约，控制面只有在宽限期内没看到续约时，才把节点标记为 NotReady。这样设计是为了避免把一次网络抖动或控制面忙碌当成节点宕机，从而误触发大规模重新调度。租约对象存放在 kube-node-lease 命名空间，排查节点状态来回抖动时，先看续约时间是否正常。
基本信息
| 适用平台 | 启用节点租约特性的集群，较新版本默认开启 |
|---|---|
| 对象位置 | kube-node-lease 命名空间，每个节点一个 Lease 对象 |
| 关键字段 | renewTime、leaseDurationSeconds、acquireTime |
| 心跳间隔 | kubelet 侧可调，常见默认在十秒量级 |
| 宽限期 | 由控制面参数控制，常见默认在数十秒量级 |
典型使用场景
- 节点状态抖动排查：区分短暂续约中断与真实失联
- 大规模同时 NotReady：判断是控制面压力还是网络分区
- 维护窗口评估：确认节点是否真已下线再执行操作
- 参数调优：按集群规模与网络质量调整心跳与宽限
- 告警降噪：把亚分钟级抖动与真实故障在监控上分开
查看租约
查看租约
kubectl get leases -n kube-node-lease
kubectl get lease node1 -n kube-node-lease -o yaml | grep -A2 renewTime
kubectl get lease node1 -n kube-node-lease -o jsonpath='{.spec.renewTime}{"\n"}'
date -u # 与本机时间对照，判断续约是否新鲜
kubectl get node node1 -o jsonpath='{.status.conditions[?(@.type=="Ready")]}'常见现象与含义
| 现象 | 含义 | 处理方向 |
|---|---|---|
| 亚分钟级 NotReady 抖动 | 续约短暂中断，可能来自负载或网络 | 先看租约与网络，再决定是否干预 |
| NotReady 持续 | kubelet 未能续约 | 查 kubelet 日志与节点资源 |
| 租约正常但状态异常 | 其他健康检查失败 | 查看节点状态条件详情 |
| 多节点同时 NotReady | 控制面或网络层问题 | 查控制面负载与 apiserver 连通性 |
节点状态的判定逻辑是「宽限期过后仍未续约」，因此短暂抖动后自动恢复属于设计预期，不必立即人工介入，先观察再动作往往更稳。
调整心跳间隔与宽限期会改变故障判定速度：调得快会放大误判，调得慢会拉长真实故障的发现时间，规模大或网络抖动明显的集群要整体权衡。