亲和性

一、概念

在K8S中，亲和性（Affinity）用来定义Pod与节点关系的概念，亲和性通过指定标签选择器和拓扑域约束来决定 Pod 应该调度到哪些节点上。与污点相反，它主要是尽量往某节点靠。

亲和性是 Kubernetes 中非常有用的调度策略，作用是优化 Pod 的调度策略，以便将 Pod 调度到满足特定条件的节点上，从而实现更高效的资源利用、提高容错性和性能等方面的需求。

亲和性配置主要分为三类：

• 1、节点亲和性：进行 pod 调度时，优先调度到符合条件的亲和力节点上
• 2、Pod 亲和性：将与指定 pod 亲和力相匹配的 pod 部署在同一节点。
• 3、Pod 反亲和性：根据策略尽量部署或不部署到一块
• 4、服务亲和性：将与同一Service相关联的Pod调度到同一节点上

二、节点亲和性

2.1、介绍

节点亲和性NodeAffinity，用于将Pod调度到具有特定标签或污点的节点上，通过使用节点亲和性规则，您可以控制Pod应该在哪些节点上运行。

配置节点亲和性分为：

• 硬亲和性（RequiredDuringSchedulingIgnoredDuringExecution），即支持必须部署在指定的节点上，也支持必须不部署在指定的节点上
• 软亲和性（PreferredDuringSchedulingIgnoredDuringExecution），尽量部署在满足条件的节点上，或尽量不要部署在被匹配的节点上

如果同时配置了硬亲和 和 软亲和，那么先强制要求Pod满足此规则才能被调度。如果没有满足该规则的节点可用，Pod将无法被调度。然后再根据软亲和的权重分来决定。

2.2、匹配类型

节点亲和性是针对节点标签进行匹配，匹配类型支持多种

符号	说明
In	包含条件，满足则部署在满足条件的节点上
NotIn	匹配不在条件中的节点，实现节点反亲和性
Exists	只要存在 key 名字就可以，不关心值是什么
DoesNotExist	匹配指定 key 名不存在的节点，实现节点反亲和性
Gt	value 为数值，且节点上的值小于指定的条件 ， 配置value > 节点
Lt	value 为数值，且节点上的值大于指定条件 配置value < 节点

2.3、使用示例

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity: # 亲和力配置
    nodeAffinity: # 节点亲和力
      requiredDuringSchedulingIgnoredDuringExecution: # 节点必须匹配下方配置
        nodeSelectorTerms: # 选择器
        - matchExpressions: # 匹配表达式
          - key: topology.kubernetes.io/zone # 匹配 label 的 key
            operator: In # 匹配方式，只要匹配成功下方的一个 value 即可
            values:
            - antarctica-east1 # 匹配的 value1
            - antarctica-west1 # 匹配的 value2
      preferredDuringSchedulingIgnoredDuringExecution: # 节点尽量匹配下方配置
      - weight: 1 # 权重[1,100]，按照匹配规则对所有节点累加权重，最终之和会加入优先级评分，优先级越高被调度的可能性越高
        preference:
          matchExpressions: # 匹配表达式
          - key: another-node-label-key # label 的 key
            operator: In # 匹配方式，满足一个即可
            values:
            - another-node-label-value # 匹配的 value
#      - weight: 20
        ......
  containers:
  - name: with-node-affinity
    image: xxx

三、Pod 亲和性

3.1、介绍

Pod亲和性（PodAffinity）， 可以在同一节点上调度与Pod相似的其他Pod，或者避免在同一节点上调度。

用法上和节点亲和性差不多，主要由nodeAffinity换成podAntiAffinity， nodeSelectorTerms换成labelSelector，匹配类型这些是一样的

3.2、示例

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity: # 亲和力配置
    podAffinity: # pod 亲和力配置
      requiredDuringSchedulingIgnoredDuringExecution: # 当前 pod 必须匹配到对应条件 pod 所在的 node 上
      - labelSelector: # 标签选择器
          matchExpressions: # 匹配表达式
          - key: security # 匹配的 key
            operator: In # 匹配方式
            values: # 匹配其中的一个 value
            - S1
        topologyKey: topology.kubernetes.io/zone
    podAntiAffinity: # pod 反亲和力配置
      preferredDuringSchedulingIgnoredDuringExecution: # 尽量不要将当前节点部署到匹配下列参数的 pod 所在的 node 上
      - weight: 100 # 权重
        podAffinityTerm: # pod 亲和力配置条件
          labelSelector: # 标签选择器
            matchExpressions: # 匹配表达式
            - key: security # 匹配的 key
              operator: In # 匹配的方式
              values:
              - S2 # 匹配的 value
          topologyKey: topology.kubernetes.io/zone
  containers:
  - name: with-pod-affinity
    image: xx

四、Pod 反亲和性

pod反亲和性根据策略尽量让Pod之间部署或不部署到一块， 它与Pod亲和性配置的区别只有：podAffinity换成podAntiAffinity

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: my-container
      image: my-image
  affinity:
    podAntiAffinity: # pod反亲和性配置
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
              - key: "app"
                operator: In
                values:
                  - my-app
          topologyKey: "kubernetes.io/hostname"