亲和性与反亲和性调度策略是Kubernetes中控制Pod部署位置的核心机制，解决"Pod该跑到哪台机器上"的问题，简单说：亲和性让Pod靠近或固定到指定节点，反亲和性让Pod分散开避免扎堆。
k8s亲和性和反亲和性区别是什么
要理解这对概念，先想象一个宿舍分配场景，亲和性就像你申请住到篮球场旁边，因为每天要去打球；反亲和性就像你申请不要和室友住同一间，因为你怕吵，K8s调度器干的就是宿管阿姨的活,根据你的要求分配床位。
从技术层面拆解,亲和性分为两大类。
节点亲和性：Pod和机器的关系
节点亲和性（nodeAffinity）管的是Pod与节点（机器）之间的匹配逻辑，它代替了早期的nodeSelector，功能更精细，比如你的集群里有GPU服务器和普通CPU服务器，训练任务就想跑到GPU节点上，这时写一条规则，让Pod只调度到带gpu=true标签的节点,这就是节点亲和性在起作用。
节点亲和性支持两种策略：
- requiredDuringSchedulingIgnoredDuringExecution：硬性要求，没有满足条件的节点，Pod就调度不上去,一直Pending。
- preferredDuringSchedulingIgnoredDuringExecution：软偏好，优先挑符合条件的节点,实在没有也能跑到别处去。
Pod亲和性：Pod和Pod的关系
Pod亲和性（podAffinity）管的是Pod之间的远近关系，比如网关服务和认证服务之间通信量大，希望它们部署在同一台机器上，减少网络跳数，这就用Pod亲和性让它们"贴贴"。
Pod反亲和性（podAntiAffinity）则恰好相反，它让Pod分散部署，核心系统的高可用架构里，同一个服务的多个副本一般要打散到不同节点上，防止一台物理机挂了,所有副本同时挂掉。
硬策略与软策略怎么组合
调度器执行规则时有"必须"和"尽量"两种级别，术语叫requiredDuringScheduling和preferredDuringScheduling，名字太长记不住很正常，你只需记住"required是铁律，preferred是偏好"。
实际配置里,组合思路是这样：
- 生产环境的数据库实例，用required硬反亲和，强制分散到不同可用区
- 日志采集这种辅助Pod，用preferred软亲和，能跟主应用跑到一起最好，跑不到也不影响
- 缓存类服务，既要有反亲和打散副本，又要亲和到特定硬件节点，两条规则叠加
关键配置写法
配置亲和性策略其实不复杂，核心就是写labels标签匹配,下面是一个节点反亲和性的例子：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
replicas: 3
template:
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- nginx
topologyKey: kubernetes.io/hostname
这个配置干的事：强制要求这3个nginx副本，必须分散到不同的hostname节点上,不能有任意两个副本待在同一台机器。
topologyKey是反亲和生效范围的设定项，它决定"分散到什么粒度",常见取值：
- kubernetes.io/hostname：按节点维度打散
- topology.kubernetes.io/zone：按可用区维度打散
- topology.kubernetes.io/region：按地域维度打散
pod反亲和性部署场景有哪些
生产环境里用得最多的就是Pod反亲和性，多实例高可用部署是核心场景，比如电商系统的用户服务，你开了5个副本，如果不加反亲和，调度器可能把3个副本都塞到同一台物理机上，这台机器一旦宕机或者被运维重启,用户服务直接失去一大半能力。
高可用多副本打散
解决办法是给Deployment加上podAntiAffinity规则，让每个副本落到不同节点，行业共识认为，生产环境的无状态应用都应该考虑加一层软反亲和，成本低、收益明显。
故障域隔离
如果集群跨多个可用区，比如用了云厂商的多可用区架构，反亲和策略的topologyKey要换成topology.kubernetes.io/zone，保证副本分散到不同机房，而不是只分散到同一机房的不同机器，单机房断电时,其他机房的副本还能扛住流量。
避免流量热点
业务层有多个互斥的服务，比如两个CPU密集型的计算任务，它们同时跑到同一台机器上，会互相抢资源导致整节点过载，给它们设置相互反亲和，可以错开调度位置,机器负载更均衡。
kubernetes节点亲和性配置方法
节点亲和性的配置场景集中在"把任务固定到指定硬件"上,实操中按这几步走。
第一步：给节点打标签
节点亲和性依赖标签，先给节点标记好属性，比如一台机器装了SSD,准备跑数据库：
kubectl label node node01 disk-type=ssd
第二步：在Deployment里写亲和性规则
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: disk-type
operator: In
values:
- ssd
写好后apply，调度器就会把这个Pod安排到disk-type=ssd的节点上。
第三步：用软策略提升资源利用率
只写硬性规则的话，如果ssd节点资源满了，Pod会一直Pending,更灵活的做法是硬性指定加上软性偏好组合：
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: disk-type
operator: In
values:
- ssd
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 50
preference:
matchExpressions:
- key: zone
operator: In
values:
- east-1
这段配置表示：必须跑到ssd机器上，在这个前提下优先选east-1可用区的机器。
节点亲和性 vs 节点反亲和性
节点亲和性解决"让Pod去指定节点"，节点反亲和性解决"让Pod别去某些节点"，它们不冲突，可以同时配置，比如要求Pod必须跑在SSD节点上，但又不要去GPU专属机器,两条规则一起写就行。
多实例部署怎么平衡亲和与反亲和
大规模集群里，最常见的需求其实是"既要有一定集中，又要避免过度集中"。
自研中间件的特殊需求
有状态的中间件，比如Kafka或Elasticsearch，副本之间需要跨节点通信但又要保证数据分片分散，很多运维团队会用软反亲和加Pod拓扑分布约束
（topologySpreadConstraints）组合，拓扑分布约束是比亲和性更精细的调度工具,它能让Pod按比例均匀分布到节点或可用区上：
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app: kafka
maxSkew=1表示任意两个节点上的Pod数量差距不超过1，均匀分布,这套配置在多地多集群的部署里已经是标准操作。
单体应用拆分后的服务编排
微服务拆分完成后，调用链变长，服务之间的亲和性需求大增，网关与核心服务用软亲和让它们尽量靠近，减少跨节点调用延迟；网关的多个副本之间用反亲和打散，保证可用性，亲和与反亲和对同一组Pod同时生效,并不矛盾。
亲和性调度常见的坑和排查思路
规则写错或者理解偏了，会导致Pod一直Pending,排查时按下面步骤来。
kubectl describe pod看Events字段，Pending原因会直接显示FailedScheduling，同时附带的message会说明具体哪条规则不满足- 检查节点的labels是否打对，用
kubectl get nodes --show-labels确认 - 检查拓扑key是否匹配，节点反亲和依赖topologyKey，如果节点没有这个key，规则直接失效
- 软策略权重是1-100的整数，权重设置不同，调度优先级不同，但别指望软策略绝对可靠
Q&A补充
Q：k8s亲和性和反亲和性区别是什么？
A：亲和性让Pod集中到特定节点或靠近特定Pod，反亲和性让Pod避开特定节点或相互分散，前者用于资源匹配和通信优化,后者用于高可用和故障隔离。
Q：反亲和性策略会导致Pod调度失败吗？
A：硬反亲和（required）在多副本数超过节点数时必然调度失败，因为找不到足够多的节点，处理办法是改用软反亲和（preferred）,或者扩大节点池规模。
Q：topologyKey怎么选？
A：如果只关心单机层面的分散，用kubernetes.io/hostname；如果集群跨机房，用topology.kubernetes.io/zone，选择时先想清楚故障域到底是什么,主机故障还是机房故障。