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