【K8S 云原生】Kurbernets集群的调度策略

目录

一、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往性能高的多部署，选择软策略

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