K8S—集群调度

前言

一 List-Watch

1.1 list-watch概述

1.2 list-watch工作机制

二集群调度

2.1 调度过程

2.2 Predicate 和 Priorities 的常见算法和优先级选项

2.3 调度方式

三亲和性

3.1 节点亲和性

3.2 Pod 亲和性

3.3 键值运算关系

3.4 Pod亲和性与反亲和性

3.5 示例

四污点(Taint) 和容忍(Tolerations)

4.1 污点

4.2 容忍

前言

在 Kubernetes 中，List-Watch 是一种 API 操作模式，用于实时监视 Kubernetes 资源对象的变化。List-watch 模式结合了 List 操作和 Watch 操作，允许客户端首先列出（List）资源对象的初始状态，然后通过长连接（Watch）来实时获取这些资源对象的变化情况。

Kubernetes 是通过 List-Watch的机制进行每个组件的协作，保持数据同步的，每个组件之间的设计实现了解耦。

通过 List-Watch 组件，客户端可以实时地监视 Kubernetes 集群中资源对象的状态变化，而无需反复发送 List 请求来轮询资源状态。这种实时监控机制使客户端能够更加高效地响应资源对象的变化，并及时更新本地状态或执行相关操作。

一 List-Watch

1.1 list-watch概述

在 Kubernetes 中，List-watch 是一种机制，用于实现各个组件之间的协作和数据同步。它是 Kubernetes 中的核心概念之一，确保集群中的各个组件保持最新的状态，并能够及时响应变化。

以下是一个简要的概述，涉及了 Kubernetes 中的各个关键组件和它们之间的交互：

用户使用 kubectl：通过配置文件或命令行向 Kubernetes API Server 发送请求，以创建、更新或删除资源对象（如 Pod、Deployment 等）。
API Server：作为 Kubernetes 集群的控制面板，接收来自用户或其他组件的请求。它处理身份验证、授权和访问控制，并根据请求调用相应的资源对象操作。
etcd：Kubernetes 使用 etcd 作为分布式键值存储系统，用于持久化保存集群的状态信息。所有部署和配置信息都会写入 etcd，并通过 Watch 机制发送事件通知给 API Server。
Controller Manager：负责处理集群中的各种控制器，如 ReplicaSet、Deployment、DaemonSet 等。它监听（Watch） API Server 发出的事件，根据需要进行调整，以确保所管理的资源对象处于所需的状态。
Scheduler：负责将新创建的 Pod 分配到合适的 Node 节点上运行。它监听（Watch） API Server 发出的事件，根据调度策略和资源约束选择合适的节点，并将 Pod 分配给该节点。
kubelet：运行在每个 Node 节点上，负责管理节点上的容器和 Pod。它监听（Watch） API Server 发出的事件，确保节点上运行的 Pod 与 API Server 中的状态保持同步。

通过 List-watch 机制，API Server 监听 etcd 和其他组件发出的事件，并相应地发送事件通知给各个组件。这样，各个组件就能够根据事件的变化及时采取相应的操作，以保持集群中的资源对象处于最新的状态。

总之，List-watch 是 Kubernetes 中实现组件之间协作和数据同步的重要机制，通过事件监听和通知，实现了各个组件的解耦和高效的信息交换。这种机制保证了 Kubernetes 集群中各个组件之间的协作和整体的稳定性。

1.2 list-watch工作机制

Pod 是 Kubernetes 的基础单元，Pod 启动典型创建过程如下：

用户通过 kubectl 或其他 API 客户端向 APIServer 提交创建 Pod 对象的请求。
APIServer 将 Pod 对象的元信息存入 etcd 中，并返回确认信息给客户端。
etcd 发送 Create 事件给 APIServer。
Controller Manager 监听 APIServer 发出的事件，并接收到 Create 事件。
Controller Manager 使用 Replication Controller 确保 Node 上的副本数量符合定义，并创建缺少的副本。
APIServer 在 etcd 中记录新创建的 Pod 的详细信息。
etcd 发送创建 Pod 的信息事件给 APIServer。
Scheduler 监听 APIServer 发出的事件，为新创建的 Pod 安排合适的 Node。
Scheduler 更新 Pod 的信息，包括部署到哪个 Node 上。
Scheduler 更新的信息通过 APIServer 更新至 etcd 中保存起来。
etcd 发送更新成功的事件给 APIServer，APIServer 反映 Pod 对象的调度结果。
kubelet 在 Node 上监听 APIServer 发送的 Pod 更新事件，尝试在当前节点上启动容器，并将结果状态回送至 APIServer。
APIServer将 Pod 状态信息存入 etcd，并发送确认信息给相关的 kubelet。

