k8s调度、污点、容忍、不可调度、排水、数据卷挂载

一、Kubernetes的list-watch机制

1、List-watch

K8S集群中，通过List-watch机制进行每个组件的协作，保持数据同步。这种设计可以实现每个组件之间的解耦

kubectl配置文件，统一向集群内部apiserver发送命令——通过apiserver把命令发送到各个组件

创建成功之后，kubectl get pod，kubectl describe pod nginx查看信息——在ETCD数据库中

List-watch会在每一步把监听的消息（apiserver:6443）——组件controller-manager、schedule、kubelet、ETCD都会监听apiserver的6443端口

2、创建pod的过程：

1、客户端向apiserver发送创建创建pod的请求，然后apiserver将请求信息存入到ETCD中

2、存入完之后，ETCD会通过apiserver发送创建pod资源的事件

3、controller-manager通过List-watch机制监听apiserver发送出来的事件，并创建相关的pod资源。创建完成之后，通过apiserver将信息存入到ETCD中

4、ETCD存入更新信息之后，再次通过apiserver发送调度pod资源的事件到scheduler

5、scheduler通过List-watch机制监听到apiserver发出的调度事件，通过调度算法，将pod资源调度到合适的node节点上，调度完成后通过apiserver将调度信息更新到ETCD中

6、ETCD收到更新信息后，再次向apiserver发出的创建pod的事件

7、kubelet通过List-watch机制监听apiserver发出的创建pod的事件，然后根据事件信息，在相应的node节点完成pod的创建

二、scheduler调度的过程和策略：

1、简介

scheduler是K8S集群的调度器，把pod分配到集群的节点

调度规则：

公平，每个节点都能够分配资源
资源高效利用，集群中的资源可以被最大化使用
效率：调度的性能要好，能够尽快的完成大批量pod的调度工作
灵活：允许用户根据自己的需求，控制和改变调度的逻辑

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

有两种策略：预算策略、优选策略

scheduler是一个单独运行的程序，只要启动之后就会一直监听apiserver。获取报文中的字段：spec中的nodeName字段

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

创建pod到节点时，有两个策略

先执行预算策略，在执行优先策略。这两步的操作都必须成功，否则立刻返回报错

部署的node必须满足这两个策略，少一个都不行

2、预算策略：predicate

自带一些算法，选择node节点，是scheduler自带的算法策略，不需要人工干预

podfitsresources：pod的适应策源，检查节点上剩余的资源是否满足pod请求的资源（主要是CPU和内存）
podfitshost：po适应主机，如果pod指定了node的name，检测主机名是否存在，如果存在要和pod指定的名称匹配，这才能调度过去
podselectormarches：pod选择器匹配，创建pod的时候，可以根据node'节点的标签来进行匹配。他查找指定的node节点上标签是否存在。存在的标签是否匹配
nodeskconflict：无磁盘冲突，确保已挂载的卷和pod卷不发生冲突。除非目录是只读

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

若三个node节点都满足——>优选策略

3、优先策略：

3.1、leastrequestedpriority：

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

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

3.2、balanceresourceallocation：

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

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

举例：

node1 CPU和内存使用率：20 60

node2 CPU和内存使用率：50 50

node2的内存和CPU使用率接近，权重高，会被选择

3.3、imagelocalitypriority：

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

以上三个策略都是scheduler自带的算法，自动的

4、选择的过程：

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

三、kubernetes对Pod的调度策略

在 Kubernetes 中，调度是指将 Pod 放置到合适的节点上，以便对应节点上的 Kubelet 能够运行这些 Pod。

1）定向调度：使用 nodeName 字段指定node节点名称；使用 nodeSelector 字段指定node节点的标签；

2）亲和性调度：使用节点/Pod 亲和性（NodeAffinity、PodAffinity、PodAntiAffinity）；

3）污点与容忍：使用节点设置污点，结合 Pod设置容忍。

4）全自动调度：运行在哪个节点上完全由Scheduler经过一系列的算法计算得出；

#补充，Pod和node的关系
Node 是 Kubernetes 集群中的工作节点
一个 Node 可以运行多个 Pod，而一个 Pod 只能运行在一个 Node 上
使用标签和选择器可以管理 Node 和 Pod 之间的关系，从而实现灵活的调度和管理。

四、定向调度

1、调度策略简介：

nodeName：指定节点名称，用于将Pod调度到指定的Node上，不经过调度器。

nodeSelector：在 Pod 定义文件的 spec 下的 nodeSelector 字段中设置一个标签选择器，在 Pod 调度的时候，只有具有这些标签的 Node 才会被考虑用来运行这个 Pod。

