生产环境如何配置 Pod 反亲和性避免单点故障风险

在生产环境配置 Pod 反亲和性是为了防止同一个应用的多个副本被调度到同一台节点上，从而避免节点故障导致服务不可用，建议优先使用软策略配合硬策略兜底。

先说结论：Pod 反亲和性能有效分散副本分布，但配置过严会导致 Pod 无法调度，需根据集群资源情况选择策略。

适合：对高可用有明确要求的核心业务服务
先准备：确认节点标签、拓扑域（如主机名或可用区）及资源余量
验收：观察 Pod 分布是否跨节点且无长期 Pending 状态

命令速用版

以下是一个典型的 Deployment 配置片段，展示了如何使用硬策略强制分散 Pod：

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
    - labelSelector:
        matchExpressions:
        - key: app
          operator: In
          values:
          - my-app
      topologyKey: kubernetes.io/hostname

如果希望调度更灵活，可将 requiredDuringSchedulingIgnoredDuringExecution 改为 preferredDuringSchedulingIgnoredDuringExecution 并设置权重。

为什么会这样

默认情况下，Kubernetes 调度器主要关注资源是否足够，而不关心同一个应用的多个 Pod 是否位于同一台物理机或同一可用区。如果节点发生故障，所有集中在该节点的副本都会不可用，形成单点故障。反亲和性规则告诉调度器在放置 Pod 时，尽量避免与具有特定标签的其他 Pod 处于相同的拓扑域中。

分步处理

1. 确认拓扑域

首先确认集群节点支持的拓扑标签。常用的是 kubernetes.io/hostname（分散到不同节点）或云厂商提供的可用区标签（如 topology.kubernetes.io/zone）。使用以下命令查看节点标签：

kubectl get nodes `--show-labels`

2. 定义标签选择器

确定需要分散的 Pod 的标签，通常是 app 或 component。确保 Deployment 中的 matchLabels 与反亲和性规则中的 labelSelector 一致。

3. 选择策略类型

资源充足且要求严格高可用时，使用 required（硬策略）；资源紧张或希望尽量分散但不强求时，使用 preferred（软策略）。生产环境建议先上软策略观察，再根据情况调整。

4. 应用配置

将配置更新到集群，并注意观察调度状态。如果是现有服务，建议先在测试环境验证 YAML 是否正确。

怎么验证是否生效

部署完成后，使用以下命令查看 Pod 分布情况：

kubectl get pods -o wide

检查同一应用的多个 Pod 是否位于不同的 NODE 列所示的主机上。同时观察是否有 Pod 处于 Pending 状态，如果有，使用 kubectl describe pod <pod-name> 查看事件，确认是否因反亲和性规则导致无法调度。

常见坑

1. 资源不足导致无法调度

如果设置了硬策略反亲和性，但集群节点数量少于副本数，或者某些节点资源不足，Pod 会一直处于 Pending 状态。公开资料中没有看到可靠的量化数据说明具体影响比例，但这是最常见的问题。

2. 拓扑键不匹配

如果指定的 topologyKey 在节点上不存在，反亲和性规则将不会生效。例如在某些旧版本或特定云环境中，可用区标签可能不同。

3. 标签选择器过宽

如果 labelSelector 匹配了不该匹配的其他服务 Pod，可能导致不必要的调度限制，影响集群整体调度效率。

参考来源

Kubernetes Official Documentation, "Assign Pods to Nodes", https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/