关键业务需用Pod Anti-Affinity实现跨机架高可用，核心是通过topologyKey设为rack标签、配置requiredDuringSchedulingIgnoredDuringExecution硬性规则确保副本分散于不同机架，并配合PDB、探针和多可用区节点池提升整体可靠性。
要在 Kubernetes 中用 Pod Anti-Affinity 实现关键业务跨机架高可用，核心是让同一应用的多个副本不落在同一个物理机架上——这比仅“跨节点”更进一步，能规避机架级断电、网络汇聚层故障或布线问题导致的批量宕机。
明确 topologyKey：选对机架标识符
Kubernetes 本身不直接识别“机架”，需依赖节点标签映射。管理员必须提前为每个节点打上机架标签，例如：
-
统一打标命令示例：
kubectl label node node-01 rack=rack-a、kubectl label node node-02 rack=rack-b -
topologyKey 必须设为该标签键名，如
rack；不能用kubernetes.io/hostname（那是节点级）或failure-domain.beta.kubernetes.io/zone（那是可用区级） - 确认标签已生效：
kubectl get nodes -L rack，确保所有目标节点都有非空、不重复的rack值
配置硬性反亲和策略（requiredDuringSchedulingIgnoredDuringExecution）
软策略（preferred）无法保证机架隔离，在关键业务中不可靠。必须使用硬性规则，确保调度器严格遵守：
- labelSelector 匹配你 Deployment 中 Pod 的实际标签（如
app: payment-service） - topologyKey 设为
rack，表示“相同 rack 值的节点视为同一拓扑域，禁止共存” - 若副本数 > 可用机架数，Pod 将长期处于 Pending 状态——这是预期行为，提示你扩容机架资源，而非妥协可用性
配套必须启用的高可用机制
仅靠 Anti-Affinity 不足以应对真实故障场景，需组合以下三项：
-
PodDisruptionBudget（PDB）：限制主动驱逐时允许不可用的副本数，防止滚动更新或节点维护期间服务中断。例如设置
minAvailable: 2，确保三副本服务至少两个始终在线 - Liveness & Readiness 探针：让 K8s 及时发现并重启僵死进程，或从 Service 流量中摘除异常实例，避免流量打到半死状态的 Pod
-
多可用区节点池：机架通常位于同一可用区内，为防止单可用区整体失效，应将节点分布在至少两个可用区，并为每个可用区内部署独立机架标签体系（如
rack: us-east-1a-rack1），再配合 zone 级反亲和或 PDB 分区控制
验证与可观测要点
部署后务必验证是否真正跨机架运行：
- 查 Pod 分布：
kubectl get pods -o wide | awk '{print $1,$7,$8}'，核对 NODE 列对应节点的rack标签值是否互异 - 模拟机架故障：手动 cordon + drain 某一 rack 下全部节点，观察剩余副本是否持续提供服务、Service Endpoints 是否自动剔除离线实例
- 监控建议接入：记录
scheduler_scheduling_duration_seconds监控项，若因反亲和导致 Pending 时间过长，说明机架资源不足，需告警干预
