0
点赞
收藏
分享

微信扫一扫

k8s教程(17)-pod之优先级调度


文章目录

  • ​​01 引言​​
  • ​​02 案例​​
  • ​​2.1 创建PriorityClass​​
  • ​​2.2 Pod声明优先级类别​​
  • ​​2.3 注意事项​​
  • ​​03 文末​​

01 引言

声明:本文为《Kubernetes权威指南:从Docker到Kubernetes实践全接触(第5版)》的读书笔记

对于运行各种负载(如:​​Service​​​、​​Job​​)的中等规模或者大规模的集群来说,出于各种原因,我们需要尽可能提高集群的资源利用率

提高资源利用率的常规做法是采用优先级方案,即不同类型的负载对应不同的优先级,同时允许集群中的所有负载所需的资源总量超过集群可提供的资源,在这种情况下,当发生资源不足的情况时,系统可以选择释放一些不重要的负载(优先级最低的),保障最重要的负载能够获取足够的资源稳定运行。

本文主要举例演示pod的优先级调度。

02 案例

2.1 创建PriorityClass

首先,由集群管理员创建​​PriorityClass​​​(​​PriorityClass​​不属于任何命名空间):

apiversion:scheduling.k8s.io/vlbetal kind:Priorityclass
metadata:
name:high-priority
va1ue:1000000
globalDefault:false
description:"This priority class should be used for XYZ service pods only."

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

2.2 Pod声明优先级类别

可以在任意​​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​​字段会记录目标节点的名称。

需要注意,高优先级Pod仍然无法保证最终被调度到节点​N​上,在节点​N​上低优先级​Pod​被驱逐的过程中,如果有新的节点满足高优先级​Pod​的需求,就会把它调度到新的​Node​

而如果在等待低优先级的Pod退出的过程中,又出现了优先级更高的​Pod​,调度器就会调度这个更高优先级的​Pod​到节点​N​上,并重新调度之前等待的高优先级​Pod​

2.3 注意事项

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

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

高优先级​​Pod​​​抢占节点并驱逐低优先级的​​Pod​​​,这个问题对于普通的服务型的
​​​Pod​​​来说问题不大,但对于执行批处理任务的​​Pod​​​来说就可能是个灾难,当一个高 优先级的批处理任务的​​Pod​​​创建后,正在执行批处理任务的某个低优先级的​​Pod​​可 能因为资源不足而被驱逐,从而导致对应的批处理任务被搁置。

为了避免这个问题发生,​PriorityClass增加了一个新的属性一​preemptionPolicy​,当它的值为 ​preemptionLowerPriorty​(默认)时,就执行抢占功能,当它的值被设置为​Never​ 时,就默认不抢占资源,而是静静地排队,等待自己的调度机会

03 文末

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

本文主要讲解的是​​Pod​​的优先级调度的案例以及注意事项,希望能帮助到大家,谢谢大家的阅读,本文完!


举报

相关推荐

0 条评论