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-
