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

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

反亲和性：

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

软策略反亲和性：

硬策略反亲和性：

注意点：

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

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

软硬策略

污点和容忍

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

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

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

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

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

六、taint

1、taint种类：

NoSchedule：K8S不会把pod调度到这个节点上
PreferNoschedule：尽量避免把pod部署在该节点上，不是一定（master节点一般设这个）
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节点上运行

一旦执行了drain，被执行的节点会变成不可调度状态
会驱逐该节点上的所有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