目录

一、Kubernetes的list-watch机制

1、List-watch

2、创建pod的过程：

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

1、简介

2、预算策略：predicate

3、优先策略：

3.1、leastrequestedpriority：

3.2、balanceresourceallocation：

3.3、imagelocalitypriority：

4、选择的过程：

三、kubernetes对Pod的调度策略

四、定向调度

1、调度策略简介：

2、指定节点：

3、指定标签：

五、亲和性调度：

1、介绍：

2、键值的运算关系：

3、node亲和性实例

---

一、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分配到集群的节点

调度规则：

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

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

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

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

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

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

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

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

2、预算策略：predicate

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

1. podfitsresources：pod的适应策源，检查节点上剩余的资源是否满足pod请求的资源（主要是CPU和内存）
2. podfitshost：po适应主机，如果pod指定了node的name，检测主机名是否存在，如果存在要和pod指定的名称匹配，这才能调度过去
3. podselectormarches：pod选择器匹配，创建pod的时候，可以根据node'节点的标签来进行匹配。他查找指定的node节点上标签是否存在。存在的标签是否匹配
4. 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的亲和性

1. In（大写的i）：在，选择的标签值在node节点上存在
2. Notin：不在，选择label的值不在node节点上
3. Gt：大于，要大于选择的标签值，只能比较整数
4. Lt：小于，要小于选择的标签值，只能比较整数
5. Exists：存在，只是选择标签对象，不考虑值
6. 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

反亲和性：

表示反转，满足哪个就不去哪个

软策略反亲和性：

硬策略反亲和性：

注意点：

1. pod的亲和性策略，在配置时，必须要加上拓扑域的关键字topologykey，指向的是节点标签
2. pod亲和性的策略分为硬策略和软策略
3. pod亲和性的NotIn可以替代反亲和性
4. pod亲和性主要是为了把相关联的pod组件部署在同一节点上。lnmp

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

软硬策略

污点和容忍

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

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

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

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

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

六、taint

1、taint种类：

1. NoSchedule：K8S不会把pod调度到这个节点上
2. PreferNoschedule：尽量避免把pod部署在该节点上，不是一定（master节点一般设这个）
3. NoExecute：如果污点类型是他，K8S将会把该节点上的pod驱逐出去，而且也不会调度到这个节点

2、NoExecute驱逐：

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

如果是自主式pod，会被直接杀死

注意点：节点服务器需要维护的，服务器要关机，节点上的业务将会失效。在工作中主要部署pod的方式是控制器部署，尤其deployment控制器最多。

一旦设置为驱逐，控制器创建的pod会在其他节点重新部署。所以驱逐的业务主要用在业务维护，和业务回收

驱逐是所有的pod全部被驱逐，跟命名空间无关，所有的都会被驱逐。

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

但是系统集群组件不会被驱逐

3、污点相关命令：

#创建污点
kubectl taint node node01污点种类

#删除污点
kubectl taint node node01 key:NoSchedule-

#查看污点
kubectl describe nodes node01  | grep -i taints

1、NoSchedule污点

相当于硬策略，不会部署在该节点

kubectl taint node node01 key=1:NoSchedule

2、PreferNoSchedule污点

相当于软策略，尽量避免把pod部署在该节点上，不是一定（master节点一般设这个）

kubectl taint node node01 key=1:PreferNoSchedule

3、NoExecute污点

驱逐污点，配置之后，驱逐该节点上的pod，并且之后不会再部署到该节点上

kubectl taint node node01 key1=2:NoExecute

所有node1上的pod全部被驱逐，自主式pod全部被删除

七、容忍：

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

特殊情况：NoExecute依然可以部署pod，但是有生命周期，时间一到，pod会被销毁然后重新拉起

生命周期结束之后，会驱逐一部分pod到其他节点， *有的节点还是会保持在污点之上

适用于该节点维护完毕，测试一下该节点工作是否正常

实验：

三个节点都设置污点NoSchedule

测试驱逐污点，能不能容忍

设置NoExcute驱逐污点，必须要设置时间限制

      tolerations:
      - key: key
        operator: Equal
        value: "1"
        effect: NoExecute
        tolerationSeconds: 36

这种格式表示会容忍所有污点的key，key对应的节点的污点的类型是NoSchedule

没有key，不匹配节点的标签，会容忍所有污点，但是类型是指定的类型

    

      tolerations:
      - operator: Exists
        effect: NoSchedule

没有要匹配的污点类型：

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

      tolerations:
      - key: key
        operator: Exists

node的亲和性

pod的亲和性和发亲和性

污点和容忍

以上都是如何选择node节点部署pod

选择一个期望的节点来部署pod

适用场景举例：

多个master节点：

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

尽量不往master节点上部署pod，但是不一定。防止资源浪费，也可以自定义一个标签

业务维护：

node02需要维护2个小时

但是这个节点上还有业务pod在运行

就需要把这个节点的污点，设置为驱逐：NoExecute

将该节点上的pod全部赶走

我们部署pod一般都是使用deployment控制器部署，若是控制器部署，会在其他节点重新部署，并不是被杀死。自主式的pod会被删除

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

八、cordon和drain：

cordon：可以把节点标记为不可用状态

#标记节点为cordon不可部署

kubectl cordon master01 node01

#取消标记
kubectl uncordon master01 node01

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

1. 一旦执行了drain，被执行的节点会变成不可调度状态
2. 会驱逐该节点上的所有pod

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

drain：开始排水，标记node节点为不可调度，然后驱逐pod
 --ignore-daemonsets：忽视daemonset方式部署的pod，daemonset部署的pod不会被转移（daemonset要部署的一般是重要的后台运行的，系统pod，所以不动）
--delete-local-data：有本地挂载的pod会被强制杀死
--force：强制释放不是控制器管理的pod

#取消drain：
kubectl uncordon node02