Kubernetes——Pod优先级和抢占式调度

2022-07-06 18:03:37 阅读：164 来源： 互联网

标签：优先级 Kubernetes 调度式调度 Scheduler Pod 节点资源

Pod优先级和抢占式调度

对于运行各种负载（如Service、Job）的中等规模或者大规模的集群来说，出于各种原因，我们需要尽可能提高集群的资源利用率。而提高资源利用率的常规做法是采用优先级方案，即不同类型的负载对应不同的优先级，同时允许集群中的所有负载所需的资源总量超过集群可提供的资源，在这种情况下，当发生资源不足的情况时，系统可以选择释放一些不重要的负载（优先级最低的），保障最重要的负载能够获取足够的资源稳定运行。

在 Kubernetes 1.8 版本之前，当集群的可用资源不足时，在用户提交新的 Pod 创建请求后，该 Pod 会一直处于 Pending 状态，即使这个 Pod 是一个很重要（很有身份）的 Pod，也只能被动等待其他 Pod 被删除并释放资源，才能有机会被调度成功。

在 Kubernetes 1.8 版本引入了基于 Pod 优先级抢占 Pod Priority Preemption 的调度策略，此时 Kubernetes 会尝试释放目标节点上低优先级的 Pod，以腾出空间（资源）安置高优先级的 Pod，这种调度方式被称为“抢占式调度”。在Kubernetes 1.11版本中，该特性升级为Beta版本，默认开启，在后继的Kubernetes 1.14 版本中正式 Release。

如何声明一个负载相对其他负载“更重要”？我们可以通过以下几个维度来定义：

- Priority（英[praɪˈɒrəti] 美[praɪˈɔːrəti]），优先级
- QoS，服务质量等级
- 系统定义的其他度量指标

优先级抢占调度策略的核心行为分别是：

- 驱逐 Eviction（英[ɪˈvɪkʃn] 美[ɪˈvɪkʃn]）
- 抢占 Preemption (英[ˌpriːˈempʃn] 美[ˌpriːˈempʃn])

这两种行为的使用场景不同，效果相同。

Eviction：是 kubelet 进程的行为，即当一个 Node 发生资源不足 under resource pressure 的情况时，该节点上的 kubelet 进程会执行驱逐动作，此时 Kubelet 会综合考虑 Pod 的优先级、资源申请量与实际使用量等信息来计算哪些Pod需要被驱逐；当同样优先级的 Pod 需要被驱逐时，实际使用的资源量超过申请量最大倍数的高耗能 Pod 会被首先驱逐。对于QoS等级为 Best Effort 的 Pod 来说，由于没有定义资源申请 CPU/Memory Request，所以它们实际使用的资源可能非常大。
Preemption: 则是Scheduler执行的行为，当一个新的Pod因为资源无法满足而不能被调度时，Scheduler可能（有权决定）选择驱逐部分低优先级的 Pod 实例来满足此 Pod 的调度目标，这就是 Preemption 机制。

需要注意的是，Scheduler可能会驱逐 Node A 上的一个 Pod 以满足 Node B 上的一个新 Pod 的调度任务。比如下面的这个例子：

一个低优先级的 Pod A 在 Node A（属于机架R）上运行，此时有一个高优先级的 Pod B 等待调度，目标节点是同属机架 R 的 Node B，他们中的一个或全部都定义了 antiaffinity 规则，不允许在同一个机架上运行，此时 Scheduler只好“丢车保帅”，驱逐低优先级的 Pod A 以满足高优先级的 Pod B 的调度。

Pod优先级调度示例如下
首先，由集群管理员创建 PriorityClasses，PriorityClass 不属于任何命名空间：

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

上述 YAML 文件定义了一个名为 high-priority 的优先级类别，优先级为100000，数字越大，优先级越高，超过一亿的数字被系统保留，用于指派给系统组件。

可以在任意Pod中引用上述Pod优先级类别：

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

如果发生了需要抢占的调度，高优先级 Pod 就可能抢占节点 N，并将其低优先级 Pod 驱逐出节点 N，高优先级 Pod 的 status 信息中的 nominatedNodeName 字段会记录目标节点 N 的名称。需要注意，高优先级 Pod 仍然无法保证最终被调度到节点 N 上，在节点 N 上低优先级 Pod 被驱逐的过程中，如果有新的节点满足高优先级 Pod 的需求，就会把它调度到新的 Node 上。而如果在等待低优先级的 Pod 退出的过程中，又出现了优先级更高的 Pod，调度器将会调度这个更高优先级的 Pod 到节点 N 上，并重新调度之前等待的高优先级 Pod。

优先级抢占的调度方式可能会导致调度陷入“死循环”状态。当 Kubernetes 集群配置了多个调度器 Scheduler 时，这一行为可能就会发生，比如下面这个例子：

Scheduler A为了调度一个（批）Pod，特地驱逐了一些Pod，因此在集群中有了空余的空间可以用来调度，此时 Scheduler B 恰好抢在 Scheduler A 之前调度了一个新的 Pod，消耗了相应的资源，因此，当 Scheduler A清理完资源后正式发起 Pod 的调度时，却发现资源不足，被目标节点的 kubelet 进程拒绝了调度请求！这种情况的确无解，因此最好的做法是让多个Scheduler相互协作来共同实现一个目标。

最后要指出一点：使用优先级抢占的调度策略可能会导致某些Pod永远无法被成功调度。因此优先级调度不但增加了系统的复杂性，还可能带来额外不稳定的因素。因此，一旦发生资源紧张的局面，首先要考虑的是集群扩容，如果无法扩容，则再考虑有监管的优先级调度特性，比如结合基于 Namespace 的资源配额限制来约束任意优先级抢占行为。

标签：优先级,Kubernetes,调度,式调度,Scheduler,Pod,节点,资源
来源： https://www.cnblogs.com/zuoyang/p/16451843.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9

Kubernetes——Pod优先级和抢占式调度

Pod优先级和抢占式调度