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-------->etcd的数据库当中。

list-watch---会在每一步把监听的消息（APIserver：6443）------controller manager ,scheduler .kubelet，etcd都会监听apiserver:6443端口

2、调度的过程和策略

scheduler是k8s集群的调取器，把pod分配到集群的节点

以下几个问题：

1、公平，每个节点都能够分配资源

2、资源高效利用：集群当中的资源可以被最大化使用

3、效率：调度的性能要搞好，能够尽快的完成大批量的pod的调度工作

4、灵活：允许用户根据自己的需求，控制和改变调度的逻辑。

scheduler是一个单独运行的程序，启动之后就会一直监听APIserver.获取报文中的字段：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、podeslectormatchers:pod选择器匹配，创建pod的时候可以根据node的标签来进行匹配。查找指定的node节点上标签是否存在，存在的标签是否匹配。

4、nodiskconflict：无磁盘冲突，确保已挂载的卷与pod的卷不发生冲突,除非目录是只读

如果预算策略都不满足，pod将始终处于pending状态，不断的重试调度，直到有节点满足条件为止

node1 node2 node3

经过预算策略，上述三个节点都满足，那该怎么办？---->优选

优先策略

leastrequestedpriority：最低请求优先级，通过算法计算节点上的cpu内存使用率，确定节点的权重

使用率越低的节点相应的权重越高。调度时会更倾向于使用率低的节点。实现资源合理的利用

balanceresourceallocation：平衡资源分配，cpu和内存的使用率，给节点赋予权重，权重算的是cpu和内存使用率接近。权重越高

和上面的leastrequestedpriority最低请求优先级一起使用

node1 cpu和内存使用率:20:60

node2 cpu和内存使用率：50:50

node2在被调度时会被优先选择。

imagelocalitypriority：节点上是否已经有了要部署的镜像。镜像的总数成正比，满足的镜像数越多，权重越好

nginx:1.22

node1 无

node2 有

以上这些策略scheduler自带的算法

通过预算选择出可以部署的节点，再通过优先选择出来最好的节点，以上都是自带的算法。k8s集群自己来选择

指定节点：

spec参数设置：

nodeName:node02

指定了节点，在参数中设置了nodeName,指定了节点的名称，会跳过scheduler的调度策略，这个规则是强制匹配

指定标签：

spec

nodeSelector:kubectl get nodes --show-labels 查看所有节点的标签

kubectl label nodes master01 test1=a kubectl label nodes node01 test2=b kubeclt label nodes node02 test3=c

以上三行，创建自定义标签的命令

kubectl get deployment.apps -o wide 可以看到已经部署的deployment的标签

nodeSelector:

指定节点标签部署pod，是要经过scheduler的算法，如果节点不满足条件，pod会进入pending状态，直到节点满足条件为止

亲和性：

节点亲和性和pod亲和性

软策略与硬策略

node节点的亲和性：

preferredDuringSchedulingIgnoredDuringExecution 软策略：

选择node节点时，我声明了我最好能部署在Node01,软策略会尽量满足这个条件。不一定会完全部署在node01节点上

requiredDuringSchedulinglgnoreFuringExecution 硬策略：

选择pod时，声明了node01,我是硬策略，必须满足硬策略的条件。必须部署在node01,强制性要求

pod的亲和性：

preferredDuringSchedulingIgnoredDuringExecution 软策略

要求调度器将pod调度到其他pod的亲和性匹配的节点上。可以是，也可以不是，尽量满足

pod nginx1 node01

pod nginx2 nginx2希望跟nginx1部署在一个节点上，尽量满足。

requiredDuringSchedulinglgnoreFuringExecution 硬策略

要求调度器将Pod调度到其他pod的亲和性匹配的节点上。必须是

pod nginx1 node01

pod nginx2 nginx2必须要和nginx的亲和性匹配，只能往node01

键值的运算关系：

标签，都是根据标签来选择亲和性

In：在

选择的标签值在node节点上存在

Notin:不在

选择label的值不在node节点上存在

Gt:大于，大于选择的标签值

Lt:小于，小于选择的标签值

Exists：存在，选择标签对象，值不考虑

DoesNotExist:不存在，选择不具有指定标签的对象。值不考虑。

软策略：

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

硬策略：

先满足硬策略，再考虑软策略