伊布 分布式实验室 

Pod优先级、抢占

Pod优先级、抢占功能，在Kubernetes v1.8引入，在v1.11版本进入beta状态，并在v1.14版本进入GA阶段，已经是一个成熟的特性了。
顾名思义，Pod优先级、抢占功能，通过将应用细分为不同的优先级，将资源优先提供给高优先级的应用，从而提高了资源可用率，同时保障了高优先级的服务质量。
我们先来简单使用下Pod优先级、抢占功能。
集群版本是v1.14，因此feature PodPriority默认是开启的。抢占模式的使用分为两步：

1. 定义PriorityClass，不同PriorityClass的value不同，value越大优先级越高。

2. 创建Pod，并设置Pod的priorityClassName字段为期待的PriorityClass。

创建PriorityClass

如下，先创建两个PriorityClass：high-priority和low-priority，其value分别为1000000、10。
需要注意的是，要将low-priority的globalDefault设置为了true，因此low-priority即为集群默认的PriorityClass，任何没有配置priorityClassName字段的Pod，其优先级都将设置为low-priority的10。一个集群只能有一个默认的PriorityClass。如果没有设置默认PriorityClass，则没有配置PriorityClassName的Pod的优先级为0。

创建后查看下系统当前的PriorityClass。

可以看到，除了上面创建的两个PriorityClass，默认系统还内置了system-cluster-critical、system-node-critical用于高优先级的系统任务。
设置Pod的PriorityClassName

为了方便验证，这里使用了扩展资源。为节点x1设置了扩展资源example.com/foo的容量为1。

查看下x1的allocatable和capacity，可以看到x1上有1个example.com/foo资源。

我们先创建Deployment nginx，它会请求1个example.com/foo资源，但是我们没有设置PriorityClassName，因此Pod的优先级将是默认的low-priority指定的10。

然后再创建Deployment debian，它并没有请求example.com/foo资源。

此时两个Pod都可以正常启动。
开始抢占
我们将Deployment debian的example.com/foo请求量改为1，并将priorityClassName设置为high-priority。

此时，由于集群中只有x1上有1个example.com/foo资源，而且debian的优先级更高，因此scheduler会开始抢占。如下是观察到的Pod过程。

君子：Non-preempting PriorityClasses

Kubernetes v1.15为PriorityClass添加了一个字段PreemptionPolicy，当设置为Never时，该Pod将不会抢占比它优先级低的Pod，只是调度的时候，会优先调度（参照PriorityClass的value）。

所以我把这种PriorityClass叫做“君子”，因为他只是默默凭本事（Priority）排队，不会强抢别人的资源。官网给出一个适合的例子是 data science workload。
对比Cluster Autoscaler

云上Kubernetes在集群资源不足时，可以通过Cluster Autoscaler自动对Node扩容，即向云厂商申请更多的Node，并添加到集群中，从而提供更多资源。
但这种做法不足的地方是：

• 云下场景不易实施

• 增加Node要多花钱

• 不是立即的，需要时间

如果用户能够比较明确的划分应用的优先级，在资源不足的时候通过抢占低优先级Pod的资源，可以更好的提高资源利用率、提高服务质量。
原文链接：https://ieevee.com/tech/2019/07/10/preeption.html