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-------->etcd的数据库当中。
list-watch---会在每一步把监听的消息(APIserver:6443)------controller manager ,scheduler .kubelet,etcd都会监听apiserver:6443端口
2、调度的过程和策略
scheduler是k8s集群的调取器,把pod分配到集群的节点
以下几个问题:
1、公平,每个节点都能够分配资源
2、资源高效利用:集群当中的资源可以被最大化使用
3、效率:调度的性能要搞好,能够尽快的完成大批量的pod的调度工作
4、灵活:允许用户根据自己的需求,控制和改变调度的逻辑。
scheduler是一个单独运行的程序,启动之后就会一直监听APIserver.获取报文中的字段:spec.nodeName
创建pod时,为每个Pod创建一个binding,表示该往哪个节点上部署。
创建pod到节点时,有两个策略,先执行预算策略,再执行优先策略 这两步的操作都必须成功,否则立刻返回报错。
也就是说,部署的node,必须满足这两个策略。
预算策略:
predicate自带一些算法来选择Node节点 (scheduler自带的算法策略,不需要人工干预)
1、podfitsresources:pod适应资源,检查节点上的剩余资源是否满足pod请求的资源。主要是cpu和内存
2、podfitshost:pod适应主机,如果pod指定了Node的name,nginx1pod--->node01,检测主机名是否存在,存在要和pod指定的名称匹配,才能调度过去
3、podeslectormatchers:pod选择器匹配,创建pod的时候可以根据node的标签来进行匹配。查找指定的node节点上标签是否存在,存在的标签是否匹配。
4、nodiskconflict:无磁盘冲突,确保已挂载的卷与pod的卷不发生冲突,除非目录是只读
如果预算策略都不满足,pod将始终处于pending状态,不断的重试调度,直到有节点满足条件为止
node1 node2 node3
经过预算策略,上述三个节点都满足,那该怎么办?---->优选
优先策略
leastrequestedpriority:最低请求优先级,通过算法计算节点上的cpu内存使用率,确定节点的权重
使用率越低的节点相应的权重越高。调度时会更倾向于使用率低的节点。实现资源合理的利用
balanceresourceallocation:平衡资源分配,cpu和内存的使用率,给节点赋予权重,权重算的是cpu和内存使用率接近。权重越高
和上面的leastrequestedpriority最低请求优先级一起使用
node1 cpu和内存使用率:20:60
node2 cpu和内存使用率:50:50
node2在被调度时会被优先选择。
imagelocalitypriority:节点上是否已经有了要部署的镜像。镜像的总数成正比,满足的镜像数越多,权重越好
nginx:1.22
node1 无
node2 有
以上这些策略scheduler自带的算法
通过预算选择出可以部署的节点,再通过优先选择出来最好的节点,以上都是自带的算法。k8s集群自己来选择
指定节点:
spec参数设置:
nodeName:node02
指定了节点,在参数中设置了nodeName,指定了节点的名称,会跳过scheduler的调度策略,这个规则是强制匹配
指定标签:
spec
nodeSelector:kubectl get nodes --show-labels 查看所有节点的标签
kubectl label nodes master01 test1=a kubectl label nodes node01 test2=b kubeclt label nodes node02 test3=c
以上三行,创建自定义标签的命令
kubectl get deployment.apps -o wide 可以看到已经部署的deployment的标签
nodeSelector:
指定节点标签部署pod,是要经过scheduler的算法,如果节点不满足条件,pod会进入pending状态,直到节点满足条件为止
亲和性:
节点亲和性和pod亲和性
软策略与硬策略
node节点的亲和性:
preferredDuringSchedulingIgnoredDuringExecution 软策略:
选择node节点时,我声明了我最好能部署在Node01,软策略会尽量满足这个条件。不一定会完全部署在node01节点上
requiredDuringSchedulinglgnoreFuringExecution 硬策略:
选择pod时,声明了node01,我是硬策略,必须满足硬策略的条件。必须部署在node01,强制性要求
pod的亲和性:
preferredDuringSchedulingIgnoredDuringExecution 软策略
要求调度器将pod调度到其他pod的亲和性匹配的节点上。可以是,也可以不是,尽量满足
pod nginx1 node01
pod nginx2 nginx2希望跟nginx1部署在一个节点上,尽量满足。
requiredDuringSchedulinglgnoreFuringExecution 硬策略
要求调度器将Pod调度到其他pod的亲和性匹配的节点上。必须是
pod nginx1 node01
pod nginx2 nginx2必须要和nginx的亲和性匹配,只能往node01
键值的运算关系:
标签,都是根据标签来选择亲和性
In:在
选择的标签值在node节点上存在
Notin:不在
选择label的值不在node节点上存在
Gt:大于,大于选择的标签值
Lt:小于,小于选择的标签值
Exists:存在,选择标签对象,值不考虑
DoesNotExist:不存在,选择不具有指定标签的对象。值不考虑。
软策略:
多个软策略看权重,权重高,执行指定的软策略
硬策略:文章来源:https://www.toymoban.com/news/detail-819978.html
先满足硬策略,再考虑软策略文章来源地址https://www.toymoban.com/news/detail-819978.html
到了这里,关于K8S集群调度的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!