Kubernetes作为容器编排领域的标杆，其调度策略直接影响应用性能和稳定性。节点亲和（Node Affinity）与反亲和（Anti-Affinity）是精细化调度的重要工具，能够根据节点标签、拓扑域等条件，智能控制Pod的分布逻辑。本文将深入解析其实践技巧，帮助开发者规避资源竞争、提升容错能力并优化资源利用率。
节点亲和基础配置
节点亲和性通过`requiredDuringSchedulingIgnoredDuringExecution`和`preferredDuringSchedulingIgnoredDuringExecution`两种规则实现硬约束与软约束。例如将数据库Pod强制调度到带`disk=ssd`标签的节点，可配置必须匹配的节点选择器；而优先但不强制部署到高可用区则适合软约束。实践时需注意避免硬约束过多导致调度失败。
反亲和实现高可用
通过`podAntiAffinity`可防止单点故障。比如定义Web服务Pod的反亲和规则，确保同一服务的多个实例分散在不同可用区。关键参数`topologyKey`需设置为`topology.kubernetes.io/zone`等标准拓扑域，同时配合`labelSelector`精准匹配目标Pod。生产环境中建议优先使用软反亲和避免调度僵局。
动态污点与容忍配合
节点亲和常与污点（Taint）机制协同使用。例如给GPU节点添加`accelerator=gpu:NoSchedule`污点后，只有声明对应容忍的Pod才能被调度，再结合节点亲和规则进一步筛选。这种组合既能保留特殊资源，又能实现精确调度，尤其适合AI训练等场景。
多维度权重调优
当存在多个亲和性规则时，`weight`字段（1-100范围）可定义优先级。例如跨机房部署时，给机架拓扑的亲和性设置更高权重，确保优先满足跨机架容灾，其次再考虑CPU架构匹配。通过权重分层策略，可构建多维度的调度层次结构。
实战避坑指南
常见误区包括：过度使用硬约束导致PodPending、拓扑域定义不完整影响反亲和效果、忽略节点标签更新需手动触发重新调度等。建议通过`kubectl describe node`验证标签，用`kubectl get pods -o wide`观察实际分布，并配合调度事件监控及时发现问题。