k8s Pod亲和性与反亲和性详解：同置与分散实战

Pod 亲和性/反亲和性

本教程共 65 篇 · 第 40 篇 · 更新于 2026-08-14 · 约 9 分钟阅读

KubernetesPod亲和性Pod反亲和性调度topologyKey高可用

本节目标：理解 Pod 间亲和性和反亲和性怎么按”其他 Pod 的标签”决定落点，会用 topologyKey 表达拓扑域，能区分硬约束和软偏好，并知道两个典型场景。

节点亲和性看的是”节点标签”。可有时候你要看的不是节点，而是”这台机器上已经跑了哪些 Pod”。比如缓存和 Web 放一起延迟低，或同一服务的副本别堆同一台机器。

这就是 Pod 间亲和性（podAffinity）和反亲和性（podAntiAffinity）的用武之地。

40-1 它解决什么问题

节点亲和性回答”Pod 想去哪类节点”。Pod 间亲和性回答”Pod 想和哪些 Pod 做邻居，或躲开哪些 Pod”。判断依据是节点上已有 Pod 的标签，而不是节点本身的标签。

规则长这样：“如果某个拓扑域里已经有满足 Y 的 Pod，那我就（不）和它放一起”。这里的拓扑域是 topologyKey 指定的，比如节点、可用区、机架。

Note

topologyKey 是一个节点标签键，用来划分拓扑域。常用 kubernetes.io/hostname 表示”按单机”，用 topology.kubernetes.io/zone 表示”按可用区”。

40-2 两种约束与操作符

和节点亲和性一样，Pod 间亲和/反亲和也有硬约束和软偏好两种：

requiredDuringSchedulingIgnoredDuringExecution：硬约束，必须满足，否则不调度。
preferredDuringSchedulingIgnoredDuringExecution：软偏好，尽量满足。

Pod 间亲和性可用的操作符是 In、NotIn、Exists、DoesNotExist。它不支持 Gt/Lt。

spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values: ["store"]
        topologyKey: "kubernetes.io/hostname"

上面意思是：本 Pod 必须调度到”已经有 app=store 的 Pod 在跑”的那台机器上。

Warning

反亲和性要求集群里每个节点都有对应的 topologyKey 标签，否则行为会和预期不符。而且 Pod 间亲和性计算量偏大，官方不建议在数百节点以上的大集群里滥用，会拖慢调度。

40-3 场景一：相关服务同置

想象一个三节点集群，跑 Web 应用加 Redis 缓存，两者通信要低延迟。用 Pod 亲和性把 Web 贴着缓存放。

Redis 这边加反亲和，让三个副本分散到不同节点：

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchExpressions:
        - key: app
          operator: In
          values: ["store"]
      topologyKey: "kubernetes.io/hostname"

Web 这边既亲和缓存、又反亲和自己：

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchExpressions:
        - key: app
          operator: In
          values: ["web-store"]
      topologyKey: "kubernetes.io/hostname"
  podAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchExpressions:
        - key: app
          operator: In
          values: ["store"]
      topologyKey: "kubernetes.io/hostname"

最终效果：每台机器上一个 Web 配一个缓存，三台各一份，既近又稳。

40-4 场景二：副本分散提高可用

反亲和性是高可用的好朋友。StatefulSet、Deployment 的多个副本，用 podAntiAffinity 按 hostname 打散，避免”一台机器挂掉、服务全断”。

Tip

软反亲和（preferred）更宽容：节点不够时退而求其次，副本仍能起来。硬反亲和在节点不足时会让部分副本一直 pending。生产一般先用软的，确有强隔离需求再上硬的。

40-5 与节点亲和性怎么选

想”指定节点类型”——用节点亲和性。
想”跟/躲某个工作负载”——用 Pod 间亲和/反亲和。
想”赶走某类节点”——用污点（下一章）。

三者可以叠加。调度器在过滤阶段检查硬性规则，在打分阶段参考软偏好，最终定下落点。