Kubernetes节点与 Pod 亲和性

首先来个一句话总结：亲和性调度就像关系亲密的闺蜜，你去哪儿我也去哪儿。反亲和性调度就像赌气的两个孩子，赌气永远不在一起玩儿。

1、调度Pod的主要方式

Pod调度到指定Node的方式主要有4种：

nodeName调度：直接在Pod的yaml编排文件中指定nodeName，调度到指定name的节点上。
nodeSelector调度：直接在Pod的yaml编排文件中指定nodeSelector，调度到带有指定label的节点上。
污点(Taints)和容忍度(Tolerations)调度：主要通过在Node节点上打污点，然后在Pod的yaml编排文件中配置容忍度，来实现调度。
亲和-反亲和调度：通过条件筛选来调度，筛选的条件使用的是Node（Pod）的label字段。

2、为什么需要亲和调度

有了nodeName调度、nodeSelector调度、污点(Taints)和容忍度(Tolerations)调度，为什么还需要亲和-反亲和调度呢？

为了更灵活更复杂的调度方式。比如有些场景想把2个Pod 调度到一台节点上，有的场景为了隔离性高可用性想把2个Pod分开到不同节点上，或者有的场景想把Pod调度到指定的一些特点节点上。

3、亲和调度的前置概念（重要）

label在K8S中是非常重要的概念，不管是什么场景，只要和选择、筛选相关的，基本是用label字段来匹配的。
亲和性和反亲和性的调度，筛选的条件依旧用的是Node的label字段。
不管是Node亲和性调度，还是Pod亲和性调度，被调度的主体都是Pod。都是讲的Pod根据亲和规则调度到某个节点，或者Pod跟随别的Pod调到到某个节点（比如Pod1跟随Pod2，Pod2被调度到B节点，那么Pod1也被调度到B节点）。
Node亲和性调度和 Pod亲和性调度的配置都是写在编排Pod的yaml里。因为被调度的主体是Pod。
Node亲和性调度是指Pod和Node的亲密关系。
Pod亲和性调度是指Pod和Pod的亲密关系。
硬亲和：亲和规则只有一种，必须符合该规则。
软亲和：规则有多种，每个权重不同，根据权重优先级去选择一个规则。
Node亲和性调度的图示如下，Pod亲和性调用和Pod反亲和性调用也类似。

4、亲和调度的具体概念

Affinity的中文意思是亲近，用来表述亲和性调度再合适不过了。

亲和性调度：就好像Node（或者Pod）和Pod是关系很好的闺蜜，Pod说，“只要符合这种label的Node（Pod）都是我的好闺蜜，闺蜜在哪儿我就去哪儿”。

反亲和性调度：就好像2个Pod是赌气的2个孩子，互相对着干，一个往东，另一随便去哪个方向就是不往东，他们不会去到同一个地方。

4.1、记住这3种调度关系

亲和性调度和反亲和性调度的关系就3种：

node亲和调度：硬亲和、软亲和
pod亲和调度：硬亲和、软亲和
pod反亲和调度：硬亲和、软亲和

4.2、记住这2种亲和表达式

不管是Node亲和还是Pod亲和，他们都有2种亲和性表达方式：

RequiredDuringSchedulingIgnoredDuringExecution：是硬亲和的方式，必须满足指定的规则才可以把Pod调度到该Node上。这里注意Required这个词，中文意思必须的。
PreferredDuringSchedulingIgnoredDuringExecution：是软亲和的方式，强调优先满足某个规则，然后根据优先的规则，将Pod调度到节点上。这里注意Preferred这个词，中文意思是首选，用来说明选择规则的优先级，确实比较合适。

这两个字段也比较长，我们来做下拆解，将RequiredDuringSchedulingIgnoredDuringExecution拆解为RequiredDuringScheduling和IgnoredDuringExecution。

RequiredDuringScheduling：定义的规则必须强制满足（Required）才会把Pod调度到节点上。
IgnoredDuringExecution：已经在节点上运行的Pod不需要满足定义的规则，即使去除节点上的某个标签，那些需要节点包含该标签的Pod依旧会在该节点上运行。或者这么理解：如果Pod所在的节点在Pod运行期间标签被删除了，不再符合该Pod的节点亲和性规则，那也没关系，该Pod 还能继续在该节点上运行。

4.3、表达式中的操作符

亲和性表达方式需要用到如下几个可选的操作符operator：

In：标签的值在某个列表中
NotIn：标签的值不在某个列表中
Exists：存在某个标签
DoesNotExist：不存在某个标签
Gt：标签的值大于某个值（字符串比较）
Lt：标签的值小于某个值（字符串比较）

这些操作符里，虽然没有排斥某个节点的功能，但是用这几个标签也可以变相的实现排斥的功能。

4.4、作用域topologyKey

topologyKey很多地方解释为拓扑建，很是费解。实际上就是个作用域的概念。

