k8s的集群调度

2024-01-08 18:58:12

scheduler组件:负责调度资源,根据调度算法(预算策略、优先策略)把pod调度到node节点

1、list-watch监听

(1)定义:在k8s集群中,通过list-watch的机制进行每个组件之间的写作,保持数据同步,保证每个组件之间的解耦

(2)数据流向

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

①创建pod

??第一步把创建命令发送到apiserver

??第二步由apiserver把消息传给controller manager

??第三步由scheduler资源调度器根据调度算法把命令传给kubelet节点控制器

??第四步由kubelet节点控制器具体分发到哪个节点

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

②创建成功后,pod的详细信息均保存在etcd的数据库中

list-watch会监听apiserver6443的端口,controller manager,scheduler,kubelet,etcd都会监听apiserver6443的端口

注:只有apiserver在etcd上有读写权限

2、调度过程和策略

scheduler是k8s集群的资源调度器,作用:把pod分配到集群节点

(1)调度规则

①公平分配:每个节点都能分配资源

②资源高效利用:整个集群中的资源可以最大化使用

③效率:调度性能好,若pod数量对,能尽快完成大批量的pod的调度工作

④灵活:允许用户根据需求控制、改变调度逻辑

scheduler是一个单独运行的程序,启动后会一直监听apiserver,获取报文中的spec:nodeName字段。创建pod时,为每个pod创建binding,表示该往哪个节点上部署

(2)调度策略(先执行预算策略,再执行优先策略。两个策略结合使用)

1)预算策略

(predicate自带算法,选择node节点,不需要人工干预)

podfitsresources

pod适应资源。检查节点上的剩余资源是否满足pod请求的资源

(主要是CPU和内存资源)

podfitshost

pod适应主机。若要指定pod部署再哪个节点上,检测的主机名是否存在,存在要和pod指定名称匹配才能调度过去

podselectormatches

pod选择器匹配。创建pod时可以根据node节点标签进行匹配,查找指定的node节点上标签是否存在,若存在,再检查标签是否匹配

nodiskconflict

无磁盘冲突。确保已挂载的卷与pod卷不发生冲突,除非目录是只读,可以覆盖原pod

优先执行预算策略,再执行优先策略,若预算策略都不满足,pod将始终处于pending状态,scheduler不断的重试调度,直到有节点满足条件为止

2)优先策略

leastrequestedpriority

最低请求优先级策略。通过算法计算节点上的CPU和内存的使用率,来确定节点的权重,使用率越低的节点权重越高。调度时倾向于权重高的节点,实现资源合理利用

balanceresourceallocation

平衡资源分配策略。考虑CPU和内存的使用率,根据CPU和内存使用率接近给节点赋予权重,越接近权重越高

结合leastrequestedpriority最低请求优先级策略一起使用

imagelocalitypriority

节点上是否已存在要部署的镜像。与镜像总数成正比,满足的镜像数越多,权重越高

以上策略均是scheduler自带的算法。通过预算策略选择出可以部署的节点,再通过优先策略选择出最好的节点

注:部署的node节点必须同时满足预算策略和优先策略,否则立刻报错

3)指定节点(不经过scheduler资源调度器调度)

spec设置参数nodeName:node2

在参数中设置nodeName,指定节点名称会跳过scheduler的调度策略,这个规则是强制匹配,不走调度算法,不考虑该节点资源是否足够

4)指定标签(经过scheduler资源调度器调度)

spec设置参数nodeSelector:标签名

查看节点标签(节点自带标签)

kubectl get nodes --show-labels

自定义节点标签

kubectl label nodes node2 ttt=c

③修改标签

kubectl label nodes node1 sss=b --overwrite

④删除标签(-减号)

kubectl label nodes master yyy-

⑤指定标签部署pod

指定节点标签部署pod经过scheduler调度算法,若节点不满足条件,pod进入pending算法,直到节点满足条件为止

5)键值运算关系

根据标签选择亲和性

In

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

NotIn

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

Gt

大于选择的标签值(只能比较整数值)

Lt

小于选择的标签值(只能比较整数值)

Exists

存在,只选择标签对象。只要node节点上有这个标签对象即可,无论标签值是什么(不能使用values字段)

DoesNotExist

不存在,选择不具有指定标签的对象,无论标签值是什么(不能使用values字段)

亲和性根据标签进行选择

6)亲和性

①节点亲和性
??硬策略requiredDuringSchedulingIgnoredDuringExecution

选择node节点时,声明部署在node1节点,硬策略必须满足这个条件(强制性要求)

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

??软策略preferredDuringSchedulingIgnoredDuringExecution

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

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

A 硬策略

??In方式调度node节点

??NotIn方式调度node节点

??Gt方式调度node节点

??Lt方式调度node节点

??Exists方式调度node节点

??DoesNotExist方式调度node节点

B 软策略(因为有权重,一个策略中可以有多个软策略)

??一个策略中可以有多个软策略(优先执行权重高的策略)

??一个策略中同时有硬策略和软策略(先满足硬策略,再满足软策略)

??不满足硬策略的条件,不再执行软策略,pod始终处于pending状态

在部署pod时如何选择策略?【面试题】

结合业务举例说明:目前有3个node

node1

4核8G

node2

4核8G

node3

2核4G

若集群中节点都正常运行,但性能高低不一致,选择软策略,性能高的多部署一点pod,性能低的少部署一点pod

若其中一个节点故障或维护中,选择硬策略,将pod部署在正常运行的节点

②pod亲和性

??软策略preferredDuringSchedulingIgnoredDuringExecution

要求调度器将pod调度到其他pod的亲和性匹配的节点上,软策略尽量满足这个要求

??硬策略requiredDuringSchedulingIgnoredDuringExecution

要求调度器将pod调度到其他pod的亲和性匹配的节点上,硬策略必须满足这个要求

★删除污点

污点:有污点在,该节点无法部署pod

①查看污点

kubectl describe nodes master |grep -i taints

②删除污点

kubectl taint nodes master node-role.kubernetes.io/master:NoSchedule-

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