深入理解K8S——Pod Preemption资源抢占

深入理解K8S——Pod Preemption资源抢占

参考

Pod Priority and Preemption

Pod Preemption in Kubernetes

what

之前有多篇博文分析过调度器，参见深入分析kube-scheduler，k8s-调度算法，k8s-scheduler，对调度器有了基本认识。如果没有node满足Pod P的要求，就会触发Preemption。Preemption逻辑会试图找到一个node，在node上移除低优先级的Pod就可以满足P。找到node之后，Preemption就会删除这些受害者Pods，然后调度P。

Note:

• 删除需要时间，注意pod.spec.terminationGracePeriodSeconds，在真正删除容器之前，K8S会先发终止信号（kill -15 {pid}）给容器，默认30s。所以就算Preemption提名了node，在终止时间内，如果有其他满足条件的node，P会调度过去。
• Preemption不一定保证PDB
• Preemption必须考虑的问题是：当node上所有低优先级（比P低）的pods都移除了，P是否可以调度到node上。
• 当Preemption与Pod亲和性发送冲突时，即P亲和低优先级的Pod，调度器不会抢占这个node Pod资源。建议P只亲和优先级大于等于自己的Pods
• 跨node抢占暂不支持。考虑以下场景，zone下有node A，node B，Pod A运行在node A上。考虑Pod B抢占 node B，但是Pod B与Pod A在zone下有反亲和性，所以Pod B无法调度在node B上。

where

将Preemption放在调度里面有一下几点好处：

• Preemption也有一些调度逻辑，需要遍历node，找到合适node等等，所以放在调度里面可以减少重复代码
• 减少资源竞争，如果别的组件实现Preemption，会引起资源竞争。不过多调度器也会引起资源竞争。

特别注意

• 避免错误地设置高优先级的Pod，引起资源抢占
• 被抢占的Pod会有时间优雅退出，抢占Pod需要等待这些受害者退出。如果在等待期间，有一个高优先级的Pod，那么可能这个Pod调度到node上，导致抢占Pod无法被调度
• 如果有多个node可以抢占，调度器会选择总Pod优先级最低的node
• 根据优先级排序时，还需要按照QoS排序
• 由于调度器只考虑资源请求（只关注request，不考虑limit），所以不会驱逐BestEffort Pod，因为BestEffort 没有request，所以在调度器看来，删除它并没有释放资源
• 释放资源总量等于P的资源申请总量

ping-pong

考虑这样一个场景，node上运行一些高优先级的BestEffort Pod，调度器调度了一个低优先级的非BestEffort Pod在node。当node处于资源压力时，kubelet会先驱逐低优先级的Pod，不管高优先级的BestEffort 。但是调度器不考虑BestEffort，还是会调度node，造成这种ping-pong。