topologyKey配置了一个label的key，那么存在这个key对应的label的所有Node就在同一个作用域里。

5、实战

理论知识讲解完毕，接下来通过实战加深理解。你可以按照步骤操作实践。

5.1、nodeName调度

比如要将Pod调度到nodeName是k8s-worker-2的节点上

apiVersion: v1
kind: Pod
metadata:
  name: webapp
  namespace: demo
  labels:
    app: webapp
spec:
  nodeName: 'k8s-worker-2'
  containers:
    - name: webapp
      image: nginx
      ports:
        - containerPort: 80

5.2、nodeSelector调度

比如要将Pod调度到具有"special-app"="specialwebapp"的label节点上。

查看节点信息：

kubectl describe node k8s-worker-2

Pod的yaml编排文件：

apiVersion: v1
kind: Pod
metadata:
  name: webapp
  namespace: demo
  labels:
    app: webapp
spec:
  nodeSelector:
    # 选择调度到具有这个label的节点
    "special-app": "specialwebapp"
  containers:
    - name: webapp
      image: nginx
      ports:
        - containerPort: 80

查看Pod被调度到哪台机器上：

kubectl get pod -n demo -o wide

5.3、Node亲和调度

Node的亲和调度是指，Node和Pod的关系。

硬亲和

定义Pod-Node的硬亲和yaml文件：pod_node_required_affinity.yaml。文件内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: webapp
  namespace: demo
  labels:
    app: webapp
spec:
  containers:
    - name: webapp
      image: nginx
      ports:
        - containerPort: 80
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: app
                operator: In
                values:
                  - backend

硬亲和性配置注释

# 定义 Pod 的节点亲和性配置
affinity:
  # 指定节点亲和性规则
  nodeAffinity:
    # 定义硬性要求，如果找不到满足条件的节点，Pod 不会被调度
    requiredDuringSchedulingIgnoredDuringExecution:
      # 定义一个或多个必须满足的条件
      nodeSelectorTerms:
         # 定义一系列的关键值对条件
         - matchExpressions:
            # 要匹配的标签键
            - key: app
              # 操作符，In 表示标签值必须在给定的列表中
              operator: In
              # 列出允许的标签值
              values:
                - backend

给k8s-worker-3节点添加label：

kubectl label node k8s-worker-3 app=backend

查看k8s-worker-3节点的label情况：

kubectl get node k8s-worker-3 --show-labels

执行上面的yaml部署Pod，可以看到Pod已经被调度到k8s-worker-3节点上。

软亲和

软亲和调度，主要就是加入了多个规则，每个设置了权重，yaml文件如下：

apiVersion: v1
kind: Pod
metadata:
  name: webapp
  namespace: demo
  labels:
    app: webapp
spec:
  containers:
    - name: webapp
      image: nginx
      ports:
        - containerPort: 80
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 80
          preference:
            matchExpressions:
              - key: app2
                operator: Exists
        - weight: 20
          preference:
            matchExpressions:
              - key: app
                operator: In
                values:
                  - backend2

配置解释

affinity:
  nodeAffinity:  # 定义节点亲和性规则，用于控制 Pod 调度到哪些节点上
    preferredDuringSchedulingIgnoredDuringExecution:  # 定义在调度时优先考虑的规则，但在运行时不强制执行
      - weight: 80  # 权重为 80，表示这个规则的优先级较高
        preference:  # 定义匹配规则
          matchExpressions:  # 使用表达式来匹配节点标签
            - key: app2  # 检查节点标签中是否存在 key 为 "app2" 的标签
              operator: Exists  # 使用 "Exists" 操作符，表示只要节点有这个标签就满足条件
      - weight: 20  # 权重为 20，表示这个规则的优先级较低
        preference:  # 定义匹配规则
          matchExpressions:  # 使用表达式来匹配节点标签
            - key: app  # 检查节点标签中是否存在 key 为 "app" 的标签
              operator: In  # 使用 "In" 操作符，表示节点的标签值必须在给定的值列表中
              values:  # 定义允许的标签值列表
                - backend2  # 节点标签的值必须是 "backend2"

删除之前的Pod，删除之前的k8s-worker-3节点的label，再给k8s-worker-2节点的增加app2=backend的label。

kubectl delete pod webapp -n demo
kubectl label node k8s-worker-3 app-
kubectl label node k8s-worker-2 app2=backend

部署上面的软亲和yaml文件，可以看到Pod被调度到了k8s-worker-2节点。

5.4、Pod亲和调度

Pod亲和调度，是指Pod和Pod之间的关系。

硬亲和

比如Pod1跟随Pod2，Pod2被调度到B节点，那么Pod1也被调度到B节点。

所以这里准备2个Pod。Pod1使用上面的例子，让Pod1采用Node硬亲和调度到k8s-worker-3节点。然后再部署Pod2，让它跟随Pod1，也会被调度到k8s-worker-3节点。