注意：在创建 Pod 的工作就已经完成了后，为什么 kubelet 还要一直监听呢？

这是因为 Kubernetes 是一个动态的容器编排系统，Pod 对象的状态可能会在运行时发生变化，例如副本数量的调整或者镜像文件的更新。因此，kubelet 在 Node 上一直监听 APIServer 发送的 Pod 更新事件，以便及时更新和调整 Node 上的资源，并确保 Pod 的状态始终与期望状态一致。这也是 Kubernetes 能够高效、可靠地管理容器化应用程序的重要原因之一。

二集群调度

2.1 调度过程

Scheduler 是 kubernetes 的调度器，主要的任务是把定义的 pod 分配到集群的节点上。

Kubernetes Scheduler 的主要任务：

公平性：保证每个节点都能被分配到资源。
资源高效利用：最大化集群资源利用率。
效率：具有良好的调度性能，能够快速完成对大批量 Pod 的调度工作。
灵活性：允许用户根据需求控制调度逻辑。

Kubernetes Scheduler 的工作流程：

Scheduler 作为单独的程序运行，持续监听 APIServer 获取未指定 nodeName 的 Pod。
对每个未指定 nodeName 的 Pod，Scheduler 创建一个 binding，指明该 Pod 应该放置在哪个节点上。
调度过程分为以下几个步骤：
①预算策略（predicate）：过滤掉不满足条件的节点。

②优选策略（priorities）：对通过预算策略的节点按优先级排序。

③选择节点：从经过优选策略排序的节点中选择优先级最高的节点。
如果在任何一步骤中出现错误，Scheduler 将直接返回错误信息。

2.2 Predicate 和 Priorities 的常见算法和优先级选项

Predicate 阶段常见的算法：

PodFitsResources：检查节点上剩余资源是否大于 Pod 请求的资源，并检查节点名称是否与 NodeName 匹配。
PodFitsHost：如果 Pod 指定了 NodeName，检查节点名称是否与 NodeName 匹配。
PodFitsHostPorts：检查节点上已使用的端口是否与 Pod 请求的端口冲突。
PodSelectorMatches：过滤掉与 Pod 指定标签不匹配的节点。
NoDiskConflict：确保已挂载的卷和 Pod 指定的卷不冲突，除非它们都是只读的。

注意：在 Predicate 过程中，如果没有合适的节点，Pod 将一直处于 Pending 状态，直到有节点符合条件。如果有多个节点符合条件，将进入 Priorities 阶段进行节点排序。

Priorities 阶段常见的优先级选项：

LeastRequestedPriority：根据 CPU 和内存使用率计算权重，使用率越低权重越高，倾向于选择资源使用较低的节点。
BalancedResourceAllocation：根据节点上 CPU 和内存使用率的接近程度计算权重，使用率越接近权重越高，通常与 LeastRequestedPriority 一起使用。
ImageLocalityPriority：倾向选择已经包含所需镜像的节点，镜像总大小越大，权重越高。

通过计算所有优先级项目和权重的算法，Scheduler 可以确定最终的节点选择结果，以完成 Pod 的调度工作。这些算法和优先级选项有助于实现资源高效利用、公平性和灵活性，确保集群的顺利运行和资源分配。

2.3 调度方式

#指定调度节点

①pod.spec.nodeName 将 Pod 直接调度到指定的 Node 节点上，会跳过 Scheduler 的调度策略，该匹配规则是强制匹配

vim myapp.yaml

apiVersion: apps/v1  
kind: Deployment  
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      nodeName: node01
      containers:
      - name: myapp
        image: soscscs/myapp:v1
        ports:
        - containerPort: 80

kubectl apply -f myapp.yaml

kubectl get pods -o wide

#查看详细事件（发现未经过 scheduler 调度分配）

kubectl describe pod nginx-6799fc88d8-9fsjc

②pod.spec.nodeSelector：通过 kubernetes 的 label-selector 机制选择节点，由调度器调度策略匹配 label，然后调度 Pod 到目标节点，该匹配规则属于强制约束。

#获取标签帮助

kubectl label --help
Usage:
  kubectl label [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--resource-version=version] [options]

#需要获取 node 上的 NAME 名称

