k8s的集群调度:

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

预算策略

优先策略

1、List-watch

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

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

list-watch---会在每一步把监听的消息（APIservice：6443）---controller manager，schedler，kubectl，etcd都会监听apiservice：6443

各个组件（除了客户端）都监听apiservice端口

只有apiservice对etcd有读写信息

如何来把pod分配到node

2，调度的过程和策略：

scheduler是k8s集群的调度器，工作就是把pod分配到集群的节点。

要考虑以下几个问题：

1，公平，每一个节点都能被分配资源

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

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

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

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

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

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

node1 node2 node3

经过预算策略，.上述三个节 点都满条件,那该怎么办?--->优选。

优先策略：

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

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

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

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

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

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

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

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

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

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

指定节点：

spec参数设置：

指定nodeName

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

指定标签：

spec

nodeSelector：

节点本身就有标签

查看所有节点的标签。

kubectl get nodes --show-labels

给指定节点自定义标签

kubectl label nodes node01 test1=a

kubectl label nodes node02 test2=b

选择标签：

标签选择，还是会进入scheduler的算法，如果节点不满足条件，pod会进入pending状态。直到节点满足条件为止。

要通过scheduler调度器来调度

亲和性：

节点亲和性

pod亲和性

软策略和硬策略

node节点的亲和性：

preferredDuringSchedulingIgnoredDuringExecution软策略：

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

requiredDuringSchedulingIgnoredDuringExecution硬策略：

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

pod的亲和性：

preferredDuringSchedulingIgnoredDuringExecution软策略：

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

requiredDuringSchedulingIgnoredDuringExecution硬策略：

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

键值的运算关系：

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

In：在

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

Notin：不在

选择label的值不在node节点上

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

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

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

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

affinity:

#选择的亲和性的部署方式：

nodeAffinity:

#选择的是node节点的亲和性：

requiredDuringSchedulingIgnoredDuringExecution:

nodeSelectorTerms:

#选择了亲和性的策略。nodeSelectorTerms你要选择哪个node做为硬策略。匹配的节点的标签。

- matchExpressions:

#定义一个符合我要选择的node节点的信息

- key: test1

operator: In

#指定键值对的算法

values:

- a

也是通过调度器

硬策略，

换成notin

选择标签不是test1=a上的节点

删除节点上的标签：

覆盖标签

加上一个overwrite

比较数字：

大于

只要大于就可以

小于

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

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

只能比较整数值

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

报错

#指定键值对的算法为Exists' Ior ' DoesNotExist'不能使用values字段

选择存在memory的节点

选择没有memory的节点

如果不满足就会进入pending状态

软策略：

选择策略之后要给他一个权重，

- weight: 1

preference:

#选择节点的倾向，尽量满足要求而不是一定

尽量满足不是一定。

可以多个软策略一起执行

以权重高的为准。

选择权重大的来部署

当硬策略和软策略一起的时候

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

硬策略：

先满足硬策略，在满足软策略，不满足硬策略的情况下，软策略也不会满足。

面试题：你在部署pod的时候选择什么样的策略：

node的亲和性：

在性能有高低的时候，选用软策略，尽量把pod往性能高的多部署。

当有node节点故故障，或者节点维护中之后，用硬策略来选择，把故障节点剔除。

schedule的调度算法。

预算策略

过滤出合适的节点

优先策略

选择部署的节点

nodeName：硬匹配，不走调度策略。node01.

nodeSelector：根据节点的标签选择，会走调度算法。

只要是走调度算法，在不满足预算策略的情况下，所有pod都是pending

node节点的亲和性：

硬策略：必须满足的条件。匹配原则也是根据节点的标签。

软策略：尽量满足要求。不是一定

以上是node节点

pod的亲和性和反亲和性

调度策略： 匹配标签 操作符： 拓扑域 调度目标

node的亲和性 主机标签 In NotIn Exist DoesNotExist Gt Lt 不支持 指定主机

pod的亲和性 pod的标签 In NotIn Exist DoesNotExist 支持 pod和指定标签的pod部署在同一个拓扑域

pod的反亲和性 pod的标签 In NotIn Exist DoesNotExist 支持 pod和指定标签的pod部署在不同的拓扑域

pod的亲和性：

使用硬策略

podAffinity

拓扑域: k8s集群节点当中的一个组织结构,可以根据节点的物理关系或者逻辑关系进行划分。

可以用来表示节点之间的空间关系，网络关系或者其他类型的关系。

标签。主机标签。

topologyKey：指定拓扑域的关键字，表示正在使用test1作为拓扑域的关键字。test1一般是节点标签，表示希望把pod调度到包含有app标签的pod，值为nginx的在test1的拓扑域上的节点。

都部署在拓扑域有test1的关键字

用Exists

将标签改一下：

两个node节点标签相同

两都满足，系统会在次选择一个资源较好的节点会部署在一个node节点上

不存在标签才会部署

都有标签会进入pending状态，不用。

使用软策略

软策略还可以部署，不是绝对

使用In

也不是绝对。

反亲和性：

podAntiAffinity

和亲和性的Notin一样的

注意点：

1，pod的亲和性策略，在配置时，必须要加上拓扑域的关键字topologyKey指向的是节点标签

2，pod亲和性的策略分为硬策略和软策略。

