当节点的内存使用量超过阈值时，kubelet 会根据 Pod 相对于 request 的内存使用量来对 Pod 进行排名。排名如下所示：
Pod Name Pod QoS Memory requested Memory limits Memory usageC Burstable 1Gi 2Gi 1.8G
A Best Effort 0 0 700M
E Best Effort 0 0 300M
B Guaranteed 2Gi 2Gi 1.9G
D Burstable 1Gi 2Gi 800M
F Guaranteed 2Gi 2Gi 1G
可以看到在本例中，可以看到在本例中，QoS 等级为 Guaranteed 的 Pod 在 QoS 等级为 Burstable 的 Pod 之前被驱逐。
当内存资源不足时，kubelet 在驱逐 Pod 时只会考虑 requests 和 Pod 的内存使用量，不会考虑 limits。
3. Node OOM (Out Of Memory)因为 kubelet 默认每 10 秒抓取一次 cAdvisor 的监控数据，所以有可能在 kubelet 驱逐 Pod 回收内存之前发生内存使用量激增的情况，这时就有可能触发内核 OOM killer。这时删除容器的权利就由kubelet 转交到内核 OOM killer 手里，但 kubelet 仍然会起到一定的决定作用，它会根据 Pod 的 QoS 来设置其 oom_score_adj 值：
QoS oom_score_adj
Guaranteed -998
Burstable min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)
pod-infra-container -998
kubelet, docker daemon, systemd service -999
如果该节点在 kubelet 通过驱逐 Pod 回收内存之前触发了 OOM 事件，OOM killer 就会采取行动来降低系统的压力，它会根据下面的公式来计算 oom_score 的值：
容器使用的内存占系统内存的百分比 + oom_score_adj = oom_score
OOM killer 会杀掉 oom_score_adj 值最高的容器，如果有多个容器的 oom_score_adj 值相同，就会杀掉内存使用量最多的容器（其实是因为内存使用量最多的容器的 oom_score 值最高）。关于 OOM 的更多内容请参考：Kubernetes 内存资源限制实战。
假设某节点运行着 4 个 Pod，且每个 Pod 中只有一个容器。每个 QoS 类型为 Burstable 的 Pod 配置的内存 requests 是 4Gi，节点的内存大小为 30Gi。每个 Pod 的 oom_score_adj 值如下所示：
Pod Name Pod QoS oom_score_adjA Best Effort 1000
B Guaranteed -998
C Burstable 867（根据上面的公式计算）
D Best Effort 1000
当调用 OOM killer 时，它首先选择 oom_score_adj 值最高的容器（1000），这里有两个容器的 oom_score_adj 值都是 1000，OOM killer 最终会选择内存使用量最多的容器。
总结
因为 kubelet 默认每 10 秒抓取一次 cAdvisor 的监控数据，所以可能在资源使用量低于阈值时，kubelet 仍然在驱逐 Pod。
kubelet 将 Pod 从节点上驱逐之后，Kubernetes 会将该 Pod 重新调度到另一个资源充足的节点上。但有时候 Scheduler 会将该 Pod 重新调度到与之前相同的节点上，比如设置了节点亲和性，或者该 Pod 以 Daemonset 的形式运行。
现在你应该理解了 kubelet 驱逐 Pod 的原理和过程，如果你在部署应用时设置了恰当的参数，知道了所有的可能性，你就能更好地掌控你的集群。
推广GitHub：https://github.com/maxzhang1985/yoyogo 实现基于ASP.NET Core 思想编写的Web框架的 Golang 语言实现 ，如果觉还可以请Star下， 欢迎一起交流。