requiredDuringSchedulingIgnoredDuringExecution是硬性调度约束，必须满足亲和规则才能调度，否则Pod将长期处于Pending状态；其作用等价于nodeSelector但支持更复杂表达式（如In、NotIn），且IgnoredDuringExecution表示调度后节点标签变更不影响已运行Pod。
硬性反亲和（requiredDuringSchedulingIgnoredDuringExecution）是 Golang 应用在 Kubernetes 中实现高可用副本分散部署的首选方式，但必须确保节点数 ≥ 副本数，否则 Pod 会卡在 Pending 状态。
为什么 Golang 应用特别需要 podAntiAffinity
Golang 服务通常轻量、启动快、常以多副本横向扩展，但默认调度器不保证副本分散。一个常见故障场景是：2 个 app: order-service Pod 全被调度到同一节点，该节点宕机即导致订单服务整体不可用。这不是资源不足问题，而是调度逻辑缺失——podAntiAffinity 正是用来补上这一环的业务语义。
注意：这不是“给 Golang 特殊配置”，而是所有无状态微服务的通用实践；Golang 因其高并发低开销特性，更容易因单点故障放大影响。
最简有效的 YAML 配置写法
以下是最小可运行的 Deployment 片段，适用于绝大多数 Golang HTTP 服务：
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values: ["order-service"]
topologyKey: "kubernetes.io/hostname"
关键点说明：
-
matchExpressions比matchLabels更可靠：避免因 Deployment 模板里漏加标签导致规则失效 -
topologyKey: "kubernetes.io/hostname"表示“不同节点”，这是生产环境最常用粒度；若需跨可用区，请确认节点真有topology.kubernetes.io/zone标签（用kubectl get node -o wide查） - 必须确保所有目标 Pod（即你要避开的那些）都带
app: order-service标签——这个标签来自template.metadata.labels，不是selector.matchLabels
PodAntiAffinity 不生效的三个高频原因
Golang 应用部署后发现两个副本仍在同一节点，大概率是以下其一：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
topologyKey对应的标签在节点上不存在：比如写了topology.kubernetes.io/zone，但kubectl get node --show-labels显示节点只有kubernetes.io/hostname -
labelSelector匹配的是其他 Pod 的标签，而你实际想避开的 Pod 标签是app: order-svc（少了个-），但配置里写的是order-service - 没触发滚动更新：只改了 YAML 文件却没删旧 Pod 或执行
kubectl rollout restart deploy/order-service，旧 Pod 还占着节点，新 Pod 调度时受其约束
调试建议：先用 kubectl get pod -l app=order-service -o wide 看副本分布，再用 kubectl describe pod 查 Events 里是否有 FailedScheduling 及具体拒绝原因。
要不要用 preferred 而不是 required
仅当集群节点数不稳定（如 Spot 实例频繁进出）或副本数 > 可用节点数时才考虑 preferredDuringSchedulingIgnoredDuringExecution。它带 weight 参数，但无法防止扎堆——如果只剩 1 个节点有足够资源，调度器仍会把所有副本塞进去。
真正需要的是：用 required 保底线 + 资源请求（resources.requests）做硬隔离。例如设 requests.cpu: 500m，配合节点 CPU 容量，天然限制单节点最多跑 2 个副本（假设 1C 节点），再叠 podAntiAffinity 就更稳。
最后提醒：podAntiAffinity 规则本身不消耗运行时资源，但调度器在计算时需扫描集群中所有匹配标签的 Pod，若全集群用同一个大范围标签（如 env: prod），会影响大规模集群的调度性能。按服务粒度打标才是可持续做法。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
