从一个 SRE 角度看, Pod 驱逐分为两种情况:
kubect drain
drain ~= cordon + delete Pod
主动驱逐,受限于 PDB,如果配置了 PDB,会防止应用出现全部不可用的状况,但是直接 操作 DELETE Pod ,不受 PDB 限制,所以 drain 比 直接 DELETE 会安全一些,当做节点维护时。
配置 PDB,进一步提高服务整体可用性
Node Not Ready
节点会被打上 node.kubernetes.io/unreachable:NoExecute 的污点,上面的 Pod 会被驱逐。
可以 kubectl describe node 进行定位
Kubelet 发起驱逐
主要是节点不可压测资源不足造成,这里分析下 内存不足的情况下:
BestEffort
或 Burstable
Pod。这些 Pod 会根据它们的优先级以及它们的资源使用级别超过其请求的程度被逐出。Guaranteed
Pod 和 Burstable
Pod 根据其优先级被最后驱逐。可根据事件日志快速定位到
内核 OOM
只看进程的 oom_score
, 优先 kill oom_score
较高的,不通服务 的 Qos 设置可能会影响 oom_score,但不能 保证不被 kill。
内核 OOM 日志,可以从 dmesg 中查到, 可以配置 NPD 快速发现 内核 OOM 事件 内核 OOM,一般情况,Pod 不会重新调度,只会原地重启
超过 Limit 限制
超过 cgroup 限制,会被强制杀掉
可根据事件日志快速定位到
打 NoExecute 污点,或者移除标签,导致标签选择失败
Controller Manager 控制器,循环监听 Node 、Pod 信息,然后持续调谐
抢占驱逐
Pod 分配调度时,节点资源不足,Scheduler 发起的驱逐,低优先级 Pod 腾出资源给 高优先级 Pod 调度
总结: