Kubernetes 节点 Not Ready 时 Pod 驱逐机制深度解析（上）
#作者：邓伟
文章目录
- 一、核心原理：多层级驱逐体系与协同机制
- 二、实战：多维度故障模拟与驱逐验证
一、核心原理：多层级驱逐体系与协同机制
- Node 状态与 Condition 演进
Kubernetes 通过NodeCondition描述节点状态，核心状态包括：
- Ready：节点是否准备好接收 Pod（True/False/Unknown）
- OutOfDisk：节点磁盘是否不足
- MemoryPressure：节点内存是否存在压力
- DiskPressure：节点磁盘 IO 是否存在压力
当节点因网络分区、Kubelet 进程崩溃等原因无法正常汇报状态时，Ready状态会变为Unknown；当节点资源持续不足或主动标记为不可用，状态会变为False。这两种情况都会触发节点NotReady的驱逐逻辑。
- 多层级驱逐体系
Kubernetes 通过Taint/Toleration、资源压力驱逐、API 主动驱逐构建了立体化的驱逐体系：
（1）Taint/Toleration 机制（控制平面主导）
- Taint：附加在节点上的属性（如node.kubernetes.io/not-ready:NoExecute），表示节点不希望运行某些 Pod
- Toleration：定义在 Pod 上的规则，表示 Pod 可以容忍某个 Taint
当节点NotReady时，Kubernetes 会自动为节点添加NoExecute类型的 Taint：
# 节点NotReady时自动添加的Taint
- key: node.kubernetes.io/not-readyvalue: ""effect: NoExecute
NoExecute效应的 Taint 会使不具备对应 Toleration 的 Pod 被立即驱逐，而具备 Toleration 的 Pod 可根据配置决定是否驱逐或延迟驱逐。
（2）资源压力驱逐（Kubelet 本地执行）
Kubelet 通过监控节点资源使用情况，当内存、磁盘等不可压缩资源达到阈值时，会主动驱逐 Pod 以释放资源。核心机制包括：
- 软驱逐：资源使用超过阈值后持续观察宽限期（如–eviction-soft-grace-period），若未恢复则触发驱逐
- 硬驱逐：资源使用直接超过临界值时立即驱逐（如内存 < 250Mi）
- 驱逐信号：支持memory.available、nodefs.available等 8 种资源指标
（3）API 主动驱逐（人工干预或自动化策略）
通过kubectl drain或直接调用 Eviction API，可强制驱逐节点上的 Pod，同时遵循PodDisruptionBudget（PDB）等策略保障服务可用性。
- 关键控制器协同
（1）NodeController（控制平面）
- 负责监控所有节点状态，当检测到节点NotReady时，向节点添加node.kubernetes.io/not-ready:NoExecute Taint
- 支持通过–node-monitor-grace-period参数配置状态检测延迟（默认 40 秒）
（2）TaintManager（控制平面） - 作为kube-controller-manager的子组件，默认启用（–enable-taint-manager=true）
- 周期性检查节点 Taint 与 Pod Toleration 的匹配关系，对不满足条件的 Pod 发起驱逐
- 驱逐逻辑遵循NoExecute规则：若 Pod 无对应 Toleration，立即驱逐；若有 Toleration 但指定tolerationSeconds，则延迟驱逐
（3）Kubelet（节点代理） - 执行本地资源压力驱逐，优先回收镜像、日志等本地资源
- 处理 API 发起的驱逐请求，执行 Pod 优雅终止
二、实战：多维度故障模拟与驱逐验证
- 准备测试环境
# 创建测试Namespace
kubectl create ns test-zone
# 部署无状态应用（无NotReady Toleration）
kubectl run nginx-test --image=nginx --replicas=3 -n test-zone
# 查看初始Pod分布
kubectl get pods -n test-zone -o wide
- 模拟节点 NotReady（三种方式）
方式 1：手动标记节点不可用
# 标记节点为不可调度（可选，避免新Pod调度）
kubectl cordon node01
# 模拟节点NotReady（修改NodeCondition）
kubectl patch node node01 -p '{"spec":{"unschedulable":true}}'
# 或通过API直接修改Condition（更底层）
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Node
metadata:name: node01
spec:conditions:- type: Readystatus: "False"reason: NodeNotReadymessage: "Network partition"
EOF
方式 2：停止 Kubelet 服务（真实故障模拟）
# 登录节点，停止Kubelet
systemctl stop kubelet
# 等待节点状态变为Unknown（约40秒，由--node-monitor-grace-period控制）
kubectl get nodes -w
方式 3：资源压力触发驱逐（Kubelet 本地驱逐）
# 模拟内存压力（需root权限）
stress -m 1 --vm-bytes 3G
# 观察驱逐事件
kubectl describe node node01 | grep -A 5 Conditions
- 观察驱逐过程
（1）节点 Taint 变化
kubectl describe node node01 | grep -A 5 Taints
# 输出应包含自动添加的NotReady Taint
Taints: node.kubernetes.io/not-ready:NoExecute
（2）Pod 驱逐日志
# 查看Pod事件
kubectl get pods -n test-zone -o wide
# 状态变为Terminating，Events显示被TaintManager驱逐
kubectl describe pod nginx-test-xxx -n test-zone | grep -i reason
# 包含"evicted by TaintManager"相关记录
（3）驱逐宽限期（Toleration 配置）
若 Pod 定义了NotReady Toleration 并设置tolerationSeconds：
tolerations:
- key: "node.kubernetes.io/not-ready"operator: "Exists"effect: "NoExecute"tolerationSeconds: 300 # 5分钟后驱逐
则 Pod 会在宽限期后被驱逐，可通过kubectl get pods -w观察延迟驱逐现象。
- Node Problem Detector（NPD）集成实战
部署Node Problem Detector，可自动检测节点硬件故障、内核错误等，并触发对应的 Taint 添加：
# 部署NPD
kubectl apply -f https://raw.githubusercontent.com/kubernetes/node-problem-detector/master/config/node-problem-detector.yaml
# 验证NPD运行
kubectl get pods -n kube-system -l app=node-problem-detector