目录
一、Kubernetes的list-watch机制
1、List-watch
2、创建pod的过程:
二、scheduler调度的过程和策略:
1、简介
2、预算策略:predicate
3、优先策略:
3.1、leastrequestedpriority:
3.2、balanceresourceallocation:
3.3、imagelocalitypriority:
4、选择的过程:
三、kubernetes对Pod的调度策略
四、定向调度
1、调度策略简介:
2、指定节点:
3、指定标签:
五、亲和性调度:
1、介绍:
2、键值的运算关系:
3、node亲和性实例
一、Kubernetes的list-watch机制
1、List-watch
K8S集群中,通过List-watch机制进行每个组件的协作,保持数据同步。这种设计可以实现每个组件之间的解耦
kubectl配置文件,统一向集群内部apiserver发送命令——通过apiserver把命令发送到各个组件
创建成功之后,kubectl get pod,kubectl describe pod nginx查看信息——在ETCD数据库中
List-watch会在每一步把监听的消息(apiserver:6443)——组件controller-manager、schedule、kubelet、ETCD都会监听apiserver的6443端口
2、创建pod的过程:
1、客户端向apiserver发送创建创建pod的请求,然后apiserver将请求信息存入到ETCD中
2、存入完之后,ETCD会通过apiserver发送创建pod资源的事件
3、controller-manager通过List-watch机制监听apiserver发送出来的事件,并创建相关的pod资源。创建完成之后,通过apiserver将信息存入到ETCD中
4、ETCD存入更新信息之后,再次通过apiserver发送调度pod资源的事件到scheduler
5、scheduler通过List-watch机制监听到apiserver发出的调度事件,通过调度算法,将pod资源调度到合适的node节点上,调度完成后通过apiserver将调度信息更新到ETCD中
6、ETCD收到更新信息后,再次向apiserver发出的创建pod的事件
7、kubelet通过List-watch机制监听apiserver发出的创建pod的事件,然后根据事件信息,在相应的node节点完成pod的创建
二、scheduler调度的过程和策略:
1、简介
scheduler是K8S集群的调度器,把pod分配到集群的节点
调度规则:
- 公平,每个节点都能够分配资源
- 资源高效利用,集群中的资源可以被最大化使用
- 效率:调度的性能要好,能够尽快的完成大批量pod的调度工作
- 灵活:允许用户根据自己的需求,控制和改变调度的逻辑
scheduler:负责调度资源,把Pod调度到node节点上
有两种策略:预算策略、优选策略
scheduler是一个单独运行的程序,只要启动之后就会一直监听apiserver。获取报文中的字段:spec中的nodeName字段
创建pod时,为每个pod创建一个binding,表示该往哪个节点上部署
创建pod到节点时,有两个策略
先执行预算策略,在执行优先策略。这两步的操作都必须成功,否则立刻返回报错
部署的node必须满足这两个策略,少一个都不行
2、预算策略:predicate
自带一些算法,选择node节点,是scheduler自带的算法策略,不需要人工干预
- podfitsresources:pod的适应策源,检查节点上剩余的资源是否满足pod请求的资源(主要是CPU和内存)
- podfitshost:po适应主机,如果pod指定了node的name,检测主机名是否存在,如果存在要和pod指定的名称匹配,这才能调度过去
- podselectormarches:pod选择器匹配,创建pod的时候,可以根据node'节点的标签来进行匹配。他查找指定的node节点上标签是否存在。存在的标签是否匹配
- nodeskconflict:无磁盘冲突,确保已挂载的卷和pod卷不发生冲突。除非目录是只读
如果预算策略不满足,pod将始终处于pending状态,不断重试调度,直到节点满足条件为止
若三个node节点都满足——>优选策略
3、优先策略:
3.1、leastrequestedpriority:
最低请求优先级,通过算法计算节点上的CPU和内存使用率,确定节点的权重
使用率越低的节点,相应的权重就越高。调度时会更倾向于这些使用率低的节点。实现资源合理的利用
3.2、balanceresourceallocation:
平衡资源分配,算CPU和内存的使用率,给节点赋予权重。权重算的是CPU和内存使用率接近,权重越高。
和上面的最低请求优先级一起使用
举例:
node1 CPU和内存使用率:20 60
node2 CPU和内存使用率:50 50
node2的内存和CPU使用率接近,权重高,会被选择
3.3、imagelocalitypriority:
节点上是否已经有了要部署的镜像。镜像的总数成正比,满足的镜像数越多,权重越好
以上三个策略都是scheduler自带的算法,自动的
4、选择的过程:
先通过预算策略选择出可以部署的节点,在通过优选策略选择出最好的节点,以上都是自带的算法。K8S集群自己来选择
三、kubernetes对Pod的调度策略
在 Kubernetes 中,调度 是指将 Pod 放置到合适的节点上,以便对应节点上的 Kubelet 能够运行这些 Pod。
1)定向调度: 使用 nodeName 字段指定node节点名称;使用 nodeSelector 字段指定node节点的标签;
2)亲和性调度: 使用 节点/Pod 亲和性(NodeAffinity、PodAffinity、PodAntiAffinity);
3)污点与容忍: 使用 节点设置污点,结合 Pod设置容忍。
4)全自动调度:运行在哪个节点上完全由Scheduler经过一系列的算法计算得出;
#补充,Pod和node的关系
Node 是 Kubernetes 集群中的工作节点
一个 Node 可以运行多个 Pod,而一个 Pod 只能运行在一个 Node 上
使用标签和选择器可以管理 Node 和 Pod 之间的关系,从而实现灵活的调度和管理。
四、定向调度
1、调度策略简介:
nodeName:指定节点名称,用于将Pod调度到指定的Node上,不经过调度器。
nodeSelector:在 Pod 定义文件的 spec 下的 nodeSelector 字段中设置一个标签选择器,在 Pod 调度的时候,只有具有这些标签的 Node 才会被考虑用来运行这个 Pod。
2、指定节点:
spec参数设置:
nodeName: node2
指定了节点,在参数中设置了nodeName,指定了节点的名称,会跳过scheduler的调度策略,这个规则是强制匹配
3、指定标签:
spec参数设置:
nodeSelector:
节点自定义标签:
kubectl label nodes master01 test1=a
kubectl label nodes node01 test2=b
kubectl label nodes node02 test3=c
kubectl get nodes --show-labels
#查看节点的标签
指定节点标签部署pod,是要经过scheduler的算法,如果节点不满足条件,pod会进入pending状态。直到节点满足条件为止
五、亲和性调度:
1、介绍:
两种亲和性:节点亲和性和pod亲和性
两种策略:软策略和硬策略
node节点的亲和性:
preferredDuringSchedulingIgnoredDuringExecution:软策略
选择node节点时,声明了我最好能部署在node01。如果是软策略,他会尽量满足这个条件,不一定会完全部署在node01节点上。
requiredDuringSchedulinglgnoredDuringExecution:硬策略
选择pod时,声明了部署在node1上。如果是硬策略,必须满足硬策略的条件,必须部署在node1上。强制性要求
pod的亲和性:
preferredDuringSchedulingIgnoredDuringExecution:软策略
要求调度器将pod调度到其他pod的亲和性匹配的节点上。可以是,也可以不是,尽量满足
requiredDuringSchedulingIgnoredDuringExecution:硬策略
要求调度器将pod调度到其他pod的亲和性匹配的节点上,强制性满足
2、键值的运算关系:
都是根据标签来选择node或者pod的亲和性
- In(大写的i):在,选择的标签值在node节点上存在
- Notin:不在,选择label的值不在node节点上
- Gt:大于,要大于选择的标签值,只能比较整数
- Lt:小于,要小于选择的标签值,只能比较整数
- Exists:存在,只是选择标签对象,不考虑值
- DoesNotExist:不存在,选择不具有指定标签的对象。不考虑值
3、node亲和性实例
node亲和性的硬策略:
in策略:
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx:1.22
name: nginx
affinity:
#选择亲和性部署方式
nodeAffinity:
#选择的是node节点的亲和性
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
#选择了亲和性的策略。nodeSelectorTerms你要选择哪个node作为硬策略。匹配的节点标签
- matchExpressions:
#定义了一个符合我要选择的node节点信息
- key: test3
operator: In
#指定键值对的算法
values:
- c
硬限制选择test3=c的节点
Notin:
notin,只要不在test3=c的节点,都能够部署
删除节点上的标签:
kubectl label nodes master01 test1-
kubectl label nodes node01 test2-
kubectl label nodes node02 test3-
更改标签名:
kubectl label nodes node02 memory=1000 --overwrite
Gt:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: memory
operator: Gt
values:
- "612"
大于612节点上部署
Exists:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: memory
operator: Exists
#指定键值对的算法为Exists或DoesNotExist,不能使用values字段
DoesNotExist:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: memory
operator: DoesNotExist
软策略:
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: memory
operator: In
values:
- "1000"
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 10
preference:
matchExpressions:
- key: memory
operator: In
values:
- "500"
多个软策略看权重,权重高,执行指定的软策略
硬策略和软策略一起执行:
先满足硬策略,再考虑软策略。若硬策略无法满足,软策略一个都不会执行
面试题:
你在部署pod的时候选择什么样的策略:
根据node的亲和性:
性能不一致,尽量把pod往性能高的多部署,选择软策略
节点故障或者节点维护中,只能选择硬策略,把故障节点剔除
4、pod亲和性实例
4.1、pod的亲和性和反亲和性:
调度策略: |
匹配标签 |
操作符 |
拓扑域 |
调度目标 |
node的亲和性 |
主机标签 |
In、NotIn、Exists、DoesNotExist、Gt、Lt |
不支持 |
指定主机 |
pod的亲和性 |
pod的标签 |
In、NotIn、Exists、DoesNotExist |
支持 |
pod和指定标签的pod部署在同一个拓扑域 |
pod的反亲和性 |
pod的标签 |
In、NotIn、Exists、DoesNotExist |
支持 |
pod和指定标签的pod部署在不同一个拓扑域 |
4.2、拓扑域:
K8S集群节点当中的一个组织结构,可以根据节点的物理关系或者逻辑关系进行划分
可以用来标识节点之间的空间关系,网络关系,或者其他类型的关系
这里pod的亲和性的拓扑域是标签
4.3、pod的亲和性实例:
1、In
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx:1.22
name: nginx
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- nginx
topologyKey: test1
#topologyKey指定拓扑域的关键字段,表示正在使用test1作为拓扑的关键字。test1一般是节点标签,表示希望吧pod调度到包含有app标签的pod,值为nginx1的在test1的拓扑域上的节点
2、Exists
满足test1节点,且满足pod标签等于app的
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: Exists
topologyKey: test1
软策略:
表示尽量选择满足不存在app的pod标签的 并且 是满足test1的节点的
affinity:
podAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: DoesNotExist
topologyKey: test1
反亲和性:
表示反转,满足哪个就不去哪个
软策略反亲和性:
硬策略反亲和性:
注意点:
- pod的亲和性策略,在配置时,必须要加上拓扑域的关键字topologykey,指向的是节点标签
- pod亲和性的策略分为硬策略和软策略
- pod亲和性的NotIn可以替代反亲和性
- pod亲和性主要是为了把相关联的pod组件部署在同一节点上。lnmp
你在进行部署的时候,怎么考虑node节点:
软硬策略
污点和容忍
污点和容忍可以配合node的亲和性一块使用
污点:是node的调度机制,不是pod
被设为污点的节点,不会部署pod
污点和亲和性相反,亲和性是尽量选择和一定选择
污点的节点一定不被选择?
六、taint
1、taint种类:
- NoSchedule:K8S不会把pod调度到这个节点上
- PreferNoschedule:尽量避免把pod部署在该节点上,不是一定(master节点一般设这个)
- NoExecute:如果污点类型是他,K8S将会把该节点上的pod驱逐出去,而且也不会调度到这个节点
2、NoExecute驱逐:
基于控制器创建的pod,虽然被驱逐,他会在其他节点重新部署
如果是自主式pod,会被直接杀死
注意点:节点服务器需要维护的,服务器要关机,节点上的业务将会失效。在工作中主要部署pod的方式是控制器部署,尤其deployment控制器最多。
一旦设置为驱逐,控制器创建的pod会在其他节点重新部署。所以驱逐的业务主要用在业务维护,和业务回收
驱逐是所有的pod全部被驱逐,跟命名空间无关,所有的都会被驱逐。
不论创建方式是什么,都会被驱逐
但是系统集群组件不会被驱逐
3、污点相关命令:
#创建污点
kubectl taint node node01污点种类
#删除污点
kubectl taint node node01 key:NoSchedule-
#查看污点
kubectl describe nodes node01 | grep -i taints
1、NoSchedule污点
相当于硬策略,不会部署在该节点
kubectl taint node node01 key=1:NoSchedule
2、PreferNoSchedule污点
相当于软策略,尽量避免把pod部署在该节点上,不是一定(master节点一般设这个)
kubectl taint node node01 key=1:PreferNoSchedule
3、NoExecute污点
驱逐污点,配置之后,驱逐该节点上的pod,并且之后不会再部署到该节点上
kubectl taint node node01 key1=2:NoExecute
所有node1上的pod全部被驱逐,自主式pod全部被删除
七、容忍:
即使节点上设置了污点,有了容忍机制,依然可以在设置了污点了节点上部署pod
特殊情况:NoExecute依然可以部署pod,但是有生命周期,时间一到,pod会被销毁然后重新拉起
生命周期结束之后,会驱逐一部分pod到其他节点, *有的节点还是会保持在污点之上
适用于该节点维护完毕,测试一下该节点工作是否正常
实验:
三个节点都设置污点NoSchedule
测试驱逐污点,能不能容忍
设置NoExcute驱逐污点,必须要设置时间限制
tolerations:
- key: key
operator: Equal
value: "1"
effect: NoExecute
tolerationSeconds: 36
这种格式表示会容忍所有污点的key,key对应的节点的污点的类型是NoSchedule
没有key,不匹配节点的标签,会容忍所有污点,但是类型是指定的类型
tolerations:
- operator: Exists
effect: NoSchedule
没有要匹配的污点类型:
指定key的值,指定节点的标签值,但是不指定污点的类型,那么所有节点上只要包含这个指定的标签名,可以容忍所有的污点
tolerations:
- key: key
operator: Exists
node的亲和性
pod的亲和性和发亲和性
污点和容忍
以上都是如何选择node节点部署pod
选择一个期望的节点来部署pod
适用场景举例:
多个master节点:
kubectl taint node master节点名 node-role.kubernetes.io/master=PreferNoSchedule
尽量不往master节点上部署pod,但是不一定。防止资源浪费,也可以自定义一个标签
业务维护:
node02需要维护2个小时
但是这个节点上还有业务pod在运行
就需要把这个节点的污点,设置为驱逐:NoExecute
将该节点上的pod全部赶走
我们部署pod一般都是使用deployment控制器部署,若是控制器部署,会在其他节点重新部署,并不是被杀死。自主式的pod会被删除
一旦节点恢复,一定要把污点去除
八、cordon和drain:
cordon:可以把节点标记为不可用状态
#标记节点为cordon不可部署
kubectl cordon master01 node01
#取消标记
kubectl uncordon master01 node01
drain:排水,把该节点下的pod全部转移到其他node节点上运行
- 一旦执行了drain,被执行的节点会变成不可调度状态
- 会驱逐该节点上的所有pod
kubectl drain node02 --ignore-daemonsets --delete-local-data --force
drain:开始排水,标记node节点为不可调度,然后驱逐pod
--ignore-daemonsets:忽视daemonset方式部署的pod,daemonset部署的pod不会被转移(daemonset要部署的一般是重要的后台运行的,系统pod,所以不动)
--delete-local-data:有本地挂载的pod会被强制杀死
--force:强制释放不是控制器管理的pod
文章来源:https://www.toymoban.com/news/detail-818575.html
文章来源地址https://www.toymoban.com/news/detail-818575.html
#取消drain:
kubectl uncordon node02
到了这里,关于【K8S 云原生】Kurbernets集群的调度策略的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!