k8s的集群调度

scheduler组件：负责调度资源，根据调度算法（预算策略、优先策略）把pod调度到node节点

1、list-watch监听

（1）定义：在k8s集群中，通过list-watch的机制进行每个组件之间的写作，保持数据同步，保证每个组件之间的解耦

（2）数据流向

kubectl配置文件，向apiserver发送命令，通过apiserver把命令发送到各个组件

①创建pod

??第一步把创建命令发送到apiserver

??第二步由apiserver把消息传给controller manager

??第三步由scheduler资源调度器根据调度算法把命令传给kubelet节点控制器

??第四步由kubelet节点控制器具体分发到哪个节点

kubectl run nginx --image=nginx:1.22→apiserver→controller manager→scheduler→kubelet

②创建成功后，pod的详细信息均保存在etcd的数据库中

list-watch会监听apiserver6443的端口，controller manager，scheduler，kubelet，etcd都会监听apiserver6443的端口

注：只有apiserver在etcd上有读写权限

2、调度过程和策略

scheduler是k8s集群的资源调度器，作用：把pod分配到集群节点

（1）调度规则

①公平分配：每个节点都能分配资源

②资源高效利用：整个集群中的资源可以最大化使用

③效率：调度性能好，若pod数量对，能尽快完成大批量的pod的调度工作

④灵活：允许用户根据需求控制、改变调度逻辑

scheduler是一个单独运行的程序，启动后会一直监听apiserver，获取报文中的spec:nodeName字段。创建pod时，为每个pod创建binding，表示该往哪个节点上部署

（2）调度策略（先执行预算策略，再执行优先策略。两个策略结合使用）

1）预算策略 （predicate自带算法，选择node节点，不需要人工干预）
podfitsresources	pod适应资源。检查节点上的剩余资源是否满足pod请求的资源 （主要是CPU和内存资源）
podfitshost	pod适应主机。若要指定pod部署再哪个节点上，检测的主机名是否存在，存在要和pod指定名称匹配才能调度过去
podselectormatches	pod选择器匹配。创建pod时可以根据node节点标签进行匹配，查找指定的node节点上标签是否存在，若存在，再检查标签是否匹配
nodiskconflict	无磁盘冲突。确保已挂载的卷与pod卷不发生冲突，除非目录是只读，可以覆盖原pod
优先执行预算策略，再执行优先策略，若预算策略都不满足，pod将始终处于pending状态，scheduler不断的重试调度，直到有节点满足条件为止
2）优先策略
leastrequestedpriority	最低请求优先级策略。通过算法计算节点上的CPU和内存的使用率，来确定节点的权重，使用率越低的节点权重越高。调度时倾向于权重高的节点，实现资源合理利用
balanceresourceallocation	平衡资源分配策略。考虑CPU和内存的使用率，根据CPU和内存使用率接近给节点赋予权重，越接近权重越高 结合leastrequestedpriority最低请求优先级策略一起使用
imagelocalitypriority	节点上是否已存在要部署的镜像。与镜像总数成正比，满足的镜像数越多，权重越高
以上策略均是scheduler自带的算法。通过预算策略选择出可以部署的节点，再通过优先策略选择出最好的节点
注：部署的node节点必须同时满足预算策略和优先策略，否则立刻报错

3）指定节点（不经过scheduler资源调度器调度）

spec设置参数nodeName:node2

在参数中设置nodeName，指定节点名称会跳过scheduler的调度策略，这个规则是强制匹配，不走调度算法，不考虑该节点资源是否足够

4）指定标签（经过scheduler资源调度器调度）

spec设置参数nodeSelector:标签名

①查看节点标签（节点自带标签）

kubectl get nodes --show-labels

②自定义节点标签

kubectl label nodes node2 ttt=c

③修改标签

kubectl label nodes node1 sss=b --overwrite

④删除标签（-减号）

kubectl label nodes master yyy-

⑤指定标签部署pod

指定节点标签部署pod经过scheduler调度算法，若节点不满足条件，pod进入pending算法，直到节点满足条件为止

5）键值运算关系

根据标签选择亲和性
In	在，选择的标签值在node节点上
NotIn	不在，选择的标签值不在node节点上
Gt	大于选择的标签值（只能比较整数值）
Lt	小于选择的标签值（只能比较整数值）
Exists	存在，只选择标签对象。只要node节点上有这个标签对象即可，无论标签值是什么（不能使用values字段）
DoesNotExist	不存在，选择不具有指定标签的对象，无论标签值是什么（不能使用values字段）
亲和性根据标签进行选择

6）亲和性

①节点亲和性

??硬策略requiredDuringSchedulingIgnoredDuringExecution

选择node节点时，声明部署在node1节点，硬策略必须满足这个条件（强制性要求）

注：先满足软策略，再满足硬策略

??软策略preferredDuringSchedulingIgnoredDuringExecution

选择node节点时，声明最好部署在node1，软策略会尽量满足这个条件，但不一定能完全实现

注：多个软策略看权重，权重高，执行指定的软策略

A 硬策略

??In方式调度node节点

??NotIn方式调度node节点

??Gt方式调度node节点

??Lt方式调度node节点

??Exists方式调度node节点

??DoesNotExist方式调度node节点

B 软策略（因为有权重，一个策略中可以有多个软策略）

??一个策略中可以有多个软策略（优先执行权重高的策略）

??一个策略中同时有硬策略和软策略（先满足硬策略，再满足软策略）

??不满足硬策略的条件，不再执行软策略，pod始终处于pending状态

在部署pod时如何选择策略？【面试题】

结合业务举例说明：目前有3个node

node1	4核8G
node2	4核8G
node3	2核4G

若集群中节点都正常运行，但性能高低不一致，选择软策略，性能高的多部署一点pod，性能低的少部署一点pod

若其中一个节点故障或维护中，选择硬策略，将pod部署在正常运行的节点

②pod亲和性

??软策略preferredDuringSchedulingIgnoredDuringExecution

要求调度器将pod调度到其他pod的亲和性匹配的节点上，软策略尽量满足这个要求

??硬策略requiredDuringSchedulingIgnoredDuringExecution

要求调度器将pod调度到其他pod的亲和性匹配的节点上，硬策略必须满足这个要求

★删除污点

污点：有污点在，该节点无法部署pod

①查看污点

kubectl describe nodes master |grep -i taints

②删除污点

kubectl taint nodes master node-role.kubernetes.io/master:NoSchedule-