k8s的集群调度

发布时间:2024年01月09日

k8s的集群调度:

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

预算策略

优先策略

1、List-watch

k8s集群当中,通过list-watch的机制进行每 个组件的协作,保持数据同步。每个组件之间的解耦。

kubectl配置文件,向APIserver发送命令----apiserver把命令发送到各个组件。

list-watch---会在每一步把监听的消息(APIservice:6443)---controller manager,schedler,kubectl,etcd都会监听apiservice:6443

各个组件(除了客户端)都监听apiservice端口

只有apiservice对etcd有读写信息

如何来把pod分配到node

2,调度的过程和策略:

scheduler是k8s集群的调度器,工作就是把pod分配到集群的节点。

要考虑以下几个问题:

1,公平,每一个节点都能被分配资源

2,资源高效利用:集群当中的资源可以被最大化使用

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

4,灵活:允许用户根据自己的需求,控制和改变调度的逻辑。

scheduler是一个单独运行的程序,启动之后会一直监听apiservice。获取报文中的字段: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

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

优先策略:

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

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

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

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

node1 cpu和内存使用率: 20:60

node2 cpu和内存使用率: 50:50

node2在被调度是会被优先选择。

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

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

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

指定节点:

spec参数设置:

指定nodeName

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

指定标签:

spec

nodeSelector:

节点本身就有标签

查看所有节点的标签。

kubectl get nodes --show-labels

给指定节点自定义标签

kubectl label nodes node01 test1=a

kubectl label nodes node02 test2=b

选择标签:

标签选择,还是会进入scheduler的算法,如果节点不满足条件,pod会进入pending状态。直到节点满足条件为止。

要通过scheduler调度器来调度

亲和性:

节点亲和性

pod亲和性

软策略和硬策略

node节点的亲和性:

preferredDuringSchedulingIgnoredDuringExecution软策略:

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

requiredDuringSchedulingIgnoredDuringExecution硬策略:

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

pod的亲和性:

preferredDuringSchedulingIgnoredDuringExecution软策略:

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

requiredDuringSchedulingIgnoredDuringExecution硬策略:

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

键值的运算关系:

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

In:在

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

Notin:不在

选择label的值不在node节点上

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

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

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

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

affinity:

#选择的亲和性的部署方式:

nodeAffinity:

#选择的是node节点的亲和性:

requiredDuringSchedulingIgnoredDuringExecution:

nodeSelectorTerms:

#选择了亲和性的策略。nodeSelectorTerms你要选择哪个node做为硬策略。匹配的节点的标签。

- matchExpressions:

#定义一个符合我要选择的node节点的信息

- key: test1

operator: In

#指定键值对的算法

values:

- a

也是通过调度器

硬策略,

换成notin

选择标签不是test1=a上的节点

删除节点上的标签:

覆盖标签

加上一个overwrite

比较数字:

大于

只要大于就可以

小于

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

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

只能比较整数值

亲和性策略根据标签来进行选择。

报错

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

选择存在memory的节点

选择没有memory的节点

如果不满足就会进入pending状态

软策略:

选择策略之后要给他一个权重,

- weight: 1

preference:

#选择节点的倾向,尽量满足要求而不是一定

尽量满足不是一定。

可以多个软策略一起执行

以权重高的为准。

选择权重大的来部署

当硬策略和软策略一起的时候

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

硬策略:

先满足硬策略,在满足软策略,不满足硬策略的情况下,软策略也不会满足。

面试题:你在部署pod的时候选择什么样的策略:

node的亲和性:

在性能有高低的时候,选用软策略,尽量把pod往性能高的多部署。

当有node节点故故障,或者节点维护中之后,用硬策略来选择,把故障节点剔除。

schedule的调度算法。

预算策略

过滤出合适的节点

优先策略

选择部署的节点

nodeName:硬匹配,不走调度策略。node01.

nodeSelector:根据节点的标签选择,会走调度算法。

只要是走调度算法,在不满足预算策略的情况下,所有pod都是pending

node节点的亲和性:

硬策略:必须满足的条件。匹配原则也是根据节点的标签。

软策略:尽量满足要求。不是一定

以上是node节点

pod的亲和性和反亲和性

调度策略: 匹配标签 操作符: 拓扑域 调度目标

node的亲和性 主机标签 In NotIn Exist DoesNotExist Gt Lt 不支持 指定主机

pod的亲和性 pod的标签 In NotIn Exist DoesNotExist 支持 pod和指定标签的pod部署在同一个拓扑域

pod的反亲和性 pod的标签 In NotIn Exist DoesNotExist 支持 pod和指定标签的pod部署在不同的拓扑域

pod的亲和性:

使用硬策略

podAffinity

拓扑域: k8s集群节点当中的一个组织结构,可以根据节点的物理关系或者逻辑关系进行划分。

可以用来表示节点之间的空间关系,网络关系或者其他类型的关系。

标签。主机标签。

topologyKey:指定拓扑域的关键字,表示正在使用test1作为拓扑域的关键字。test1一般是节点标签,表示希望把pod调度到包含有app标签的pod,值为nginx的在test1的拓扑域上的节点。

都部署在拓扑域有test1的关键字

用Exists

将标签改一下:

两个node节点标签相同

两都满足,系统会在次选择一个资源较好的节点会部署在一个node节点上

不存在标签才会部署

都有标签会进入pending状态,不用。

使用软策略

软策略还可以部署,不是绝对

使用In

也不是绝对。

反亲和性:

podAntiAffinity

和亲和性的Notin一样的

注意点:

1,pod的亲和性策略,在配置时,必须要加上拓扑域的关键字topologyKey指向的是节点标签

2,pod亲和性的策略分为硬策略和软策略。

3,pod亲和性的notin可以代替反亲和性。

4,pod亲和性主要是为了把相关联的pod部署在同一节点。lnmp

你在进行部署的时候怎么考虑node节点:

污点和容忍,可以配合node节点的亲和性一块使用。

污点:是node的调度机制,不是pod。

被设为污点的节点,不会部署pod。

污点和亲和性相反,亲和性是尽量选择和一定选择

污点的节点一定不会选择?

污点的taint三种类型:

1,NoSchedule:k8s不会把pod调度到这个节点上。

2,PreferNoSchedule:如果污点类型是他,只是尽量避免把pod部署在该节点上。不是一定。(master节点的污点就是这个)

3,*NoExecute:如果你这个污点类型是它,k8s会把该节点上的pod全部驱逐出去,而且也不会调度到这个节点。

面试:驱逐使用的场景:

注意点:节点服务器需要维护的,服务器关机,节点上pod将会失效。在工作中我们主要部署pod的方式的控制器部署。deplayment最多的。一定节点设置为驱逐,控制器会在其他节点重新部署

所有的pod都会被驱逐,跟命名空间无关。所有的一起斗会被驱逐

不论你的创建方式是什么,都会被驱逐

系统集群组件不会被驱逐(kube-proxy)

基于控制器创建的pod,虽然被驱逐,会在其他节点重新部署

基于pod创建的会直接被杀死

查看节点是否为污点

设置污点:

kubectl taint node node01 key=1:NoSchedule

把node01为NoSchedule污点类型

创建pod

kubectl create deployment nginx2 --image=nginx:1.22 --replicas=3

node01上一个都没有

去除污点:

kubectl taint node node01 key:NoSchedule-

又可以部署了

第二种:PreferNoSchedule

kubectl taint node node01 key=1:PreferNoSchedule

尽量不去,不是一定不去

第三种:

驱逐:

一开始:

kubectl taint node node02 key=1:NoExecute

node02上的全部赶走,到别的节点上

容忍:

即使节点上设置了污点,有了容忍机制,依然可以在设置为污点的节点上部署pod.

特殊情况:NoExecute依然可以部署pod,但是有生命周期,时间一到,pod会被销毁。生命周期结束之后,会驱逐一部分到其他节点。有的节点还是在源节点上。

可用于节点维护完毕,测试一下节点的工作是否正常。

把所有节点全都设置为污点:

kubectl taint node node01 key=1:NoSchedule

kubectl taint node node02 key=2:NoSchedule

配置容忍:

effect

容忍策略:容忍节点.上的标签key,对应的标签值是1,effect就是对应的污点的类型。

容忍的类型为NoSchedule,且有key标签,且标签的值为1

设为NoEcute,一定要加上时间,容忍时间。

kubectl taint node node01 key=1:NoExecute

还在超过时间之后,pod被驱逐,会在其他节点重新拉取。没有驱逐走的再到了时间再驱逐。会一直重复。

如果就一个副本

一样的一直重复

污点容忍的机制:

没有key,不匹配节点的标签,容忍使用指定污点类型的污点

会容忍污点的key,key对应的节点的污点的类型是NoSchedule

旨定key的值,指标节点的标签值,但是不指定污点的类型,那么所有节点上只要包含了这个指定的标签名,可以容忍含有标签的所有的污点

只要包含key

不再会被驱逐,容忍所有的污点。

node的亲和性

pod的亲和性和反亲和性

污点和容忍

然后选择node节点部署pod

选择一个期望的节点来部署pod(根据实际情况)

污点的作用

多个master节点:

kubectl taint node master节点名称 node-role.kubernetes.io/master=:PreferNoSchedule

尽量不往master节点上部署pod,但是不是一定的。 防止资源浪费。

业务维护:

node02需要维护2个小时。但是这个节点上还有pod在运行。

就需要把这个节点的污点设置为:NoExecute。

我们部署pod一般都是使用deployment部署,会在其他的节点重新部署,并不是被杀死

自主式的pod会被杀死。

一旦节点恢复,一定要把污点去除

cordon和drain

cordon:可以直接把节点标记为不可部署状态

把节点设置为

kubectl cordon node01

删除的时候出现了一个新的污点:

删除:

kubectl create deployment nginx1 --image=nginx:1.22 --replicas=3

原有的pod不会有影响

取消cordon状态

kubectl uncordon node01

drain:排水,把该节点下的pod全部转移到其他的节点上运行。

1,一旦执行了drain,被执行的节点会变成不可调度状态

2,会驱逐该节点上的所有pod

kubectl drain node02 --ignore-daemonsets --delete-emptydir-data --force

drain:排水,标记node节点为不可调度,然后驱逐pod

--ignore-daemonsets:无视daemonsets部署的pod,daemonsets部署的pod还在节点上。

--delete-local-data:本地挂载的pod会被强制杀死

--force: 强制释放不是控制器管理的pod.

全都排到node01上了

node节点的状态

改回来

目的,还是来管理和部署pod

面试会问:

node亲和性

pod的亲和性和反亲和性

污点:NoExecute

cordon

drain

他们都有软策略和硬策略

如何部署pod是比重要的集群资源的调度机制,合理的配置pod的调度机制可以使得资源最大化利用。

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