准备Pod2的yaml编排文件pod_pod_required_affinity.yaml，如下：

apiVersion: v1
kind: Pod
metadata:
  name: webapp-1
  namespace: demo
  labels:
    app: webapp-1
spec:
  containers:
    - name: webapp
      image: nginx
      ports:
        - containerPort: 80
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - topologyKey: kubernetes.io/hostname
          labelSelector:
            matchExpressions:
              - key: app
                operator: In
                values:
                  - webapp

配置解释

# 定义 Pod 的亲和性配置
affinity:
  # 定义 Pod 与其它 Pod 之间的亲和性规则
  podAffinity:
    #  定义硬性要求，Pod 必须调度到满足条件的节点上
    requiredDuringSchedulingIgnoredDuringExecution:
      - # 定义拓扑域，例如 "kubernetes.io/hostname" 表示主机名
        topologyKey: kubernetes.io/hostname
        # 选择具有特定标签的 Pod
        labelSelector:
          # 定义标签选择器的表达式
          matchExpressions:
            # 要匹配的标签键
            - key: app
              # 操作符，In 表示标签值必须在给定的列表中
              operator: In
              # 列出允许的标签值
              values:
                - webapp

# 通过这些注释，可以清楚地理解这个配置要求当前 Pod 必须与具有 app=webapp 标签的 Pod 调度到相同的节点上（因为 topologyKey 是 kubernetes.io/hostname，表示同一主机）。
# 这种配置通常用于确保相关服务位于同一节点，以减少网络延迟或满足其它部署需求。

可以看到Pod2跟随Pod1，也被调度到了k8s-worker-3节点。

软亲和

软亲和和硬亲和类似，只是多了权重，你可以自行尝试。

5.5、Pod反亲和调度

反亲和的硬亲和

接着上面的例子，继续准备Pod3的yaml编排文件，如下：

apiVersion: v1
kind: Pod
metadata:
  name: webapp-2
  namespace: demo
  labels:
    app: webapp-2
spec:
  containers:
    - name: webapp
      image: nginx
      ports:
        - containerPort: 80
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - topologyKey: kubernetes.io/hostname
          labelSelector:
            matchExpressions:
              - key: app
                operator: In
                values:
                  - webapp

配置解释

  # 亲和性和反亲和性配置
  affinity:
    # 定义 Pod 与其它 Pod 之间的反亲和性规则
    podAntiAffinity:
      # 定义硬性要求，Pod 必须调度到满足条件的节点上
      requiredDuringSchedulingIgnoredDuringExecution:
        - # 定义拓扑域，例如 "kubernetes.io/hostname" 表示主机名
          topologyKey: kubernetes.io/hostname
          #  选择具有特定标签的 Pod
          labelSelector:
            # 定义标签选择器的表达式
            matchExpressions:
              # 要匹配的标签键
              - key: app
                # 操作符，In 表示标签值必须在给定的列表中
                operator: In
                # 列出允许的标签值
                values:
                  - webapp
# 通过这些注释，可以清楚地理解这个配置要求当前 Pod 必须与具有 app=webapp 标签的 Pod 避免调度到相同的节点上（因为使用了 podAntiAffinity）。
# 这种配置通常用于确保高可用性，避免将多个副本调度到同一节点，从而减少单点故障的风险。

使用Pod反亲和的方式，让Pod3和Pod1不会部署在一起。部署完毕后，查看结果，Pod3因为反亲和被调度到了k8s-worker-2节点。

反亲和的软亲和

"反亲和的软亲和" 和 "硬亲和" 类似，只是多了权重，你可以自行尝试。

6、总结

本文主要快速讲解Kubernetes的亲和性和反亲和性调度。读完本文你需要记住以下3点：

亲和性和反亲和性的调度，筛选的条件使用的是Node（Pod）的label字段。
亲和性调度：就好像Node（Pod）和Pod是关系很好的闺蜜，Pod说，“只要符合这种label的Node（Pod）都是我的好闺蜜，闺蜜在哪儿我就去哪儿”。
反亲和性调度：就好像2个Pod是赌气的2个孩子，互相对着干，一个往东，另一随便去哪个方向就是不往东，他们不会去到同一个地方。

Z笔记

左老师的课堂笔记

Kubernetes节点与 Pod 亲和性

1、调度Pod的主要方式

2、为什么需要亲和调度

3、亲和调度的前置概念（重要）

4、亲和调度的具体概念

4.1、记住这3种调度关系

4.2、记住这2种亲和表达式

4.3、表达式中的操作符

4.4、作用域topologyKey

5、实战

5.1、nodeName调度

5.2、nodeSelector调度

5.3、Node亲和调度

硬亲和

软亲和

5.4、Pod亲和调度

硬亲和

软亲和

5.5、Pod反亲和调度

反亲和的硬亲和

反亲和的软亲和

6、总结