K8S的集群调度

2024-01-08 15:55:57

scheduler:负责调度资源,把pod调度到node节点

预算策略

优先策略

1、List-watch

K8S集群中,通过List-watch的机制,进行每个组件的协作,保持数据同步。可以实现每个组件之间的解耦(减少每个组件之间的关联性)

通过kubectl配置文件,向apiserver发送命令,通过apiserver发送到各个组件

kubectl run nginx --image=nginx:1.22 ---> apiserver ---> controller manager ---> scheduler ---> kubelet

创建成功之后,kubectl get pod ??kubectl describe pod nginx ---> 保存在etc的数据库中

List-watch会在每一步把监听的消息(APIserver:6443)--->每个组件(包括:controller manager、scheduler、kubelet、etcd)都会监听6443端口

如何把pod分配到node

2、调度的过程和策略

scheduler是K8S集群的调去器,把pod分配到集群的节点

以下几个问题:

①公平

每个节点都能够分配资源

②资源高效利用

集群当中的资源可以被最大化使用

③效率

调度的性能要好,能够尽快完成大批量的pod的调度工作

④灵活

允许用户根据自己的需求控制和改变调度的逻辑

scheduler是一个单独运行的程序,只要启动,就会一直监听apiserver,获取报文中的字段:spec.nodeName

创建pod时,为每个pod创建一个binding,表示该往哪个节点上部署

创建pod到节点时,有两个策略,先执行预算策略,再执行优先策略。这两步的操作都必须成功,否则立刻返回报错

也就是说,部署的node必须满足预算策略和优先策略

预算策略(rpedicate)

自带一些算法,选择node节点(scheduler自带的算法策略,不需要人为干预)

1、podfitsresources:pod适应资源。检查节点上剩余的资源是否满足pod请求的资源。主要是cpu和内存

2、podfitshost:pod适应主机。如果pod指定了node的name,检测主机名是否存在,存在要和指定的名称匹配,这才能调度过去

3、podselectormatches:pod选择器匹配。创建pod的时候可以根据node的标签来进行匹配。查找指定的node节点上标签是否存在,存在的标签是否匹配

4、nodiskconflict:无磁盘冲突。确保已挂载的卷与pod的卷不发生冲突,除非目录是只读

如果预算策略都不满足,pod将始终处于pending状态,不断地重复调度,直到有节点满足条件为止

经过预算策略,上述三个节点都满条件,那该怎么办? ------> 优选

优先策略

1、leastrequestedpriority:最低请求优先级。通过算法计算节点上的CPU和内存使用率,确定节点的权重。

使用率越低的节点相应的权重越高。调度时会更倾向于使用率低的节点,实现资源合理利用

2、balanceresourceallocation:平衡资源分配。考虑CPU和内存的使用率,给节点赋予权重。权重算的是CPU和内存使用率,使用率越接近权重越高。和leastrequestedpriority一起使用。

node1 cpu和内存;20:80

node2 cpu和内存:50:50

node2会被优先选择

3、imagelocalitypriority:节点上是否已经够有了要部署的镜像。镜像的总数成正比,满足的镜像数越多,权重越高

nginx:1.22

node1 无

node2 有(优先级高)

以上这些策略都是scheduler自带的算法

通过预算选择出可以部署的节点,再通过优先选择出来最好的节点,以上都是自带的算法。K8S集群自己来选择

指定节点

spec参数设置

nodeName: node02

指定了节点,在参数中设置了nodeName,指定了节点的名称,会跳过scheduler的调度策略

指定标签

spec

nodeSelector:

指定节点标签部署pod,是要经过scheduler的算法,如果节点不满足条件,pod会进入penidng状态,直到节点满足条件为止

亲和性

①节点亲和性

node节点亲和性

preferredDuringSchedulingIgnoredDuringExecution:软策略

选择node节点时,声明了最好能部署在node01,软策略会尽量满足这个条件,不一定会完全部署在node01节点上

requiredDuringSchedulinglgnoredDuringExecution:硬策略

选择pod时,声明了node01,必须满足硬策略的条件。必须部署在node01.强制性要求

②pod亲和性

preferredDuringSchedulingIgnoredDuringExecution:软策略

要求调度器将pod调度到其他pod的亲和性匹配的节点上。可以是,也可以不是,尽量满足

pod nginx1 node01

pod nginx2 nginx2希望和nginx1部署在一个节点,尽量满足

requiredDuringSchedulinglgnoredDuringExecution:硬策略

要求调度器将pod调度到其他pod的亲和性匹配的节点上,必须是

pod nginx1 node01

pod nginx2 nginx2必须要和nginx的亲和性匹配,只能往node01

键值的运算关系:

标签。都是根据标签来选择亲和性

In(大写的i):在

选择的标签值,在node节点上存在

Notin:不在

选择的label值,在node节点上不存在

Gt:大于选择的标签值

Lt:小于选择的标签值

Exists:存在。选择标签对象,值不考虑

DoesNotExist:不存在。选择不具有指定标签的对象。值不考虑

只能比较整数值

亲和性策略更具标签来进行选择

软策略:

多个软策略看权重,权重高,执行指定的软策略

硬策略:

先满足硬策略,再满足软策略

Q:你再部署pod的时候选择什么样的策略

A:node亲和性:性能不一致,我尽量把pod往性能高的多部署软策略。节点故障或者节点维护,只能选择硬策略,把故障节点删除

文章来源:https://blog.csdn.net/a91888888/article/details/135457323
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。