#给对应的 node 设置标签分别为 test=a 和test=b

kubectl label nodes node01 test=a

kubectl label nodes node02 test=b

#查看标签

#修改成 nodeSelector 调度方式

vim myapp1.yaml

apiVersion: apps/v1
kind: Deployment  
metadata:
  name: myapp1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp1
  template:
    metadata:
      labels:
        app: myapp1
    spec:
      nodeSelector:
	    kgc: a
      containers:
      - name: myapp1
        image: soscscs/myapp:v1
        ports:
        - containerPort: 80

kubectl apply -f myapp1.yaml 
kubectl get pods -o wide

#查看详细事件（通过事件可以发现要先经过 scheduler 调度分配）

kubectl describe pod myapp1-6799fc88d8-rxjnz

#修改一个 label 的值，需要加上 --overwrite 参数

kubectl label nodes node02 test=a --overwrite

#删除一个 label，只需在命令行最后指定 label 的 key 名并与一个减号相连即可

kubectl label nodes node02 test-

#指定标签查询 node 节点

kubectl get node -l test=a

三亲和性

3.1 节点亲和性

节点亲和性指的是将 Pod 调度到特定节点的策略。在 Kubernetes 中，通过在 Pod 的 spec 中指定 nodeAffinity 字段来实现节点亲和性。

在 preferredDuringSchedulingIgnoredDuringExecution 策略中，可以指定多个 preferred 节点亲和性项，表示希望将 Pod 调度到这些节点上，但如果没有可用的节点满足条件，则仍会调度到其他节点上运行。

在 requiredDuringSchedulingIgnoredDuringExecution 策略中，必须指定至少一个 required 节点亲和性项，如果没有可用的节点满足条件，Pod 将一直处于 Pending 状态，直到有节点符合条件。

pod.spec.nodeAffinity
●preferredDuringSchedulingIgnoredDuringExecution：软策略
●requiredDuringSchedulingIgnoredDuringExecution：硬策略

3.2 Pod 亲和性

Pod 亲和性指的是将 Pod 调度到与其他 Pod 相关的节点的策略。在 Kubernetes 中，通过在 Pod 的 spec 中指定 affinity 字段来实现 Pod 亲和性。

在 podAffinity 策略中，可以指定多个 preferredPodAffinity 和 requiredPodAffinity 项，表示希望将 Pod 调度到与这些 Pod 相关的节点上，但如果没有可用的节点满足条件，则仍会调度到其他节点上运行。

在 podAntiAffinity 策略中，可以指定多个 preferredDuringSchedulingIgnoredDuringExecution 和 requiredDuringSchedulingIgnoredDuringExecution 项，表示希望将 Pod 调度到与这些 Pod 不相关的节点上，以避免出现故障域的单点故障（SPOF）问题。

pod.spec.affinity.podAffinity/podAntiAffinity
●preferredDuringSchedulingIgnoredDuringExecution：软策略
●requiredDuringSchedulingIgnoredDuringExecution：硬策略

注意：节点亲和性和 Pod 亲和性都是在调度期间评估的，即在 Pod 分配给节点前进行评估。一旦 Pod 被调度到一个节点上，它就会一直在该节点上运行，即使后来该节点不再符合亲和性规则。

3.3 键值运算关系

键值对运算关系通常应用于 Kubernetes 中的 label selector 和 field selector，可以用来筛选出符合特定要求的 Pod、Service、Node 等 Kubernetes 对象。具体的键值对运算关系包括：

●In：label 的值在某个列表中

表示希望选择具有 app=label 的 Pod，其中 label 的值为 nginx 或 mysql。

matchExpressions:
  - {key: app, operator: In, values: [nginx, mysql]}

●NotIn：label 的值不在某个列表中

表示希望选择具有 app=label 的 Pod，其中 label 的值不为 redis。

matchExpressions:
  - {key: app, operator: NotIn, values: [redis]}

●Gt：label 的值大于某个值

表示希望选择具有 memory=label 的 Pod，其中 label 的值大于 500Mi。

matchExpressions:
  - {key: memory, operator: Gt, values: [500Mi]}

●Lt：label 的值小于某个值

表示希望选择具有 memory=label 的 Pod，其中 label 的值小于 500Mi。

matchExpressions:
  - {key: memory, operator: Lt, values: [500Mi]}

●Exists：某个 label 存在

表示希望选择具有 app=label 的 Pod，其中 label 存在。

