k8s的集群调度

k8s的集群调度?

scheduler：负责调度资源，把pod调度到node节点

预算策略

优先策略

1、List-watch

k8s集群当中，通过list-watch的机制进行每个组件的协作，保持数据同步。每个组件之间的解耦

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

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

创建成功之后，kubectl get pod kubectl describe pod nginx----------etcd的数据库当中

list-watch-----会在每一步监听的消息（APIserver:6443）------controller ?manager ?scheduler ?etcd都会监听apiserver:6443端口

2、调度的过程和策略：

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

以下几个问题：

（1）公平，每个节点都能公平分配资源

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

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

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

如何把pod分配到node

scheduler是一个单独允许的程序，启动之后就会一直监听APIserver，获取报文中的字段：sper.nodeName

创建pod时，会为每个pod创建一个binding，binding表示该往哪个节点上部署

创建pod到节点时，有两个策略，先执行预算策略，再执行优先策略。这两步的操作都必须成功，否则立刻返回报错（也就是说，部署的node，必须满足这两个策略）

预算策略：

predicate自带一些算法，选择node节点（scheduler自带的算法策略。不需人工干预）

1、podfitsresources：pod适应资源，检查节点上的剩余资源是否满足pod请求的资源。主要是cpu和内存

2、podfitshost：pod适应主机，如果pod指定了node的name，nginx1 pod---->node01，检测主机名是否存在，存在要和pod指定的名称匹配，这样才能调度过去

3、podselectormatches：pod选择器匹配，创建pod的时候，可以根据node节点的标签来进行匹配。查找指定的node节点上标签是否存在，存在标签是否匹配

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

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

优先策略：

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

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

balanceresourceallocation：平衡资源分配，cpu和内存的使用率。给节点赋予权重。权重算的是cpu和内存使用率接近。权重越高（和上面的leastrequestedpriority最低请求优先级一起使用）

node1 ?cpu和内存使用率：20：60

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

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

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

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

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

指定节点：

spec参数设置：

nodeName：node02

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

指定标签：

spec

nodeSelector

等于什么就是标签

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

自定义标签：

亲和性：

节点亲和性

pod亲和性

软策略和硬策略

node节点的亲和性：

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

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

pod的亲和性：

preferredDuringSchedulingIgnoredDuringExecution：软策略

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

requiredDuringSchedulingIgnoredDuringExecution：硬策略

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

键值的运算关系：

In（大写的i）：在

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

Notin：不在

选择label的值不在node节点上

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

Lt：小于选择的标签值

只能比较整数值

亲和性策略根据标签来进行选择

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

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

affinity：（选择亲和性部署方式）

nodeAffinity：（选择的是node节点的亲和性）

nodeSelectorTerms：（你要选择哪个node做硬策略，匹配的节点的标签）

- matchExpressions：（定义一个符合我要选择的node节点的信息）

- key： test3

operator：In

values：

- c

删除标签：

修改标签：

硬策略：

要先加上硬策略，才可以使用条件

软策略的方式：

中间加的

软策略和硬策略的部署：

或

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

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

面试题：

你在部署pod的时候选择什么样的策略？

node的亲和性：性能不一致，我尽量把pod往性能高的多部署 软策略

???????????????节点故障或者节点维护，只能选择硬策略，把故障节点剔除