3. Node 生命周期与状态管理：Node 状态、NodeCondition 与 Taint 的关系
在 Kubernetes 集群中，Node 是承载 Pod 的物理或虚拟工作节点。Node 的生命周期管理是调度器做出正确决策的基础。理解 Node 的状态转换、NodeCondition 的详细含义以及它们如何与 Taint 联动，是分析调度器瓶颈和设计高可用集群的关键前提。
3.1 Node 状态机与核心状态
Kubernetes 通过 NodeStatus 中的 Conditions 数组来反映节点的实时健康度。其中，Ready 条件是最核心的状态指标，它决定了节点是否能够参与调度。
| 状态值 | 含义 | 调度器行为 | 典型触发场景 |
|---|---|---|---|
| Ready | 节点健康，kubelet 心跳正常，所有必需服务运行中 | 正常调度 Pod | 节点正常运行，资源充足 |
| NotReady | 节点不可用，kubelet 停止上报心跳或报告异常 | 驱逐已有 Pod（受 tolerationSeconds 控制），禁止新调度 | 节点宕机、网络分区、kubelet 崩溃、磁盘压力 |
| Unknown | Node Controller 超过 node-monitor-period 未收到心跳 |
与 NotReady 相同，视为不可用 | 控制平面与节点网络中断、API Server 过载 |
--node-monitor-period：默认 5s，Node Controller 检查心跳的间隔。--node-monitor-grace-period：默认 40s，超过此时间未收到心跳，状态变为 Unknown。--pod-eviction-timeout：默认 5min，Node 进入 NotReady/Unknown 后，等待此时间开始驱逐 Pod。
3.2 NodeCondition 详解
NodeCondition 是一个结构化的状态数组，每个条件包含 Type、Status（True/False/Unknown）、LastHeartbeatTime、LastTransitionTime、Reason 和 Message。除了 Ready 之外，还有多个重要的条件类型。
| Condition Type | 描述 | 对调度的影响 |
|---|---|---|
| Ready | 节点是否准备好接收 Pod | 核心调度条件，False 或 Unknown 时禁止调度 |
| DiskPressure | 节点磁盘空间不足 | 触发节点级驱逐，调度器会避免将新 Pod 调度至此节点 |
| MemoryPressure | 节点内存资源紧张 | 触发节点级驱逐，调度器会避免调度新的 BestEffort Pod |
| PIDPressure | 节点 PID 资源耗尽 | 触发节点级驱逐，调度器会避免调度新 Pod |
| NetworkUnavailable | 节点网络配置错误或 CNI 插件异常 | 调度器会避免调度 Pod，直到网络恢复 |
# 查看节点所有 Condition
kubectl describe node <node-name>
# 仅查看 Ready 状态
kubectl get node <node-name> -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}'3.3 NodeCondition 与 Taint 的联动机制
Kubernetes 设计了一套自动化的 Taint 生成机制，当 Node 的某些 Condition 变为异常状态时，Node Controller 会自动为节点添加对应的 Taint。这种联动是调度器实现“故障隔离”和“自动驱逐”的核心手段。
NoSchedule 或 NoExecute Taint 的节点上，除非 Pod 定义了对应的 Toleration。这保证了异常节点不会接收新负载。
| NodeCondition 异常 | 自动生成的 Taint | Effect | 说明 |
|---|---|---|---|
| Ready == False | node.kubernetes.io/unreachable |
NoExecute | 节点不可达，准备驱逐 Pod |
| Ready == Unknown | node.kubernetes.io/unreachable |
NoExecute | 心跳超时，与 NotReady 行为一致 |
| DiskPressure == True | node.kubernetes.io/disk-pressure |
NoSchedule | 磁盘压力，禁止新调度 |
| MemoryPressure == True | node.kubernetes.io/memory-pressure |
NoSchedule | 内存压力，禁止新调度（BestEffort Pod 除外） |
| PIDPressure == True | node.kubernetes.io/pid-pressure |
NoSchedule | PID 压力，禁止新调度 |
| NetworkUnavailable == True | node.kubernetes.io/network-unavailable |
NoSchedule | 网络不可用，禁止新调度 |
3.4 状态转换与 Taint 的时效性
Node 状态不是瞬间切换的，Kubernetes 通过 --node-status-update-frequency 和 --node-monitor-grace-period 等参数控制状态转换的延迟。这种延迟设计是为了避免网络抖动导致频繁的 Pod 驱逐。
- 状态转换延迟： 从节点故障到状态变为
NotReady，通常需要 40s（grace period） + 5s（monitor period） ≈ 45s。 - Taint 生成延迟： Node Controller 在状态变更后立即生成 Taint，但调度器需要等待下一次调度周期（默认 100ms）才能感知。
- Pod 驱逐延迟： 对于
NoExecuteTaint，Pod 的驱逐受tolerationSeconds控制。如果 Pod 没有设置tolerationSeconds，则立即驱逐；如果设置了，则等待指定时间。
NotReady 时，Node Controller 会同时添加 node.kubernetes.io/unreachable:NoExecute 和 node.kubernetes.io/disk-pressure:NoSchedule 两个 Taint。调度器会立即停止向该节点调度新 Pod，而已经运行的 Pod 会根据 tolerationSeconds 被逐步驱逐。
3.5 手动管理 Taint 与 Condition 的关系
运维人员可以手动添加或删除 Taint，但需要注意与自动生成的 Taint 之间的优先级和覆盖关系。
| 操作场景 | 推荐做法 | 注意事项 |
|---|---|---|
| 节点计划内维护 | 手动添加 node.kubernetes.io/unschedulable:NoSchedule |
不会触发 Pod 驱逐，仅禁止新调度 |
| 节点故障排查 | 手动添加 node.kubernetes.io/unreachable:NoExecute |
会触发 Pod 驱逐，需谨慎操作 |
| 恢复自动 Taint 管理 | 删除手动添加的 Taint，Node Controller 会重新接管 | 如果 Condition 仍然异常，Node Controller 会重新添加自动 Taint |
3.6 调度器瓶颈分析：状态更新延迟
在大型集群中（1000+ Node），Node 状态更新的延迟是调度器性能瓶颈的常见来源。每次 Node 状态变更都会触发调度器的 nodeInfo 缓存更新，如果更新频率过高，会导致调度器频繁抢占锁，影响调度吞吐量。
- 瓶颈点 1：
nodeInfo缓存失效。当大量 Node 同时变更状态（如网络分区恢复），调度器需要逐个更新缓存，导致调度队列阻塞。 - 瓶颈点 2： Taint 传播延迟。从 Node Controller 生成 Taint 到调度器过滤节点，存在 100ms~1s 的延迟，在此期间可能发生错误的调度决策。
- 瓶颈点 3： Pod 驱逐风暴。当节点批量进入
NotReady状态时，大量 Pod 同时被驱逐，导致调度器需要处理海量的重新调度请求，可能引发调度器 OOM 或响应超时。
- 调整
--node-monitor-grace-period为 60s~120s，减少网络抖动导致的频繁状态切换。 - 使用
--kube-api-qps和--kube-api-burst提高调度器与 API Server 的通信速率。 - 为关键 Pod 设置
tolerationSeconds: 60，避免节点短暂故障时立即被驱逐。