实战：通过 Pod Priority 保障 Kubernetes 中的关键组件

关键组件

集群内部运行的组件，某些组件会相比其他组件来说更为重要，缺少了这些组件，集群的核心功能或者用户业务将无法得到保障：比如 DNS 组件，当 DNS 组件运行异常，集群内部的 DNS 服务将不可用；又比如网络组件，当网络组件异常，某个节点甚至集群的网络将不可用。

Kubernetes 提供了不少机制来保证组件的正常运行，比如：

• 通过配置 pod 的 restartPolicy，我们可以保证这个 pod 异常退出后，能重新运行起来；

• 通过配置 deployment 的 replicas，我们可以保证这个 pod 有指定个存活的副本，防止单点故障；

• 通过配置 pod 的 liveness 和 readiness 检测，我们可以及时发现 pod 的异常状态；

• 通过配置 pod 资源的 requests 和 limits，我们可以保证这个 pod 有适当的资源来运行。

通常情况下，这些机制保障了组件的正常运行。

下面我们假想一种情况：集群内的一个节点出现异常，控制器检测到这个节点异常后，开始重新调度异常节点上的 pod；假设这个时候，集群的其它节点可用的资源已经不多了，异常节点上有 10 个 pod 等待重新调度，调度完一半后，其它 5 个 pod 因为没有可用资源无法调度，而在这 5 个等待调度的 pod 里，恰好有一个核心应用。这个时候，集群的运行因为核心应用缺失而得不到保障。

如何应对这两种情况呢，我们可以从下面两个角度来解决：

• 调度优先级：如果调度器能够识别出这是一个核心应用，优先调度这个应用，那么只要在决定调度前，资源还满足这个应用调度的情况下，就可以优先确保关键应用被调度出去；

• 抢占：当资源不满足核心应用的调度时，通过驱逐出其它低优先级的应用，挪出资源来给核心应用运行。

Critical Add-On Pods

Critical pods 是 Kubernetes 里面标记关键组件的一种方式。除开 api-server, scheduler, controller-manager 这些系统核心组件，诸如 Heapster, DNS 等组件对于集群完整功能起到关键作用。这些关键组件因为某些原因被驱逐，处于等待调度时，配置 Critical pods 标记的组件可以确保被重新调度。

配置 Critical pods

开启 feature-gates

打开 kubelet, controller-manager 的 feature-gates，具体参数如下：

部署 Rescheduler

Rescheduler 可以通过 static pod 的方式运行，默认把 manifest 文件：

https://github.com/kubernetes/kubernetes/blob/release-1.8/cluster/saltbase/salt/rescheduler/rescheduler.manifest

放到 master 节点的 /etc/kubernetes/manifests/ 目录下即可。

Rescheduler 在 Kubernetes 1.10 版本标记为 deprecated，我们可以通过配置 Pod Priority 来达到类似的功能。

配置 Critical pods

默认情况下，Critical pods 运行在 kube-system 分区下，我们需要给这个 pod 如下额外配置：

• 配置 annotations:

• 

• 配置 tolerations:

使用 Critical pods

下面我们来通过 Critical pods 来解决上述的问题：

首先，我们配置好 feature-gates，这里我们不使用 Rescheduler。

获取当前的可用资源信息，包括可用容量，当前使用量：

运行一个 pod ，并占用掉大部分的可用资源：

确认当前资源使用情况：

再跑一个 pod，并申请大量资源，pod 会因为资源不足而处于 pending 状态：

将 resource-big 配置成 Critical pods ，观察事件和运行情况：

DIY

在上面的例子中，我们没有使用 Rescheduler，在资源不足的情况下，Critical pod 仍然可以通过抢占的模式，来保证运行。感兴趣的可以自己动手做些改变，思考下 Critical pod 实现的原理：

• namespace: 把 namespace 从 kube-system 改为其它分区；

• qos: 创建多个 pod 来占用节点资源，并使用不同 qos 类型来申请资源，观察哪个 pod 会被驱逐；

• 尝试把 DaemonSet 切换为 Deployment 看是否还能达到预期效果；如果不行，可以尝试部署 Rescheduler。

关于 Preemption 的实现，看兴趣的可以查看这个 PR：

https://github.com/kubernetes/kubernetes/pull/40952

Pod Priority and Preemption

Critical pods 是 Kubernetes 中较早实现的保证关键应用运行的一种手段和尝试，包括与之相关的 Rescheduler。但 Critical pods 及 Rescheduler 在使用时不是非常地灵活，而且只能区分关键应用和非关键应用两种类型，后面（Kubernetes 1.8 开始）引入了 Pod Priority。下面我们来看看 Pod Priority 的使用。

Priority

Priority 表明了 pod 相对于其它 pod 的重要程度，开启 pod priority 特性后，Kubernetes 会保证高优先级的 pod 被成功调度和运行。当 pod 调度不成功时，低优先级的 pod 会被驱逐出去，腾出空间给高优先级的 pod 使用。在 1.9 及以后的版本，Priority 同时会影响调度的顺序以及资源不足时 pod 被驱逐的顺序。

PriorityClass

PriorityClass 是一种 Kubernetes 资源，定义了集群内置的 Priority ，主要属性有 name 和 value，分别代表了这个 PriorityClass 的名字及优先级。通过指定 priorityClassName，可以把 pod 于现存的同名 PriorityClass 关联。value 越高，表示 pod 优先级越高。

配置 Pod Priority

开启 feature-gates

打开 kubelet, scheduler, apiserver 的 feature-gates，具体参数如下：

开启 API 及 admission controller

配置 apiserver 的 runtime-config 及 admission-control 参数：

使用 Pod Priority

我们现在尝试通过 Pod Priority 来解决上述的问题：

首先，我们配置好 feature-gates，runtime-config 及 admission-control。

获取当前的可用资源信息，包括可用容量，当前使用量：

创建两个不同优先级的 PriorityClass：

运行一个 pod ，配置普通优先级，并占用掉大部分的可用资源：

确认当前资源使用情况：

再跑一个 pod，并申请大量资源，pod 会因为资源不足而处于 pending 状态：

将 resource-big 的 priorityClassName 配置成 high-priority ，观察事件和运行情况：

本文转载自才云 Caicloud 公众号。

原文链接：https://mp.weixin.qq.com/s/AqfwOiUogN2-bimzBI0ocw