1.Pod亲和性 (Pod Affinity)
作用：
- 资源协同：当Pod需要与具有特定标签的Node或已经在特定Node上运行的Pod紧密合作时，比如共享硬件加速器或者进行高效的数据交互，可以利用Pod亲和性将这些Pod调度到一起。
- 负载分片：在大规模集群中，可以根据业务需求，将相似类型的Pod调度到同一组Node上，以实现数据局部性、减少网络开销或优化整体性能。
如何使用：
Pod亲和性通过affinity字段中的podAffinity和nodeAffinity设置。例如，创建一个Deployment时，可以在其YAML配置文件中添加以下内容：
spec: affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: ["myapp"] topologyKey: "kubernetes.io/hostname" nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: zone operator: In values: ["us-west1-a"]
在这个例子中，我们设置了两个亲和性规则：
- Pod亲和性：要求Pod被调度到那些已经运行了标签为
app=myapp的Pod的节点上，且依据kubernetes.io/hostname这一拓扑键进行判断。 - Node亲和性：强制Pod只能被调度到标签为
zone=us-west1-a的节点上。
2.Pod反亲和性 (Pod Anti-Affinity)
作用：
- 高可用性：为了确保服务的冗余性和容错性，可以设置Pod反亲和性，让相同服务的不同实例分布在不同的Node上，以避免单一节点故障影响整个服务。
- 资源隔离：当一些Pod消耗大量资源，为了避免资源竞争或达到更好的负载均衡效果，可以设置反亲和性，确保这些Pod不会被调度到同一台机器上。
如何使用：
同样在affinity字段中设置podAntiAffinity和nodeAntiAffinity。例如：
spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: ["myapp"] topologyKey: "kubernetes.io/hostname" nodeAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: failure-domain.beta.kubernetes.io/zone operator: NotIn values: ["us-west1-a"]
这个例子中，我们指定了两个反亲和性规则：
- Pod反亲和性：强制当前Pod不能与标签为
app=myapp的Pod调度到同一台机器上，依然是基于kubernetes.io/hostname拓扑键判断。 - Node反亲和性：强制Pod不能被调度到标签为
failure-domain.beta.kubernetes.io/zone=us-west1-a的节点上，从而实现跨Zone的高可用部署。
3.区别：
- 方向性: Pod亲和性强调的是Pod间的聚集或关联调度，而反亲和性则是强调Pod间的分离或避免共同调度。
- 目的: 亲和性通常用于提高服务间协作效率或平衡资源分布；反亲和性更多是为了增强服务的冗余性和故障恢复能力。
- 效果: 设置亲和性可能导致相关Pod在物理上或逻辑上更加接近；设置反亲和性则促使Pod尽可能远离某些特定的Pod或节点。
综上所述，在实际应用中，Kubernetes 的Pod亲和性和反亲和性提供了灵活的调度策略，帮助运维人员更好地管理分布式系统的可靠性和性能。
