3. PodAffinity 与 PodAntiAffinity：Pod间亲和性、反亲和性、拓扑分布约束
在 Kubernetes 集群中，Pod 的调度不仅受节点资源约束，还经常需要根据 Pod 之间的相对位置 来决策。例如：将高延迟敏感的服务调度到同一节点以减少网络跳数，或将同一应用的多个副本分散到不同故障域以提高可用性。Pod 亲和性（PodAffinity）与反亲和性（PodAntiAffinity）正是为此设计的调度语义，而拓扑分布约束（Topology Spread Constraints）则提供了更精细的分布控制。
3.1 核心概念与调度语义
Pod 间亲和性/反亲和性基于 节点上已运行的 Pod 标签 进行匹配，而非节点本身的标签。调度器通过 topologyKey 定义“拓扑域”的范围（如 kubernetes.io/hostname 表示节点级，topology.kubernetes.io/zone 表示可用区级），然后在该拓扑域内检查是否存在满足标签选择器的 Pod。
| 调度类型 | 语义 | 典型场景 |
|---|---|---|
| PodAffinity | 将 Pod 调度到 与匹配 Pod 相同的拓扑域 中 | 将缓存服务与计算服务部署在同一节点，减少网络延迟 |
| PodAntiAffinity | 将 Pod 调度到 与匹配 Pod 不同的拓扑域 中 | 将同一应用的多个副本分散到不同节点或可用区，避免单点故障 |
| TopologySpreadConstraints | 在多个拓扑域之间 均匀分布 Pod 副本 | 确保每个可用区运行的 Pod 数量相差不超过 1 |
3.2 亲和性与反亲和性的规则结构
PodAffinity 和 PodAntiAffinity 的规则结构完全相同，均包含 requiredDuringSchedulingIgnoredDuringExecution（硬约束）和 preferredDuringSchedulingIgnoredDuringExecution（软约束）两种类型。每个规则由 labelSelector、topologyKey 和可选的 namespaces 组成。
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:1.25app=web 的 Pod。如果集群只有 2 个节点，则第 3 个 Pod 将处于 Pending 状态，直到有新的节点加入或已有 Pod 被删除。
3.3 拓扑分布约束：更精细的分布控制
拓扑分布约束（TopologySpreadConstraints）通过 maxSkew、topologyKey、whenUnsatisfiable 三个核心参数，控制 Pod 在拓扑域之间的分布偏差。它比反亲和性更灵活，支持“软性”和“硬性”两种模式。
| 参数 | 说明 | 示例值 |
|---|---|---|
maxSkew |
允许的最大分布偏差（Pod 数量差） | 1 |
topologyKey |
定义拓扑域的节点标签键 | topology.kubernetes.io/zone |
whenUnsatisfiable |
不满足约束时的行为：DoNotSchedule（硬）或 ScheduleAnyway（软） |
DoNotSchedule |
labelSelector |
用于匹配 Pod 的标签选择器 | matchLabels: { app: web } |
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-server-spread
spec:
replicas: 6
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: web
containers:
- name: nginx
image: nginx:1.253.4 调度决策流程与交互关系
下图展示了调度器在处理 Pod 间亲和性、反亲和性及拓扑分布约束时的决策流程。调度器首先过滤不满足硬约束的节点，然后对剩余节点进行打分，最后选择最优节点。
3.5 实战对比：三种调度策略的适用场景
在实际生产环境中，三种策略往往组合使用。下表从 故障域隔离、性能优化、资源利用率 三个维度进行对比，帮助选择最合适的策略。
| 策略 | 故障域隔离 | 性能优化 | 资源利用率 | 推荐场景 |
|---|---|---|---|---|
| PodAntiAffinity（硬） | ★★★★★ | ★★☆☆☆ | ★★☆☆☆ | 有状态服务（如 ZooKeeper、Kafka）要求每个节点最多一个副本 |
| PodAffinity（硬） | ★☆☆☆☆ | ★★★★★ | ★★★☆☆ | 缓存与计算服务同节点部署，减少网络开销 |
| TopologySpreadConstraints | ★★★★☆ | ★★★☆☆ | ★★★★★ | 无状态服务（如 Web 应用）均匀分布到各可用区 |
| 组合使用 | ★★★★★ | ★★★★☆ | ★★★★☆ | 核心服务：反亲和性保证高可用 + 拓扑分布保证资源均衡 |
3.6 常见陷阱与最佳实践
- 拓扑键选择错误： 使用
kubernetes.io/hostname时，如果节点没有该标签，调度器会忽略该规则。建议使用标准拓扑键或确保节点标签一致。 - 硬约束过度使用： 硬反亲和性 + 大量副本可能导致 Pod 无法全部调度。建议对关键服务使用硬约束，对普通服务使用软约束或拓扑分布。
- 命名空间隔离： 默认情况下，亲和性规则只匹配同一命名空间内的 Pod。跨命名空间匹配需显式设置
namespaces字段。 - 性能影响： 大量 Pod 的亲和性规则会增加调度器计算开销。对于大规模集群（>1000 节点），建议使用拓扑分布约束替代复杂的反亲和性规则。
topologySpreadConstraints 实现均匀分布；对于有状态服务，使用 podAntiAffinity 的硬约束确保故障域隔离；对于需要协同工作的服务对，使用 podAffinity 的软约束并配合 preferredDuringScheduling 避免调度失败。
3.7 拓扑分布约束的进阶用法：多约束叠加
Kubernetes 1.19+ 支持在同一个 Pod 中定义多个拓扑分布约束，实现多维度分布控制。例如，同时按节点和可用区进行分布，确保 Pod 在集群中既分散到不同可用区，又在每个可用区内分散到不同节点。
apiVersion: apps/v1
kind: Deployment
metadata:
name: multi-spread
spec:
replicas: 9
selector:
matchLabels:
app: multi
template:
metadata:
labels:
app: multi
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: multi
- maxSkew: 1
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app: multi
containers:
- name: app
image: nginx:1.25下图展示了多约束叠加的调度效果：9 个 Pod 分布在 3 个可用区（每个可用区 3 个 Pod），且每个可用区内的 3 个 Pod 分散到不同节点上。