3，pod亲和性的notin可以代替反亲和性。

4，pod亲和性主要是为了把相关联的pod部署在同一节点。lnmp

你在进行部署的时候怎么考虑node节点：

污点和容忍，可以配合node节点的亲和性一块使用。

污点：是node的调度机制，不是pod。

被设为污点的节点，不会部署pod。

污点和亲和性相反，亲和性是尽量选择和一定选择

污点的节点一定不会选择？

污点的taint三种类型：

1，NoSchedule：k8s不会把pod调度到这个节点上。

2，PreferNoSchedule：如果污点类型是他，只是尽量避免把pod部署在该节点上。不是一定。（master节点的污点就是这个）

3，*NoExecute：如果你这个污点类型是它，k8s会把该节点上的pod全部驱逐出去，而且也不会调度到这个节点。

面试：驱逐使用的场景：

注意点：节点服务器需要维护的，服务器关机，节点上pod将会失效。在工作中我们主要部署pod的方式的控制器部署。deplayment最多的。一定节点设置为驱逐，控制器会在其他节点重新部署

所有的pod都会被驱逐，跟命名空间无关。所有的一起斗会被驱逐

不论你的创建方式是什么，都会被驱逐

系统集群组件不会被驱逐（kube-proxy）

基于控制器创建的pod，虽然被驱逐，会在其他节点重新部署

基于pod创建的会直接被杀死

查看节点是否为污点

设置污点：

kubectl taint node node01 key=1:NoSchedule

把node01为NoSchedule污点类型

创建pod

kubectl create deployment nginx2 --image=nginx:1.22 --replicas=3

node01上一个都没有

去除污点：

kubectl taint node node01 key:NoSchedule-

又可以部署了

第二种：PreferNoSchedule

kubectl taint node node01 key=1:PreferNoSchedule

尽量不去，不是一定不去

第三种：

驱逐：

一开始：

kubectl taint node node02 key=1:NoExecute

node02上的全部赶走，到别的节点上

容忍：

即使节点上设置了污点，有了容忍机制，依然可以在设置为污点的节点上部署pod.

特殊情况：NoExecute依然可以部署pod，但是有生命周期，时间一到，pod会被销毁。生命周期结束之后，会驱逐一部分到其他节点。有的节点还是在源节点上。

可用于节点维护完毕，测试一下节点的工作是否正常。

把所有节点全都设置为污点：

kubectl taint node node01 key=1:NoSchedule

kubectl taint node node02 key=2:NoSchedule

配置容忍：

effect

容忍策略:容忍节点.上的标签key,对应的标签值是1，effect就是对应的污点的类型。

容忍的类型为NoSchedule，且有key标签，且标签的值为1

设为NoEcute，一定要加上时间，容忍时间。

kubectl taint node node01 key=1:NoExecute

还在超过时间之后，pod被驱逐，会在其他节点重新拉取。没有驱逐走的再到了时间再驱逐。会一直重复。

如果就一个副本

一样的一直重复

污点容忍的机制：

没有key，不匹配节点的标签，容忍使用指定污点类型的污点

会容忍污点的key，key对应的节点的污点的类型是NoSchedule

旨定key的值，指标节点的标签值，但是不指定污点的类型，那么所有节点上只要包含了这个指定的标签名，可以容忍含有标签的所有的污点

只要包含key

不再会被驱逐，容忍所有的污点。

node的亲和性

pod的亲和性和反亲和性

污点和容忍

然后选择node节点部署pod

选择一个期望的节点来部署pod（根据实际情况）

污点的作用

多个master节点：

kubectl taint node master节点名称 node-role.kubernetes.io/master=:PreferNoSchedule

尽量不往master节点上部署pod,但是不是一定的。 防止资源浪费。

业务维护：

node02需要维护2个小时。但是这个节点上还有pod在运行。

就需要把这个节点的污点设置为：NoExecute。

我们部署pod一般都是使用deployment部署，会在其他的节点重新部署，并不是被杀死

自主式的pod会被杀死。

一旦节点恢复，一定要把污点去除

cordon和drain

cordon:可以直接把节点标记为不可部署状态

把节点设置为

kubectl cordon node01

删除的时候出现了一个新的污点：

删除：

kubectl create deployment nginx1 --image=nginx:1.22 --replicas=3

原有的pod不会有影响

取消cordon状态

kubectl uncordon node01

drain：排水，把该节点下的pod全部转移到其他的节点上运行。

1，一旦执行了drain，被执行的节点会变成不可调度状态

2，会驱逐该节点上的所有pod

kubectl drain node02 --ignore-daemonsets --delete-emptydir-data --force

drain：排水，标记node节点为不可调度，然后驱逐pod

--ignore-daemonsets：无视daemonsets部署的pod，daemonsets部署的pod还在节点上。

--delete-local-data：本地挂载的pod会被强制杀死

--force: 强制释放不是控制器管理的pod.

全都排到node01上了

node节点的状态

改回来

目的，还是来管理和部署pod

面试会问：

node亲和性

pod的亲和性和反亲和性

污点：NoExecute

cordon

drain

他们都有软策略和硬策略

如何部署pod是比重要的集群资源的调度机制，合理的配置pod的调度机制可以使得资源最大化利用。