亲和性与反亲和性用于精细控制Pod调度，提升应用性能与稳定性。亲和性分节点亲和性（如将Pod调度到带SSD的节点）和Pod亲和性（如让缓存与应用同节点以降低延迟），支持required（硬性要求）和preferred（软性偏好）两种模式。反亲和性则用于避免调度，如节点反亲和性防止敏感应用部署在公共区域，Pod反亲和性确保同一应用副本分布在不同节点，防止单点故障。典型用例是通过topologyKey为kubernetes.io/hostname的Pod反亲和性实现副本跨节点部署。常用于数据库与缓存同可用区部署、GPU任务调度至GPU节点、生产与开发环境隔离等场景。合理使用可显著提升资源利用率与系统可靠性。
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 反亲和性实现应用副本跨节点部署：
用Apache Spark进行大数据处理
下载
本文档主要讲述的是用Apache Spark进行大数据处理——第一部分：入门介绍；Apache Spark是一个围绕速度、易用性和复杂分析构建的大数据处理框架。最初在2009年由加州大学伯克利分校的AMPLab开发，并于2010年成为Apache的开源项目之一。 在这个Apache Spark文章系列的第一部分中，我们将了解到什么是Spark，它与典型的MapReduce解决方案的比较以及它如何为大数据处理提供了一套完整的工具。希望本文档会给有需要的朋友带来帮助；感
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（反亲和性）。
基本上就这些。合理使用亲和性与反亲和性，能显著提升应用的性能、稳定性和资源利用率。
