4. Pod亲和性与反亲和性：Pod亲和性（podAffinity）、Pod反亲和性（podAntiAffinity）、拓扑键（topologyKey）详解

Pod亲和性与反亲和性是Kubernetes调度系统中用于控制Pod之间相对位置关系的核心机制。与节点亲和性（nodeAffinity）不同，Pod亲和性关注的是“Pod与Pod之间的调度约束”，而非Pod与节点标签的匹配。通过合理配置，可以实现服务就近部署（降低网络延迟）或故障隔离（提高可用性）。

4.1 核心概念与语义

Pod亲和性调度基于两个关键字段：podAffinity（亲和性）和 podAntiAffinity（反亲和性）。它们都定义在Pod的 spec.affinity 字段下，并进一步分为 requiredDuringSchedulingIgnoredDuringExecution（硬约束）和 preferredDuringSchedulingIgnoredDuringExecution（软约束）。

4.2 拓扑键（topologyKey）—— 拓扑域的定义者

topologyKey 是Pod亲和性与反亲和性配置中最核心的参数。它指定了节点标签的键名，用于定义“拓扑域”的边界。调度器根据该键名将节点分组，同一键值下的节点属于同一个拓扑域。

常见的拓扑键值包括：

• kubernetes.io/hostname —— 以节点为粒度（最严格）
• topology.kubernetes.io/zone —— 以可用区为粒度
• topology.kubernetes.io/region —— 以地域为粒度
• 自定义标签键 —— 如 rack、switch 等

4.3 Pod亲和性（podAffinity）配置示例

以下示例将“前端Pod”调度到与“后端Pod”相同的节点上（基于 hostname 拓扑域）：

apiVersion: v1
kind: Pod
metadata:
  name: frontend-pod
  labels:
    app: frontend
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - backend
        topologyKey: kubernetes.io/hostname
  containers:
  - name: nginx
    image: nginx

调度逻辑：调度器查找所有标签 app=backend 的Pod，然后获取这些Pod所在节点的 kubernetes.io/hostname 值，最后将 frontend-pod 调度到具有相同 hostname 值的节点上。

4.4 Pod反亲和性（podAntiAffinity）配置示例

以下示例将同一Deployment的多个副本分散到不同节点上：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - web
            topologyKey: kubernetes.io/hostname
      containers:
      - name: nginx
        image: nginx

调度逻辑：调度器确保在同一个节点上不会运行两个标签为 app=web 的Pod。如果集群只有3个节点，每个节点将恰好运行一个副本；如果节点不足，多余的Pod将处于Pending状态。

4.5 拓扑键选择与调度效果对比

4.6 调度流程与拓扑域匹配逻辑

下图展示了Pod反亲和性在调度过程中的核心判断逻辑：

4.7 软约束与权重（weight）

对于 preferredDuringSchedulingIgnoredDuringExecution 类型的亲和性/反亲和性，可以设置 weight 字段（1-100），用于控制偏好的强度。调度器在评分阶段会根据权重计算总分，权重越高，调度器越倾向于满足该约束。

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 80
      podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - web
        topologyKey: kubernetes.io/hostname

4.8 亲和性与反亲和性的组合使用

在实际部署中，经常需要同时使用亲和性和反亲和性来实现复杂的调度策略。例如：将“缓存Pod”与“计算Pod”调度到同一可用区（亲和性），同时确保“计算Pod”的多个副本分散到不同节点（反亲和性）。

affinity:
  podAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchExpressions:
        - key: app
          operator: In
          values:
          - cache
      topologyKey: topology.kubernetes.io/zone
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchExpressions:
        - key: app
          operator: In
          values:
          - compute
      topologyKey: kubernetes.io/hostname

下图展示了这种组合策略的拓扑关系：

4.9 常见陷阱与注意事项

• 拓扑键必须一致： 同一组亲和性/反亲和性规则中，所有 podAffinityTerm 的 topologyKey 必须相同，否则调度器无法正确分组。
• 反亲和性对集群规模的要求： 使用 requiredDuringScheduling 反亲和性时，如果拓扑域数量少于副本数，部分Pod将无法调度。例如3副本要求分散到不同节点，但集群只有2个节点，则第3个Pod会Pending。
• 性能影响： 大量使用Pod反亲和性（尤其是跨namespace匹配）会增加调度器的计算开销，建议在大型集群中合理控制规则数量。
• namespace限制： labelSelector 默认只匹配同一namespace下的Pod。如果需要跨namespace匹配，需显式设置 namespaces 字段。
• 与节点亲和性的优先级： Pod亲和性/反亲和性的约束优先级高于节点亲和性。调度器先满足Pod间约束，再考虑节点标签匹配。