必须配置基于kubernetes.io/hostname的podantiaffinity硬性规则，确保两条支付通道的pod严格隔离于不同物理机，且同一通道内副本也不共节点；升级时需设maxsurge=0、maxunavailable=1并预留资源，禁用软策略与模糊拓扑。
要防止两条核心支付通道的 Pod 被调度到同一台物理机，关键在于配置Pod 反亲和性（podAntiAffinity），并严格限定拓扑域为单节点粒度——即使用 kubernetes.io/hostname 作为 topologyKey。这不是单纯“避免同节点”的可选项，而是金融级高可用场景下的强制防护动作。
明确防护目标与拓扑边界
两条支付通道通常对应两个独立 Deployment（如 payment-gateway-a 和 payment-gateway-b），每条通道至少需 2 个副本。物理防护的核心是：
- 同一通道内副本不共节点（防单点故障）
- 两条通道之间也互不共节点（防交叉影响，比如资源争抢或内核级干扰）
- 必须用
kubernetes.io/hostname作topologyKey：它基于节点实际主机名，天然一对一映射物理机，不可被伪造或复用 - 禁用模糊拓扑（如
zone或自定义rack标签）：它们无法保证物理隔离，存在跨物理机共享同一 zone/rack 的风险 - 确认所有工作节点已正确打标：可通过
kubectl get nodes -o wide验证 hostname 是否唯一且稳定
配置硬性反亲和规则（推荐用于支付通道）
对每个 Deployment 分别设置 requiredDuringSchedulingIgnoredDuringExecution，确保调度器绝不妥协：
- 通道 A 的 Deployment 中添加：
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values: ["payment-gateway-a"]
topologyKey: kubernetes.io/hostname
- 通道 B 同理，仅把
values改为["payment-gateway-b"] - 若还需实现“A 和 B 互斥”，则在通道 A 的规则中额外加一条匹配
payment-gateway-b，反之亦然
规避滚动更新时的调度冲突
硬策略在升级过程中易触发 FailedScheduling（因旧 Pod 尚未终止，新 Pod 找不到空闲节点）。应对方式：
- 将 Deployment 的
strategy.rollingUpdate.maxSurge设为0，maxUnavailable设为1：确保更新期间最多只有一副本不可用，降低节点占满概率 - 升级前检查节点资源余量：每台节点至少预留 1 份支付 Pod 的 CPU+内存，避免因资源不足导致反亲和失效
- 禁止使用
preferred替代required：软策略无法满足“物理防护”这一刚性要求，只是妥协，不是防护
上线后验证是否真正生效
配置不是终点，必须验证物理隔离是否真实达成：
- 执行
kubectl get pods -o wide | grep payment，确认所有 Pod 的NODE列值完全不重复 - 检查是否有长期
Pending状态：若有，说明集群节点数 - 模拟节点宕机（如
kubectl drain <node> --ignore-daemonsets</node>），观察剩余 Pod 是否全部自动恢复且仍在不同节点
