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的调度机制可以使得资源最大化利用。