matchExpressions:
  - {key: app, operator: Exists}

●DoesNotExist：某个 label 不存在

表示希望选择不具有 app=label 的 Pod，其中 label 不存在。

matchExpressions:
  - {key: app, operator: DoesNotExist}

3.4 Pod亲和性与反亲和性

调度策略	匹配标签	操作符	拓扑域支持	调度目标
nodeAffinity	主机	In, NotIn, Exists,DoesNotExist, Gt, Lt	否	指定主机
podAffinity	Pod	In, NotIn, Exists,DoesNotExist	是	Pod与指定Pod同一拓扑域
podAntiAffinity	Pod	In, NotIn, Exists,DoesNotExist	是	Pod与指定Pod不在同一拓扑域

kubectl label nodes node01 test=a    pod1   
kubectl label nodes node02 test=b    pod2

#创建一个标签为 app=myapp01 的 Pod

vim pod3.yaml

apiVersion: v1
kind: Pod
metadata:
  name: myapp01
  labels:
    app: myapp01
spec:
  containers:
  - name: with-node-affinity
    image: soscscs/myapp:v1
	

kubectl apply -f pod3.yaml

kubectl get pods --show-labels -o wide

#使用 Pod 亲和性调度，创建多个 Pod 资源

vim pod4.yaml

apiVersion: v1
kind: Pod
metadata:
  name: myapp02
  labels:
    app: myapp02
spec:
  containers:
  - name: myapp02
    image: soscscs/myapp:v1
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - myapp01
        topologyKey: test

#仅当节点和至少一个已运行且有键为“app”且值为“myapp01”的标签的 Pod 处于同一拓扑域时，才可以将该 Pod 调度到节点上。（更确切的说，如果节点 N 具有带有键 kgc 和某个值 V 的标签，则 Pod 有资格在节点 N 上运行，以便集群中至少有一个具有键 test 和值为 V 的节点正在运行具有键“app”和值 “myapp01”的标签的 pod。）
#topologyKey 是节点标签的键。如果两个节点使用此键标记并且具有相同的标签值，则调度器会将这两个节点视为处于同一拓扑域中。调度器试图在每个拓扑域中放置数量均衡的 Pod。
#如果 test 对应的值不一样就是不同的拓扑域。比如 Pod1 在 test=a 的 Node 上，Pod2 在 test=b 的 Node 上，Pod3 在 test=a 的 Node 上，则 Pod2 和 Pod1、Pod3 不在同一个拓扑域，而Pod1 和 Pod3在同一个拓扑域。

#使用Pod反亲和性调度

vim pod5.yaml

apiVersion: v1
kind: Pod
metadata:
  name: myapp10
  labels:
    app: myapp10
spec:
  containers:
  - name: myapp10
    image: soscscs/myapp:v1
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - myapp01
          topologyKey: kubernetes.io/hostname

#如果节点处于 Pod 所在的同一拓扑域且具有键“app”和值“myapp01”的标签，则该 pod 不应将其调度到该节点上。（如果 topologyKey 为 kubernetes.io/hostname，则意味着当节点和具有键 “app”和值“myapp01”的 Pod 处于相同的拓扑域，Pod 不能被调度到该节点上。）

kubectl apply -f pod5.yaml

kubectl get pods --show-labels -o wide

3.5 示例

kubectl get nodes --show-labels

#requiredDuringSchedulingIgnoredDuringExecution：硬策略

mkdir /opt/affinity
cd /opt/affinity

vim pod1.yaml

apiVersion: v1
kind: Pod
metadata:
  name: affinity
  labels:
    app: node-affinity-pod
spec:
  containers:
  - name: with-node-affinity
    image: soscscs/myapp:v1
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/hostname  #指定node的标签
            operator: NotIn #设置Pod安装到kubernetes.io/hostname的标签值不在values列表中的node上
            values:
            - node02


kubectl apply -f pod1.yaml

kubectl get pods -o wide

kubectl delete pod --all && kubectl apply -f pod1.yaml && kubectl get pods -o wide

注意：#如果硬策略不满足条件，Pod 状态一直会处于 Pending 状态。
#preferredDuringSchedulingIgnoredDuringExecution：软策略

vim pod2.yaml

apiVersion: v1
kind: Pod
metadata:
  name: affinity
  labels:
    app: node-affinity-pod
