Kubernetes 的亲和性(Affinity)与反亲和性(Anti-affinity)是用来控制 Pod 调度行为的规则,帮助你决定 Pod 应该或不应该部署在哪些节点上,或者与其他 Pod 的部署关系。它们是对基本节点选择器(nodeSelector)的增强,提供更精细、更灵活的调度策略。
亲和性(Affinity)
亲和性用于“吸引”Pod 到特定节点或其他 Pod 附近。它分为两种类型:
• 节点亲和性(Node Affinity):根据节点的标签来决定 Pod 可以调度到哪些节点上。例如,将某个应用只部署在带有 SSD 磁盘的节点上。• Pod 亲和性(Pod Affinity):根据已运行的 Pod 的标签,让新 Pod 调度到与这些 Pod 处于同一拓扑域(如同一个节点、同一个区域)的位置。比如,让缓存服务尽量和应用 Pod 部署在同一节点,减少网络延迟。
节点亲和性支持两种操作模式:
requiredDuringSchedulingIgnoredDuringExecution:硬性要求,必须满足,否则 Pod 不会被调度。 preferredDuringSchedulingIgnoredDuringExecution:软性偏好,尽量满足,但不保证。反亲和性(Anti-Affinity)
反亲和性用于“排斥”Pod,避免它们被调度到某些位置。同样分为两类:
• 节点反亲和性:避免将 Pod 调度到具有特定标签的节点上。例如,避免将敏感应用部署在公共网络区域的节点。• Pod 反亲和性(Pod Anti-Affinity):防止当前 Pod 与具有特定标签的其他 Pod 运行在同一拓扑域中。常用于高可用场景,比如确保同一应用的多个副本分布在不同节点上,防止单点故障。
一个典型用例是使用 Pod 反亲和性实现应用副本跨节点部署:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- my-app
topologyKey: kubernetes.io/hostname
这段配置表示:新 Pod 必须不能与标签 app=my-app 的 Pod 运行在同一个节点上(topologyKey 设置为节点主机名)。
实际应用场景
亲和性和反亲和性常用于以下场景:
将数据库和缓存部署在同一可用区以降低延迟(节点亲和性)。 确保关键服务的不同副本分散在多个节点或区域(Pod 反亲和性)。 将 GPU 密集型任务只调度到有 GPU 的节点(节点亲和性)。 隔离开发和生产环境的 Pod(反亲和性)。基本上就这些。合理使用亲和性与反亲和性,能显著提升应用的性能、稳定性和资源利用率。
