解析Kubernetes 1.8中的基于Pod优先级的抢占式调度

Author: xidianwangtao@gmail.com

Kubernetes 1.8中对scheduler的更新

• 【Alpha】支持定义PriorityClass，并指定给Pod来定义Pod Priority；
• 【Alpha】支持基于Pod Priority的抢占式调度;
• 【Alpha】Node Controller支持自动根据Node Condition给Node打上对应的Taints；

什么是抢占式调度？
在Kubernetes 1.8版本以前，当集群资源不足时，用户提交新的Pod建立请求后，该Pod会处于Pending状态，直到集群中有某个Node有足够Available Resources时才会调度成功。 从Kubernetes 1.8版本开始，这种状况下scheduler会根据Pod's Priority进行调度，调度时会选择最合适的Node并把该Node上lower Priority的Pods进行Premmption(Eviction)以释放资源供该higher Priority Pod使用。这种调度时考虑Pod Priority的方式就是Kubernetes中的抢占式调度，简称为Preemption。

在后续的版本中，Pod Priority还会用于节点的out-of-resource Eviction，关于kubelet eviction的工做机制和源码分析，请参考个人对应博客:

• Kubernetes Eviction Manager工做机制分析
• Kubernetes Eviction Manager源码分析

如何开启或关闭该Feature

在Kubernetes 1.8中，Pod Priority和Preemption做为Alpha特性，默认是disable的，若是你要使用该特性，须要给apiserver和scheduler添加以下参数并重启：

• kube-apiserver xxx --feature-gates=PodPriority=true --runtime-config=scheduling.k8s.io/v1alpha1=true
• kube-scheduler xxx --feature-gates=PodPriority=true

反过来，把上面的参数删除并重启，便可disable。

有个问题：若是我开启了这个特性，而且建立了一些PriorityClass，而后还给某些Pod使用了，这个时候我再disable掉这个特性，会不会有问题？

答案是否认的！disable后，那些以前设置的Pod Priority field还会继续存在，可是并没什么用处了，Preemption是关闭的。固然，你也不能给新的Pods引用PriorityClass了。

建立PriorityClass

Enable后，接下来就是建立PriorityClass了：

apiVersion: scheduling.k8s.io/v1alpha1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "This priority class should be used for XYZ service pods only."

注意：PriorityClass是非namespace隔离的，是global的。所以metadata下面是不能设置namespace field的。

• apiVersion: scheduling.k8s.io/v1alpha1 # enable的时候须要配置的runtime-config参数；
• metadata.name: 设置PriorityClass的名字；
• value: 32-bit 整型值，值越大表明优先级越高，可是必须小于等于 1 billion，大于 1 billion的值是给集群内的critical system Pods保留的，表示该Priority的Pod是不能被抢占的。
• globalDefault: true or false，注意只能有一个PriorityClass的这个字段为true，若是没有一个PriorityClass的该字段为true，则那些没有明确引用PriorityClass的Pod的Priority value就为最低值0.
• description: String，写给人看的备注，Kubernetes不作处理；

注意：

• PriorityClass只会影响那些还没建立的Pod，一旦Pod建立完成，那么admission Controller就已经将Pod Spec中应用的PriorityClassName对应的PriorityClass的value设置到Pod的Priority field了。意味着你再修改PriorityClass的任何field，包括globalDefault，也不会影响已经建立完成的Pod。

• 若是你删除某个PriorityClass，那么不会影响已经引用它的Pod Priority，但你不能用它来建立新的Pod了。这实际上是显而易见的。

建立Pod并引用该PriorityClass

接下来，就是建立对应Priority的Pod了：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  priorityClassName: high-priority

若是Pod.spec. priorityClassName中指定的PriorityClass不存在，则Pod会建立失败；
前面也提到，建立Pod的时候Priority Admission Controller会根据PriorityClassName找到对应的PriorityClass，并将其value设置给Pod.spec.priority。

Preemption当前还存在的问题

• 由于抢占式调度evict低优先级Pod时，有一个优雅终止时间(默认30s),若是该Node上须要evict多个低优先级的Pod，那么可能会须要很长的时间后，最终Pod才能调度到该Node上并启动运行，那么问题来了，这么长时间的过去了，这个Node是否此时此刻仍是最适合这个Pod的呢？不必定！并且在大规模且建立Pod频繁的集群中，这种结果是常常的。意味着，当初合正确的调度决定，在真正落实的时候却必定时正确的了。
• 还不支持preempted pod时考虑PDB，计划会在beta版中实现；
• 目前premmpted pod时没考虑Pending pod和victims pod的亲和性：若是该pending pod要调度到的node上须要evict的lower Priority pods和该pending pod是亲和的，目前直接evict lower Priority pods就可能会破坏这种pod亲和性。
• 不支持跨节点抢占。好比pending Pod M要调度到Node A，而该Pending Pod M又与“同Node A一个zone的Node B上的Pod N”是基于zone topology反亲和性的，目前的Alpha版本就会致使Pod M继续Pending不能成功调度。若是后续支持跨界点抢占，就能将lower Priority的Pod N从Node B上evict掉，从而保证了反亲和性。

Taint Nodes by Condition

在Kubernetes 1.8以前，Node Condition是会直接干预调度的，逻辑是是这样的，而且是没法改变的：

• kubelet会按期的将Node Condition传给kube-apiserver并存于etcd。
• kube-scheduler watch到Node Condition Pressure以后，会根据如下策略，阻止更多Pods Bind到该Node。

Node Condition	Scheduler Behavior
MemoryPressure	No new BestEffort pods are scheduled to the node.
DiskPressure	No new pods are scheduled to the node.

- 当Node Condition包含Memory Pressure时，再也不容许BestEffort QoS Pods调度到该节点；
- 当Node Condition包含DiskPressure时，不容许任何pods调度到该节点。

从Kubernetes 1.6开始，kubelet和Node Controller支持自动根据Node Condition给Node打上相应的内置Taints，当时这些Taints只是会影响kubelet eviction，而不会影响调度。这有啥不一样呢？区别就是，给Node打上Taints对调度来讲是软限制，能够经过给pods加上对应的Tolerations就可能强制调度到那个节点。而在1.8以前，Node Condition影响调度是硬限制。

Node Condition和Taints的Map关系以下：

ConditionType	Condition Status	Effect	Key
Ready	True	-
	False	NoExecute	node.kubernetes.io/notReady
	Unknown	NoExecute	node.kubernetes.io/unreachable
OutOfDisk	True	NoSchedule	node.kubernetes.io/outOfDisk
	False	-
	Unknown	-
MemoryPressure	True	NoSchedule	node.kubernetes.io/memoryPressure
	False	-
	Unknown	-
DiskPressure	True	NoSchedule	node.kubernetes.io/diskPressure
	False	-
	Unknown	-
NetworkUnavailable	True	NoSchedule	node.kubernetes.io/networkUnavailable
	False	-
	Unknown	-

总结

Kubernetes 1.8中基于Pod优先级进行抢占式调度的特性都是Alpha，请谨慎在生产中使用，尤为是要注意本文中“Preemption当前还存在的问题”小节中提到的不足。

• 【Alpha】支持定义PriorityClass，并指定给Pod来定义Pod Priority；
• 【Alpha】支持基于Pod Priority的抢占式调度;
• 【Alpha】Node Controller支持自动根据Node Condition给Node打上对应的Taints；

相信很快就能支持好抢占式调度时支持Pod亲和性、跨节点抢占等特性了，那时就完美了。