spec:
  containers:
  - name: with-node-affinity
    image: soscscs/myapp:v1
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1   #如果有多个软策略选项的话，权重越大，优先级越高
        preference:
          matchExpressions:
          - key: kubernetes.io/hostname
            operator: In
            values:
            - node03


kubectl apply -f pod2.yaml

kubectl get pods -o wide

#把values:的值改成node01，则会优先在node01上创建Pod

kubectl delete pod --all && kubectl apply -f pod2.yaml && kubectl get pods -o wide

#如果把硬策略和软策略合在一起使用，则要先满足硬策略之后才会满足软策略

apiVersion: v1
kind: Pod
metadata:
  name: affinity
  labels:
    app: node-affinity-pod
spec:
  containers:
  - name: with-node-affinity
    image: soscscs/myapp:v1
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:   #先满足硬策略，排除有kubernetes.io/hostname=node02标签的节点
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/hostname
            operator: NotIn
            values:
            - node02
      preferredDuringSchedulingIgnoredDuringExecution:  #再满足软策略，优先选择有kgc=a标签的节点
	  - weight: 1
        preference:
          matchExpressions:
          - key: kgc
            operator: In
            values:
            - a

四污点(Taint) 和容忍(Tolerations)

4.1 污点

节点亲和性，是Pod的一种属性（偏好或硬性要求），它使Pod被吸引到一类特定的节点。Taint 则相反，它使节点能够排斥一类特定的 Pod。
Taint 和 Toleration 相互配合，可以用来避免 Pod 被分配到不合适的节点上。每个节点上都可以应用一个或多个 taint ，这表示对于那些不能容忍这些 taint 的 Pod，是不会被该节点接受的。如果将 toleration 应用于 Pod 上，则表示这些 Pod 可以（但不一定）被调度到具有匹配 taint 的节点上。
使用 kubectl taint 命令可以给某个 Node 节点设置污点，Node 被设置上污点之后就和 Pod 之间存在了一种相斥的关系，可以让 Node 拒绝 Pod 的调度执行，甚至将 Node 已经存在的 Pod 驱逐出去。
污点的组成格式如下：
key=value:effect
每个污点有一个 key 和 value 作为污点的标签，其中 value 可以为空，effect 描述污点的作用。
当前 taint effect 支持如下三个选项：
●NoSchedule：表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上
●PreferNoSchedule：表示 k8s 将尽量避免将 Pod 调度到具有该污点的 Node 上
●NoExecute：表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上，同时会将 Node 上已经存在的 Pod 驱逐出去。

kubectl get nodes

#master 就是因为有 NoSchedule 污点，k8s 才不会将 Pod 调度到 master 节点上

kubectl describe node master

#设置污点

kubectl taint node node01 key1=value1:NoSchedule

# 节点说明中，查找 Taints 字段

kubectl describe node node-name

#去除污点

kubectl taint node node01 key1:NoSchedule-

kubectl get pods -o wide

kubectl taint node node02 check=mycheck:NoExecute

#查看 Pod 状态，会发现 node02 上的 Pod 已经被全部驱逐（注：如果是 Deployment 或者 StatefulSet 资源类型，为了维持副本数量则会在别的 Node 上再创建新的 Pod）

kubectl get pods -o wide

4.2 容忍

设置了污点的 Node 将根据 taint 的 effect:NoSchedule、PreferNoSchedule、NoExecute 和 Pod 之间产生互斥的关系，Pod 将在一定程度上不会被调度到 Node 上。但我们可以在 Pod 上设置容忍(Tolerations)，意思是设置了容忍的 Pod 将可以容忍污点的存在，可以被调度到存在污点的 Node 上。

#在两个 Node 上都设置了污点后，此时 Pod 将无法创建成功

kubectl get pods -o wide

vim pod3.yaml

apiVersion: v1
kind: Pod
metadata:
  name: myapp01
  labels:
    app: myapp01
spec:
  containers:
  - name: with-node-affinity
    image: soscscs/myapp:v1
  tolerations:
  - key: "check"
    operator: "Equal"
    value: "mycheck"
    effect: "NoExecute"
    tolerationSeconds: 3600

kubectl apply -f pod3.yaml

#其中的 key、vaule、effect 都要与 Node 上设置的 taint 保持一致
#operator 的值为 Exists 将会忽略 value 值，即存在即可
#tolerationSeconds 用于描述当 Pod 需要被驱逐时可以在 Node 上继续保留运行的时间

#在设置了容忍之后，Pod 创建成功