Kubernetes(k8s)-Node亲和性(Affinity)和反亲和性(Anti-affinity)

作者介绍：简历上没有一个精通的运维工程师。下面的思维导图也是预计更新的内容和当前进度(不定时更新)。

我们上一章介绍了Docker基本情况，目前在规模较大的容器集群基本都是Kubernetes，但是Kubernetes涉及的东西和概念确实是太多了，而且随着版本迭代功能在还增加，笔者有些功能也确实没用过，所以只能按照我自己的理解来讲解。

我们前面介绍了2种调度算法：标签(label)和NodeSelectors；污点（Taints）和容忍（Tolerations）。虽然可以满足我们一般的调度需求，但是不够灵活，所以Kubernetes给我们提供了另外2个资源亲和性(Affinity)和反亲和性(Anti-affinity)

在 Kubernetes 中，亲和性（Affinity）和反亲和性（Anti-affinity）是高级的调度特性，它们允许你设置规则，这些规则可以在调度 Pod 时，详细地控制 Pod 应该运行在哪些节点上。这些规则比传统的 nodeSelector 提供了更多的灵活性和控制能力。

节点亲和性（Node Affinity）

节点亲和性是一种规则，它允许你指定 Pod 应该（或者在偏好上）被调度到哪些节点上。节点亲和性分为两种类型：

1. 硬亲和性（RequiredDuringSchedulingIgnoredDuringExecution）：
   • 这种类型的亲和性是强制性的。如果节点的标签不满足 Pod 的亲和性规则，Pod 将不会被调度到该节点上。
   • 例如，你可以要求 Pod 只能被调度到具有特定标签的节点上，和nodeSelector类似。
2. 软亲和性（PreferredDuringSchedulingIgnoredDuringExecution）：
   • 这种类型的亲和性是非强制性的。它表示调度器会尝试将 Pod 调度到满足规则的节点上，但如果找不到这样的节点，Pod 仍然可以被调度到其他节点上。
   • 每个偏好规则都有一个权重，调度器会根据这些权重来选择最佳节点。

节点亲和性的示例配置：

apiVersion: v1
kind:Pod
metadata:
name:with-node-affinity
spec:
affinity:
    nodeAffinity:  #节点亲和性
      requiredDuringSchedulingIgnoredDuringExecution: #硬亲和
        nodeSelectorTerms:  # 定义下面具体的亲和规则，可以有多个
        -matchExpressions: # 其中一个亲和性规则
          -key:kubernetes.io/e2e-az-name    
            operator:In   #必须包含下面的key
            values:        #具体的key
            -e2e-az1
            -e2e-az2
      preferredDuringSchedulingIgnoredDuringExecution:
      -weight:1   #权重，多个才有意义 
        preference: #定义偏好具体内容，等效于nodeSelectorTerms
          matchExpressions: #具体规则
          -key:another-node-label  #尽量满足
            operator:In
            values:
            -value1

Pod使用硬亲和，必须调度到标签key：kubernetes.io/e2e-az-name；vlaues ：e2e-az1 或者 e2e-az2 节点。

Pod使用软亲和，尽量调度到标签Key：another-node-label；vlaues：value1 节点

节点反亲和性（Node Anti-Affinity）

节点反亲和性是节点亲和性的对立面，它允许你指定 Pod 应该避免被调度到哪些节点上。反亲和性也有两种类型：

1. 硬反亲和性（RequiredDuringSchedulingIgnoredDuringExecution）：
   • 这种类型的反亲和性是强制性的。如果节点的标签满足 Pod 的反亲和性规则，Pod 将不会被调度到该节点上。
   • 例如，你可以要求 Pod 避免被调度到具有特定标签的节点上。
2. 软反亲和性（PreferredDuringSchedulingIgnoredDuringExecution）：
   • 这种类型的反亲和性是非强制性的。它表示调度器会尝试避免将 Pod 调度到满足规则的节点上，但如果没有其他选择，Pod 仍然可以被调度到这些节点上。
   • 同样，每个偏好规则都有一个权重。

节点反亲和性的示例配置：

apiVersion: v1
kind: Pod
metadata:
  name: with-node-anti-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/e2e-az-name
            operator: NotIn
            values:
            - e2e-az3
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-key # 注意这里应该是具体的标签键名
            # 需要指定operator和values，这里没有给出具体值

Pod使用硬亲和，必须不调度到标签key：kubernetes.io/e2e-az-name；vlaues ：e2e-az3。后面的软反亲和就没有提供具体的配置。

in资源必须包含具有指定值的标签(适合Node亲和性)。

notIn资源不能包含具有指定值的标签(适合Node反亲和性)。

exists资源必须包含指定的标签，但不关心标签的值是什么。(适合Node亲和性)。

doesNotExist资源不能包含指定的标签(适合Node反亲和性)。