K8S亲和与反亲和操作符使用案例

Kubernetes 中的亲和（Affinity）与反亲和（AntiAffinity）通过 operator 字段定义标签匹配规则，以下是支持的操作符及其案例解析：

---

一、支持的操作符

1. In

   • 作用：匹配标签值在指定列表中。
   • 适用场景：节点或 Pod 的标签值需为列表中的某一项。
   • 示例 ：values: ["bj"] 表示标签值需为 bj。

2. NotIn

   • 作用：匹配标签值不在指定列表中。
   • 适用场景：排除特定标签值的节点或 Pod。
   • 示例 ：values: ["prod"] 表示标签值不能为 prod。

3. Exists

   • 作用：匹配存在指定标签键（无需指定值）。
   • 适用场景：仅需标签键存在，不关心具体值。
   • 示例 ：key: "zone" 表示节点需有 zone 标签。

4. DoesNotExist

   • 作用：匹配不存在指定标签键的节点或 Pod。
   • 适用场景：排除带有特定标签的节点或 Pod。
   • 示例 ：key: "test" 表示节点不能有 test 标签。

5. Gt（Greater than）

   • 作用：标签值为数值且大于指定值。
   • 适用场景：基于数值型标签的调度（如 CPU 核数）。
   • 示例 ：values: ["4"] 表示标签值需大于 4。

6. Lt（Less than）

   • 作用：标签值为数值且小于指定值。
   • 适用场景：资源限制场景（如内存大小）。
   • 示例 ：values: ["8"] 表示标签值需小于 8。

---

二、案例解析

1. 节点亲和（Node Affinity）

案例：硬亲和与软亲和结合

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      affinity:
        nodeAffinity:
          # 硬亲和：必须调度到 zone=bj 的节点
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: zone
                operator: In
                values: ["bj"]
          # 软亲和：优先调度到 environment=dev 的节点
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: environment
                operator: In
                values: ["dev"]

• 说明 ：operator: In 确保节点标签 zone=bj，同时优先选择 environment=dev 的节点。

---

2. Pod 反亲和（Pod AntiAffinity）

案例：非强制反亲和

apiVersion: v1
kind: Pod
spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values: ["my-app"]
          topologyKey: kubernetes.io/hostname  # 拓扑域为节点

• 说明 ：
  • operator: In 匹配标签 app=my-app 的 Pod。
  • preferredDuringScheduling 表示尽量将 Pod 分散到不同节点，但允许在节点不足时共存。

---

3. 使用 Exists 操作符

案例：强制节点存在特定标签

nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
    nodeSelectorTerms:
    - matchExpressions:
      - key: gpu
        operator: Exists  # 只需存在 gpu 标签，不限制值

• 说明 ：调度到所有带 gpu 标签的节点，无论其值为 true 还是 nvidia。

---

4. 数值比较（Gt/Lt）

案例：基于资源标签调度

nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
    nodeSelectorTerms:
    - matchExpressions:
      - key: cpu-cores
        operator: Gt
        values: ["4"]  # 节点 CPU 核数需大于 4

• 适用场景：调度到高配置节点。

---

三、操作符对比表

操作符	适用对象	说明	示例场景
In	节点/Pod 标签	标签值在列表中	区域调度（如 zone: bj）
NotIn	节点/Pod 标签	标签值不在列表中	排除测试环境节点
Exists	节点/Pod 标签	标签键存在（无需值）	调度到 GPU 节点
DoesNotExist	节点/Pod 标签	标签键不存在	排除已维护节点
Gt/Lt	节点标签	数值型标签的比较	资源密集型任务调度

---

四、注意事项

1. 拓扑域（topologyKey） ：
   • Pod 反亲和需指定 topologyKey（如 kubernetes.io/hostname），表示调度域范围。
2. 性能影响 ：
   • Pod 反亲和在大规模集群中可能降低调度效率，建议节点数不超过数百。
3. 软硬策略 ：
   • requiredDuringScheduling 是硬性规则，不满足则 Pod 无法调度；preferredDuringScheduling 是软性规则，尽力满足但不保证。

通过灵活组合操作符和策略，可以实现精细化的调度控制，例如跨区域部署、资源隔离等。更多案例可参考 Kubernetes 官方文档。