2、指定节点：

spec参数设置：

nodeName: node2

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

3、指定标签：

spec参数设置：

nodeSelector:

节点自定义标签：

kubectl label nodes master01 test1=a
kubectl label nodes node01 test2=b
kubectl label nodes node02 test3=c
kubectl get nodes --show-labels
#查看节点的标签

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

五、亲和性调度：

1、介绍：

两种亲和性：节点亲和性和pod亲和性

两种策略：软策略和硬策略

node节点的亲和性：

preferredDuringSchedulingIgnoredDuringExecution：软策略

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

requiredDuringSchedulinglgnoredDuringExecution：硬策略

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

pod的亲和性：

preferredDuringSchedulingIgnoredDuringExecution：软策略

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

requiredDuringSchedulingIgnoredDuringExecution：硬策略

要求调度器将pod调度到其他pod的亲和性匹配的节点上，强制性满足

2、键值的运算关系：

都是根据标签来选择node或者pod的亲和性

In（大写的i）：在，选择的标签值在node节点上存在
Notin：不在，选择label的值不在node节点上
Gt：大于，要大于选择的标签值，只能比较整数
Lt：小于，要小于选择的标签值，只能比较整数
Exists：存在，只是选择标签对象，不考虑值
DoesNotExist：不存在，选择不具有指定标签的对象。不考虑值

3、node亲和性实例

node亲和性的硬策略：

in策略：

apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx:1.22
name: nginx
affinity:
#选择亲和性部署方式
nodeAffinity:
#选择的是node节点的亲和性
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
#选择了亲和性的策略。nodeSelectorTerms你要选择哪个node作为硬策略。匹配的节点标签
- matchExpressions:
#定义了一个符合我要选择的node节点信息
- key: test3
operator: In
#指定键值对的算法
values:
- c

硬限制选择test3=c的节点

Notin：

notin，只要不在test3=c的节点，都能够部署

删除节点上的标签：

kubectl label nodes master01 test1-
kubectl label nodes node01 test2-
kubectl label nodes node02 test3-

更改标签名：

kubectl label nodes node02  memory=1000 --overwrite

Gt：

affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: memory
operator: Gt
values:
- "612"

大于612节点上部署

Exists：

affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: memory
operator: Exists
#指定键值对的算法为Exists或DoesNotExist，不能使用values字段

DoesNotExist：

affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: memory
operator: DoesNotExist

软策略：

affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: memory
operator: In
values:
- "1000"
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 10
preference:
matchExpressions:
- key: memory
operator: In
values:
- "500"

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

硬策略和软策略一起执行：

先满足硬策略，再考虑软策略。若硬策略无法满足，软策略一个都不会执行

面试题：

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

根据node的亲和性：

性能不一致，尽量把pod往性能高的多部署，选择软策略

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

4、pod亲和性实例

4.1、pod的亲和性和反亲和性：

调度策略：	匹配标签	操作符	拓扑域	调度目标
node的亲和性	主机标签	In、NotIn、Exists、DoesNotExist、Gt、Lt	不支持	指定主机
pod的亲和性	pod的标签	In、NotIn、Exists、DoesNotExist	支持	pod和指定标签的pod部署在同一个拓扑域
pod的反亲和性	pod的标签	In、NotIn、Exists、DoesNotExist	支持	pod和指定标签的pod部署在不同一个拓扑域

4.2、拓扑域：

K8S集群节点当中的一个组织结构，可以根据节点的物理关系或者逻辑关系进行划分

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

这里pod的亲和性的拓扑域是标签

4.3、pod的亲和性实例：

1、In

apiVersion: apps/v1

kind: Deployment

metadata:

labels:

app: nginx

name: nginx

spec:

replicas: 3

selector:

matchLabels:

app: nginx

template:

metadata:

labels:

app: nginx

spec:

containers:

- image: nginx:1.22

name: nginx

affinity:

podAffinity:

requiredDuringSchedulingIgnoredDuringExecution:

- labelSelector:

matchExpressions:

- key: app

operator: In

values:

- nginx

topologyKey: test1

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

2、Exists

满足test1节点，且满足pod标签等于app的

affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: Exists
topologyKey: test1

软策略：

表示尽量选择满足不存在app的pod标签的并且是满足test1的节点的

   affinity:

        podAffinity:

          preferredDuringSchedulingIgnoredDuringExecution:

          - weight: 1

            podAffinityTerm:

              labelSelector:

                matchExpressions:

                - key: app

                  operator: DoesNotExist

              topologyKey: test1