Pod亲和性与反亲和性是Kubernetes调度核心能力，需结合标签、拓扑域（topologyKey）和策略类型（required/preferred）精准配置：podAffinity用于就近部署，podAntiAffinity用于分散部署；topologyKey决定作用范围，如hostname（节点级）、zone（可用区级）；硬约束require不满足则Pending，软偏好preferred带权重打分；labelSelector匹配目标Pod标签，须确保其真实存在且可被发现。
Pod 亲和性与反亲和性是 Kubernetes 中控制 Pod 分布逻辑的核心调度能力，不是“要不要用”的问题，而是“怎么用对”的问题。关键不在于写几行 YAML，而在于理解标签、拓扑域和策略类型三者的配合关系。
明确你要解决的问题场景
先判断需求本质：是想让 Pod 靠近 某些已有 Pod（比如前端紧贴缓存），还是 避开 它们（比如避免多个数据库副本挤在同一节点）？前者用 podAffinity，后者用 podAntiAffinity。别混淆成节点标签匹配——那是 nodeAffinity 的事。
选对 topologyKey 决定调度粒度topologyKey 是划分“同一位置”的标准，直接影响规则生效范围：
-
kubernetes.io/hostname→ 每个节点独立为一个域，实现“同节点”或“不同节点”部署 -
topology.kubernetes.io/zone→ 可用区级别，适合跨 AZ 高可用 -
topology.kubernetes.io/region→ 地域级别，适用于多地域容灾
注意：该 key 必须对应节点上真实存在的标签，可通过kubectl get nodes -o wide查看。
硬约束与软偏好必须区分使用
-
requiredDuringSchedulingIgnoredDuringExecution是刚性要求：不满足就 Pending，适合强依赖场景（如主从不能同节点） -
preferredDuringSchedulingIgnoredDuringExecution是柔性倾向：带weight（1–100），调度器会打分优选，但不保证一定命中，适合性能优化类需求（如优先调度到 SSD 节点）
生产环境常见组合：用硬反亲和保障副本分散，再叠加软亲和倾向高性能节点。
标签选择器要精准且可维护labelSelector 匹配的是 其他 Pod 的标签，不是节点标签。常用写法：
-
matchLabels: { app: nginx }—— 简洁匹配 -
matchExpressions支持更灵活操作：- key: tier operator: In values: ["backend"] - key: version operator: NotIn values: ["v1.0-beta"]
务必确保目标 Pod 确实带有这些标签，否则规则无效；建议统一通过 Deployment 的
template.metadata.labels注入，避免手动打标遗漏。
部署前务必验证前提条件
硬性规则失败常因客观限制：
- 节点数 < 副本数 → 反亲和无法满足，Pod 卡在 Pending
- 所有节点缺失对应 topologyKey 标签 → 调度器找不到拓扑域，直接拒绝
- 目标标签的 Pod 尚未运行 → 亲和性无参照对象，同样无法调度
建议先执行kubectl get nodes --show-labels和kubectl get pods -l app=xxx --show-labels确认基础环境，再用kubectl apply --dry-run=client -o wide预检调度可行性。
