scheduler：负责调度资源，把pod调度到node节点
预算策略
优先策略
1、List-watch
K8S集群中，通过List-watch的机制，进行每个组件的协作，保持数据同步。可以实现每个组件之间的解耦（减少每个组件之间的关联性）
通过kubectl配置文件，向apiserver发送命令，通过apiserver发送到各个组件
kubectl run nginx --image=nginx:1.22 ---> apiserver ---> controller manager ---> scheduler ---> kubelet
创建成功之后，kubectl get pod kubectl describe pod nginx ---> 保存在etc的数据库中
List-watch会在每一步把监听的消息（APIserver:6443）--->每个组件（包括：controller manager、scheduler、kubelet、etcd）都会监听6443端口
如何把pod分配到node
2、调度的过程和策略
scheduler是K8S集群的调去器，把pod分配到集群的节点
以下几个问题：
①公平
每个节点都能够分配资源
②资源高效利用
集群当中的资源可以被最大化使用
③效率
调度的性能要好，能够尽快完成大批量的pod的调度工作
④灵活
允许用户根据自己的需求控制和改变调度的逻辑
scheduler是一个单独运行的程序，只要启动，就会一直监听apiserver，获取报文中的字段：spec.nodeName
创建pod时，为每个pod创建一个binding，表示该往哪个节点上部署
创建pod到节点时，有两个策略，先执行预算策略，再执行优先策略。这两步的操作都必须成功，否则立刻返回报错
也就是说，部署的node必须满足预算策略和优先策略
预算策略（rpedicate）
自带一些算法，选择node节点（scheduler自带的算法策略，不需要人为干预）
1、++++podfitsresources++++：pod适应资源。检查节点上剩余的资源是否满足pod请求的资源。主要是cpu和内存
2、++++podfitshost++++：pod适应主机。如果pod指定了node的name，检测主机名是否存在，存在要和指定的名称匹配，这才能调度过去
3、++++podselectormatches++++：pod选择器匹配。创建pod的时候可以根据node的标签来进行匹配。查找指定的node节点上标签是否存在，存在的标签是否匹配
4、++++nodiskconflict++++：无磁盘冲突。确保已挂载的卷与pod的卷不发生冲突，除非目录是只读
如果预算策略都不满足，pod将始终处于pending状态，不断地重复调度，直到有节点满足条件为止
经过预算策略，上述三个节点都满条件，那该怎么办? ------> 优选
优先策略
1、++++leastrequestedpriority++++：最低请求优先级。通过算法计算节点上的CPU和内存使用率，确定节点的权重。
使用率越低的节点相应的权重越高。调度时会更倾向于使用率低的节点，实现资源合理利用
2、++++balanceresourceallocation++++：平衡资源分配。考虑CPU和内存的使用率，给节点赋予权重。权重算的是CPU和内存使用率，使用率越接近权重越高。和leastrequestedpriority一起使用。
node1 cpu和内存；20:80
node2 cpu和内存：50:50
node2会被优先选择
3、++++imagelocalitypriority++++：节点上是否已经够有了要部署的镜像。镜像的总数成正比，满足的镜像数越多，权重越高
nginx:1.22
node1 无
node2 有（优先级高）
以上这些策略都是scheduler自带的算法
通过预算选择出可以部署的节点，再通过优先选择出来最好的节点，以上都是自带的算法。K8S集群自己来选择
指定节点
++++spec参数设置++++
nodeName: node02
指定了节点，在参数中设置了nodeName，指定了节点的名称,会跳过scheduler的调度策略
指定标签
spec
nodeSelector：
指定节点标签部署pod，是要经过scheduler的算法，如果节点不满足条件，pod会进入penidng状态，直到节点满足条件为止
++++亲和性++++
①节点亲和性
node节点亲和性
++++preferredDuringSchedulingIgnoredDuringExecution++++：软策略
选择node节点时，声明了最好能部署在node01，软策略会尽量满足这个条件，不一定会完全部署在node01节点上
++++requiredDuringSchedulinglgnoredDuringExecution++++：硬策略
选择pod时，声明了node01，必须满足硬策略的条件。必须部署在node01.强制性要求
②pod亲和性
++++preferredDuringSchedulingIgnoredDuringExecution++++：软策略
要求调度器将pod调度到其他pod的亲和性匹配的节点上。可以是，也可以不是，尽量满足
pod nginx1 node01
pod nginx2 nginx2希望和nginx1部署在一个节点，尽量满足
++++requiredDuringSchedulinglgnoredDuringExecution++++：硬策略
要求调度器将pod调度到其他pod的亲和性匹配的节点上，必须是
pod nginx1 node01
pod nginx2 nginx2必须要和nginx的亲和性匹配，只能往node01
键值的运算关系：
标签。都是根据标签来选择亲和性
++++In++++（大写的i）：在
选择的标签值,在node节点上存在
++++Notin++++：不在
选择的label值,在node节点上不存在
++++Gt++++：大于选择的标签值
++++Lt++++：小于选择的标签值
++++Exists++++：存在。选择标签对象，值不考虑
++++DoesNotExist++++：不存在。选择不具有指定标签的对象。值不考虑
只能比较整数值
亲和性策略更具标签来进行选择
软策略:
多个软策略看权重，权重高，执行指定的软策略
硬策略:
先满足硬策略，再满足软策略
Q：你再部署pod的时候选择什么样的策略
A：node亲和性：性能不一致，我尽量把pod往性能高的多部署软策略。节点故障或者节点维护，只能选择硬策略，把故障节点删除