k8s的集群调度：

k8s的集群调度：

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端口

List-watch机制：

调度的过程和策略：

如何来把pod分配到node：

Scheduler是集群的调度器，他的意义就是把pod分配到集群的节点

以下几个问题：

1. 公平：每个节点都能够公平的分配资源
2. 资源高效利用：集群当中的资源可以被最大化使用
3. 效率：调度的性能要好，能够尽快的完成大批量的调度工作
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---->node1，检测主机名是否存在，存在要和pod指定的名称匹配，这才能调度过去
3. Podselectormatches：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：有

Node2的优先级比较高

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

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

指定节点：

Spec参数设置

问：它走不走scheduler的调度策略

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

如何对标签进行指定

指定标签:

spec

nodeSelector:

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

实现：查看节点的标签

手动添加自定义标签：

查看已经部署的服务的标签：

选择标签部署我们的pod：

标签选择要走scheduler调度算法的

亲和性：

节点亲和性：

Pod亲和性：

软策略和应策略：

Node节点的亲和性：

软策略：preferredDuringSchedulingIgnoredDuringExecution

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

硬策略：

选择pod时，声明了硬策略，必须满足硬条件，必须部署在node01.可以理解成一个强制的要求

Pod的亲和性：

软策略

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

Pod nginx1 node1

Pod nginx2 nginx2希望和nginx1部署在一个节点，尽量满足

硬策略：requiredDuringSchedulingIgnoredDuringExecution

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

Pod nginx1 node1

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

键值的运算关系：

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

In:在

Notin:不在

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

选择label的值不在node节点上

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

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

Exsts:存在，选择标签镜像，值不考虑

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

Lt和gt只能比较整数值，亲和性策略根据标签来进行选择

硬策略：

还是要经过scheduler

修改键值对算法

删除标签：

强制覆盖标签：

演示：

Lt和gt只能比较整数值，亲和性策略根据标签来进行选择

小于612的部署

运行yml脚本报错：

指定键值对的算法为Exist或者DoesNotExist不能使用values字段

修正版

软策略的写法：

根据硬策略修改：

多个软策略：以权重高为标的

硬策略和软策略联合：

多个软策略看权重，权重高执行指定的软策略，硬策略，先满足硬策略，再满足软策略，硬策略无法满足，软策略一个都不执行

面试题：

你在部署pod的时候如何选择策略：

Node的亲和性：性能不一致，尽量把pod往性能高的多部署，软策略，节点故障，或者节点维护中，又要部署业务，只能选择硬策略，把故障节点剔除

举例说明：

如上图所示，如果性能有差别，可以使用软策略，部署在四核八G当中