list-watch和节点亲和性和node亲和性

k8s的集群调度

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 describe pod nginx----保存在etc的数据库当中

list-watch 会在每一步把监听的消息(监听APIserver:6443)-----每个组件contrlller manager, scheduler, kubelet,etcd都要监听apiserver:6443端口

如何把pod分配到node

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、podselectormatches:pod选择器匹配,创建pod的时候也可以根据node节点的标签来进行匹配,查找指定的node节点上标签是否存在,存在的标签是否匹配

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

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

node1 node2 node3

经过预算策略,上诉三个节点都满足条件 >优选

优先策略

leastrequestedpriority:最低请求优先级,通过算法计算节点上的cpu和内存使用率。确定节点的权重,使用率越低的节点相应的权重越高。调度时会更倾向于使用率低的节点,实现资源合理的利用

balanceresourceallocation:平衡资源分配,cpu和内存使用率,给节点赋予一个权重,权重算的是cpu和内存使用率接近。使用率越接近权重越高

和上面的leastrequestedpriority最低请求优先级一起使用

比如 node1:cpu用了20%内存60%

node2:cpuyongle 50%内存50%

node2在被调度时会被优先选择,node2的有优先级更高

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

以上这些策略都是scheduler自带的算法。通过预算策略选择出合适的节点,再通过优选策略选择出来最好的节点,以上都是自带的算法,k8s集群自己来选择

指定节点和指定标签

指定节点:

spec参数设置当中

加上nodeName:node02

指定了节点,再参数中设置了nodeName,指定了节点的名称,会跳过scheduler的调度策略。这个规则是强制匹配

指定标签

spec

nodeSelector:

kubectl get nodes --show-labels 查看节点的标签

自定义标签 kubectl lable nodes master01 test1=a

kubectl lable nodes node01 test1=b

kubectl lable nodes node02 test3=c

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

亲和性:

F

软策略和硬策略

node节点亲和性:

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

requiredDuringSchedulinglgnoredDuringExeution硬策略:选择pod时,声明了node01,如果是硬策略,必须必须部署在node01,也可以理解为强制性要求。

pod的亲和性

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

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

requiredDuringSchedulinglgnoredDuringExeution硬策略

两个pod nginx1和nginx2 必须要和nginx的亲和性匹配,只能部署在node01

键值的运算关系

根据标签选择亲和性

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

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

Gt:大于,大于选择的标签值

Lt:小于,小于选择的标签纸

只能比较整数值

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

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

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

怎么删除标签

kubectl label nodes master01 test1-

Gt:大于,大于选择的标签值

Lt:小于,小于选择的标签纸

只能比较整数值

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

指定键值对的算法为Exists' or 'DoesNotExist不能使用values字段

软策略

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

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

例子

你在部署pod时如何选择策略:

node的亲和性:性能不一致时,我尽量把pod把性能高的多部署,选择软策略

如果节点故障或者维护中,只能选择硬策略,要把故障或者维护的节点剔除。

node01:4核8g

node02: 4核8g

node03: 2核4g

看性能 选择一个软策略,尽量把pod部署在node01和node02上

如果其中一台node03挂了,我会选择硬策略排除挂了的节点

  • 20
    点赞
  • 14
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值