podantiaffinity不生效主因是topologykey选错或labelselector不匹配；需确认节点有对应标签、pod标签完全一致，优先用preferred策略，确保至少两个节点可用且资源充足。
PodAntiAffinity 配置后不生效？检查 topologyKey 和 label 匹配
反亲和性不是“禁止调度到同一节点”，而是“避免调度到满足某拓扑约束的已有 Pod 所在节点”。最常见失效原因是 topologyKey 选错，比如用了 topology.kubernetes.io/zone 却没给节点打对应 zone 标签；或 labelSelector 没匹配上目标 Pod 的实际标签。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先用
kubectl get pod -o wide看目标 Pod 在哪些节点，再用kubectl get node -o wide查这些节点的 labels，确认是否存在你写的topologyKey对应的 label -
labelSelector.matchLabels必须与目标 Pod 的metadata.labels完全一致（不是 selector 子集）；若需模糊匹配，改用matchExpressions - 测试时删掉旧 Pod 让新副本重建，不要只改 Deployment 而不触发滚动更新——旧 Pod 的 label 和节点绑定仍会影响新调度
requiredDuringSchedulingIgnoredDuringExecution 还是 preferredDuringSchedulingIgnoredDuringExecution？
硬性反亲和（requiredDuringSchedulingIgnoredDuringExecution）会在找不到合规节点时直接挂起 Pod，状态卡在 Pending；软性（preferredDuringSchedulingIgnoredDuringExecution）只是尽量避开，实在没得选也会调度过去。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 新服务上线优先用
preferred，避免因节点 label 不全或资源紧张导致整个 Deployment 卡住 - 生产环境关键组件（如 etcd、ZooKeeper 成员）才用
required，且必须确保集群节点数 ≥ 副本数，并统一打好topologyKey对应的 label -
weight只在preferred下有效，取值 1–100，但不会叠加——多个 preference 中最高 weight 的那个才起作用
Go 应用自身要不要加亲和性逻辑？一般不用
K8s 的 podAntiAffinity 已覆盖绝大多数高可用场景。Go 应用层主动探测节点、调用 K8s API 做调度决策，不仅增加复杂度，还容易引入竞态和权限问题。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 除非有强业务语义约束（例如：两个实例不能共享同一块物理磁盘），否则别在 Go 代码里做节点亲和判断
- 如果真要感知拓扑，用 Downward API 注入
spec.nodeName或topology.kubernetes.io/region等 label，而不是自己查 API Server - 注意：Go 程序里读取
os.Getenv("NODE_NAME")是安全的，但调用client-go列出同 namespace 其他 Pod 并判断位置，会放大启动延迟，且受 RBAC 和网络策略限制
为什么两个副本还是调度到了同一节点？检查污点、资源和容忍度
即使 podAntiAffinity 配对正确，Pod 仍可能挤在同一节点——因为调度器先过滤（taint/toleration、资源、nodeSelector），再打分（包括 affinity），最后才应用反亲和规则。前面任一环节筛得太松，就可能绕过反亲和。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
kubectl describe pod <name></name>查Events区域，看是否出现FailedScheduling提示，或者直接写 “0/5 nodes are available” 后面跟具体原因 - 检查节点是否有未被容忍的
Taint，而你的 Pod 没配Toleration，导致可选节点只剩 1 个 - 确认请求的
resources.requests不超过单节点剩余资源；反亲和不解决资源不足问题，它只在多个候选节点中做选择
反亲和生效的前提是：有至少两个符合条件的节点可供选择。很多人调了半天配置，最后发现集群只有 1 个 worker 节点，或者所有节点都被 taint 锁死了——这时候再准的 topologyKey 也无从谈起。
