如果你已经把这个集群从零搭起来并且让应用稳定跑了一段时间那你大概率遇到过这种场景核心服务的副本明明有好几个却齐齐整整地挤在同一个节点上节点一宕服务直接瘫痪。你反复看调度器它似乎“什么都没做错”但就是没帮你做“高可用”。这就是Kubernetes调度机制的隐性短板——默认的kube-scheduler只保证Pod“能跑起来”不保证“跑得合理”。要解决这类问题就得认真理解亲和力affinity和反亲和力anti-affinity这套机制。这篇文章面向的是已经会用Deployment、Service、nodeSelector但调度只停留在“能用”层面的同学。我会从nodeSelector的边界开始把节点亲和力、Pod亲和力、软硬规则、topologyKey、调度打分这些点一次讲透最后给一套可以直接带进生产的配置和排错经验。1. 默认调度器不够用nodeSelector 的边界在哪1.1 那个凌晨的报警五个副本挤在同一台节点上我接手过一个多可用区的集群核心支付服务在凌晨一点报警5个副本全部调度到了同一个可用区的同一台节点上。节点因为一次内核升级被重启5个Pod同时失联服务直接不可用。事后排查集群里其他节点明明有充足的内存和CPU甚至相邻可用区也有完全空闲的节点调度器完全有机会把Pod分散开但它没有。原因不复杂kube-scheduler对“高可用”这件事没有任何感知。它只做两件事——先过滤掉“跑不了”的节点再给“能跑”的节点打分排序然后选最高分。只要目标节点有足够资源它就不认为把多个同服务副本放在一起有什么问题。这不是Bug是调度器职责边界的缺失。“把关键服务的副本分散到不同节点、不同可用区”“让两个频繁通信的服务离得近一点”这类诉求不是调度器默认会替你考虑的必须写在Pod的spec里。这就是亲和力与反亲和力存在的根本原因。1.2 nodeSelector只能精确等值表达不了“排除某类节点”很多人最早接触的调度手段是nodeSelector。比如给节点打了disktypessd标签然后配置spec: nodeSelector: disktype: ssd它能把Pod定向投放到SSD节点但能力非常有限。我总结过它四个痛点只能做“等于”匹配表达不了“不是GPU节点”“内存大于8GB”“有这个标签就行”这类逻辑。只有硬性要求没有软性偏好。写上去就必须满足不满足Pod永远Pending表达不了“优先放这边放不了也行”。多个键值对之间是AND关系没法写OR。它只根据节点标签过滤压根不关心Pod之间、Pod和节点之间的相对关系。这类“筛选器”式的调度手段在大规模、异构节点、多可用区场景下会迅速显得不够用。亲和力机制就是在这个基础上做的一次全面升级。为了让你快速看清几个手段的定位我做了一张对照表调度手段匹配对象表达能力硬软性典型场景nodeSelector节点标签精确等值只硬快速定向到某类节点nodeAffinity节点标签In、NotIn、Exists、DoesNotExist、Gt、Lt硬软GPU投放、区域合规、排除节点池podAffinityPod标签In、NotIn、Exists、DoesNotExist硬软让相关服务就近部署podAntiAffinityPod标签In、NotIn、Exists、DoesNotExist硬软副本打散、故障域隔离这张表贯穿整篇文章后面的内容基本就是在讲表中后三行的细节。1.3 为什么非要调度器原生支持而不是写脚本改标签可能有人会问既然节点标签能控制调度那我写个脚本定期分析节点负载、资源自动给节点打标签不也能实现类似效果吗可以但维护成本极高。标签是集群的公共状态脚本一改所有Pod的调度结果都会受影响而且脚本逻辑和业务诉求是割裂的别人看你的Deployment根本不知道它为什么会落到这台机器。亲和力机制把“调度策略”做成了声明式API写进YAML就跟写资源请求一样自然。调度器在每次调度时直接读取这些规则既不需要外部脚本也不需要额外前置步骤。这恰恰是Kubernetes设计哲学的一部分把调度偏好沉淀为API对象的一部分而不是放在集群外部的黑盒逻辑里。2. nodeAffinity节点亲和力把“精确匹配”升级成“条件投放”2.1 required 和 preferred硬性底线与软性偏好nodeAffinity的核心是两类规则。看一个最常见写法affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: topology.kubernetes.io/zone operator: In values: - us-east-1a - us-east-1b preferredDuringSchedulingIgnoredDuringExecution: - weight: 80 preference: matchExpressions: - key: node-type operator: In values: - ssdrequiredDuringSchedulingIgnoredDuringExecution是硬性规则调度时如果节点不满足直接淘汰一个都不留。名字里的“DuringScheduling”指调度那一刻检查“IgnoredDuringExecution”指Pod跑起来之后节点的标签就算变了也不会触发驱逐。注意这和污点里的NoExecute不一样NoExecute污点在运行期会持续作用甚至驱逐已运行的Pod亲和力规则没有这种运行期强制能力。preferredDuringSchedulingIgnoredDuringExecution是软性规则“最好满足、不满足也行”。调度器会把满足偏好条件的节点加分权重weight越大加分越多。硬软分离的意图很明显业务里既有“绝不能去哪”的底线也有“最好别去哪/最好去哪”的倾向。这段名字确实长读起来也绕但生产中你会反复看到建议直接背下来。2.2 nodeSelectorTerms 和 matchExpressions 的隐式关系这一节是新手最容易理解错的地方nodeSelectorTerms数组里多个term之间是OR关系而一个term内多个matchExpressions之间是AND关系。换句话说只要满足其中一个term就算满足硬性要求但一个term里所有表达式必须同时成立。我用一个例子说明。以下配置等价于“节点必须在可用区A或可用区B且必须打了gpu标签”requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: topology.kubernetes.io/zone operator: In values: - zone-a - zone-b - key: gpu operator: Exists如果把第二条表达式拆成独立的term含义就完全变了——变成“节点在zone-a或zone-b或者节点有gpu标签”nodeSelectorTerms: - matchExpressions: - key: topology.kubernetes.io/zone operator: In values: - zone-a - zone-b - matchExpressions: - key: gpu operator: Exists这两种写法看着差别不大调度结果天差地别。我见过因为把多个条件拆成多个term导致Pod被调度到非预期节点上的真实事故。写配置的时候先在纸上把AND、OR关系理清楚再用--dry-runserver验证。2.3 operator 的完整家族In、NotIn、Exists、DoesNotExist、Gt、LtnodeAffinity支持六种操作符。日常最常用的是In和NotIn其次是Exists。你可以把它理解成购物网站的筛选器Inkey的值在values列表里相当于勾选几个品牌。NotIn不在列表里相当于排除某些品牌。Exists只要key存在就行不关心值相当于“只看有货的”。DoesNotExistkey不存在相当于“只看没参与活动的”。Gtkey对应的整数值大于指定值。比如按内存大小选节点。Lt小于指定值适合排除内存过小的节点。Gt和Lt只对nodeAffinity生效Pod亲和力里不能用因为Pod亲和力走的是labelSelector没有数值比较。写一个选“内存大于16GB节点”的表达式- key: mem-size operator: Gt values: - 16注意values必须是字符串Kubernetes在比较时会尝试转成整数。如果节点标签值写的是“16GB”这种带单位的串比较会直接失败而且不会有明确报错。这个坑我踩过后来统一规定平台侧的容量标签只写纯数字。2.4 一个综合案例推理服务定向投放到GPU节点池假设集群里有一个GPU节点池和一个普通节点池节点通过gputrue标签标识GPU节点池里又分为A100和T4两种型号。推理服务必须挂在GPU节点上且优先选A100。apiVersion: apps/v1 kind: Deployment metadata: name: inference spec: replicas: 2 selector: matchLabels: app: inference template: metadata: labels: app: inference spec: containers: - name: main image: inference:latest resources: limits: nvidia.com/gpu: 1 affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: gpu operator: Exists preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 preference: matchExpressions: - key: gpu-model operator: In values: - a100硬性规则负责兜底软性规则负责优化。如果集群里A100和T4都有调度器优先选A100节点如果A100节点资源不足T4节点也能接住。这类组合是生产集群里最常用的nodeAffinity场景。3. podAffinity / podAntiAffinity控制Pod与Pod之间的相对位置3.1 为什么有了nodeAffinity还不够nodeAffinity只能管“Pod落在哪类节点上”但很多业务问题的本质不是节点而是Pod之间的相对位置。举两个最常见的例子第一个是“就近组合”。A服务的每个请求都要调B服务如果A跑在可用区1、B跑在可用区2一次跨可用区调用延迟可能从不到1毫秒涨到几十毫秒。在Kubernetes默认调度器眼里这种“需要住得近”的关系毫无存在感。第二个是“副本打散”。即使每个节点都满足条件调度器也可能把同一个Deployment的5个副本放到同一台节点甚至同一个可用区。它不知道两个Pod之间有“同一个服务”这层关系更不知道这份关系意味着“不该住在一起”。nodeAffinity管不了这两件事。它只能对着节点标签做判断而“副本是否重复”“相关服务是否靠近”需要的是对Pod的感知。于是Kubernetes给了第二套机制podAffinity和podAntiAffinity。3.2 podAffinity让“好搭档”住得近podAffinity的思路是调度新Pod时先按labelSelector找出集群里已有的匹配Pod看它们分布在哪几个拓扑域里然后把新Pod调度到这些拓扑域上。拓扑域由topologyKey决定后面会细讲。举个具体例子。web服务想和cache服务待在同一个可用区减少缓存命中延迟affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - cache topologyKey: topology.kubernetes.io/zone调度web的Pod时调度器会先找所有appcache的Pod看它们落在哪些zone如果cache在zone-a和zone-b都有web的新Pod只会去这两个zone别的zone直接过滤掉。这就是“和谁住在一起”的控制。如果你不希望把范围限定在当前命名空间可以加上namespaces字段指定一个列表。用生活类比这就好比学校里安排宿舍默认只看床位数和硬件条件但你希望“某个社团的成员必须住在同一栋楼”podAffinity就是这条规则。3.3 podAntiAffinity把高风险副本拆开podAntiAffinity正好相反——新Pod要避开那些“已有匹配Pod”的拓扑域。最典型的用途就是同一个服务的多副本不能在同一个节点上affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - web topologyKey: kubernetes.io/hostname配置含义是调度每个web Pod时目标节点上只要存在appweb的Pod就拒绝接纳新Pod。于是5个副本必然分散到5个不同节点。如果我把topologyKey换成topology.kubernetes.io/zone含义就变成“5个副本不能落在同一个可用区”——不同节点无所谓但不能共享可用区。这是高可用部署里最常见的一个用法。你只需要声明“副本之间保持距离”具体怎么分布交给调度器。3.4 topologyKey决定“散开到哪里”的粒度topologyKey是整套机制里最容易忽略又最关键的字段。它是节点标签的key用来定义“一个拓扑域”的边界。同样一条反亲和规则topologyKey不同“保持距离”的粒度就完全不同kubernetes.io/hostname按节点划分反亲和就是“不同节点”亲和就是“同一节点”。topology.kubernetes.io/zone按可用区划分反亲和就是“不同可用区”。topology.kubernetes.io/region按地域划分跨区域容灾才用得上。选型建议普通服务做高可用反亲和最少按zone打散因为单点故障不只是节点宕机也可能是整个可用区的网络问题。如果只是为了防节点故障按hostname就够。但要注意按zone打散要求集群实际跨了多个可用区并且云端实例的zone标签正确注入。老集群里zone标签叫failure-domain.beta.kubernetes.io/zone新版本统一成topology.kubernetes.io/zone动手写配置前先看一眼节点真实标签。topologyKey不只是“选哪个粒度”的问题它直接决定了反亲和能容纳多少副本。下一节会说清楚。3.5 反亲和的算术题副本数不能超过拓扑域数required反亲和有一个硬性算术关系可调度位置的上限等于满足条件的拓扑域数量。假设集群只有3个节点你用topologyKey: kubernetes.io/hostname做required反亲和最多只能容纳3个匹配该规则的Pod第4个永远Pending调度事件里会写didnt match pod anti-affinity rules。这个数字关系在扩容和滚动更新时尤其致命。很多团队在Deployment里配了required反亲和副本数和节点数刚好相等一开始没问题后面应用扩容Pod直接挂起HPA触发半天也加不上Pod业务压力全打在现有副本上。比较稳妥的做法是核心服务用required反亲和并且预留冗余节点一般服务用preferred反亲和作为倾向而不是硬约束。这个选择在后面实战章节还会展开。4. 软规则的打分逻辑weight 到底是怎么起作用的4.1 调度器视角先过滤再打分理解了规则还必须理解这些规则在调度器里是怎么执行的否则你很难解释“为什么我weight设100还是没生效”。kube-scheduler的调度循环简化为两个阶段Filter阶段把不满足硬性条件的节点筛掉。资源不足、端口冲突、required亲和力不满足、污点不容忍都会在这一步出局。Score阶段给剩余节点打分然后选分最高的。打分的维度有很多资源余量、Pod分布均匀度、亲和力偏好等各自有不同权重。preferred亲和力属于Score阶段它永远不会让一个节点通过不了Filter。如果一个节点根本没有你要的GPU标签那它连Filter都过不了你给它preferred加多少分都没用。很多人调大weight发现“没效果”多半是把它当成了硬性要求来用。4.2 weight 的叠加过程偏好如何换算成分数nodeAffinity的preferred打分逻辑大致是把节点匹配到的所有preference的weight加起来除以本轮所有preference的weight总和换算成0-100的一个偏好分。假设你设置了三个偏好weight分别是10、50、40一个节点匹配全部偏好就拿100分匹配两个拿60分匹配一个拿10分。podAffinity和podAntiAffinity的打分逻辑更复杂一点它和“匹配Pod的数量”挂钩。比如preferred反亲和目标拓扑域上已经有越多的匹配Pod给节点打的分数就越低没有匹配Pod的拓扑域得分最高。preferred亲和则反过来目标拓扑域上匹配Pod越多得分越高。这里补一个我在排查时用过的技巧想确认亲和力规则有没有真正写进Pod spec执行kubectl get pod pod-name -o jsonpath{.spec.affinity} | python3 -m json.tool如果输出为空说明你apply的YAML里affinity字段根本没生效先检查缩进和字段名。4.3 一次真实扩容preferred反亲和如何避免Pending我管理过一个业务副本数从20扩到30节点只有10台。如果按惯例写requiredDuringSchedulingIgnoredDuringExecution的hostname反亲和第11个Pod必然Pending整个扩容流程卡死。当时的处理是把反亲和改成preferredpreferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: app operator: In values: - web topologyKey: kubernetes.io/hostname调度器仍然倾向于把副本分散到不同节点但节点不够时会容忍同一节点放两份只是扣分。结果是正常情况下能分散就分散节点不足时也能完成扩容代价是部分节点压力偏高。这个案例能很直观地说明软规则到底“有多软”——它不是约束是倾向。4.4 多个调度插件的总得分亲和力只是其中一项需要建立的一个认知是亲和力分数只是Score阶段众多插件之一。NodeResourcesFit会根据节点空闲资源打分SelectorSpread会根据Pod分布均衡度打分TaintToleration也有自己的规则这些分数会汇总。所以weight100的亲和力偏好不一定打得过一个“资源极其空闲”的节点在资源分上的巨大优势。平台方向如果想精确控制各维度权重可以调整kube-scheduler配置文件里的插件顺序和权重。但绝大多数业务场景没必要碰这个默认顺序已经足够合理。搞清楚“亲和力分数只是总分的组成部分”这件事比调高weight更有意义。5. 一套可落地的实战配置与排错经验5.1 Web服务的高可用标配节点过滤 副本打散回到文章开头那个凌晨报警的场景。现在我会给这类Web服务做一套组合配置required nodeAffinity限定只能落在生产节点preferred podAntiAffinity把同一服务的副本尽量散开。apiVersion: apps/v1 kind: Deployment metadata: name: web-demo spec: replicas: 3 selector: matchLabels: app: web-demo template: metadata: labels: app: web-demo spec: containers: - name: nginx image: nginx:1.25 ports: - containerPort: 80 affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: environment operator: In values: - production podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: topologyKey: kubernetes.io/hostname labelSelector: matchExpressions: - key: app operator: In values: - web-demo这个配置有两个优点。第一由于有preferred调度器在节点紧张时会自动容忍同一节点放两份不会把扩容卡死第二在节点充足时不同副本会尽量落在不同节点单节点故障的影响被限制在1/N。如果你想要更高级别的容灾把topologyKey改成topology.kubernetes.io/zone再加几个可用区的标签校验就能做到跨可用区副本分布。但注意跨区打散必须确保集群至少有两个可用区的节点否则preferred还好required一定Pending。5.2 StatefulSet的反亲和力滚动更新会卡死的坑如果你管理的是中间件或数据库类的StatefulSet反亲和力配置要格外小心。StatefulSet的滚动更新策略是“删一个旧Pod建一个新Pod”串行推进。假设副本数是4节点一共4台你配了required hostname反亲和更新到一半时新的Pod要被调度但4个节点上已经各有1个旧Pod占着位置新Pod找不到任何可用节点滚动更新卡死在那里。我真实踩过这个坑中间件集群从3节点扩到4节点节点就4台更新时Pod全部Pending事件里全是didnt match pod anti-affinity rules。后来把required改成preferred才解开。所以对StatefulSet我的建议是要么用preferred反亲和要么在滚动更新时预留一个空节点周转不要在“副本数节点数”的情况下用required反亲和。5.3 完整排错链路从Pending事件反推根因配置了亲和力之后Pod起不来是常见现象。排错时按下面几步走第一步用describe看事件kubectl describe pod pod-name | grep -A 15 Events重点看最后的FailedScheduling信息里面会直接告诉你“0/4 nodes are available: 4 node(s) didnt match pod anti-affinity rules”或者“1 node(s) didnt match node selector”之类的结论。第二步要区分是nodeAffinity还是podAntiAffinity导致的拒绝。如果message里有didnt match node selector或didnt match node affinity去看节点标签如果出现didnt match pod anti-affinity rules优先检查三件事labelSelector是不是匹配到了太多Pod、topologyKey写没写对、副本数是不是超过了拓扑域数量。第三步核对节点标签kubectl get nodes --show-labels特别关注zone、region这类云厂商注入的标签老集群和新集群的key不一样。第四步看现有Pod分布kubectl get pods -o wide做完这四步绝大多数亲和力相关的问题都能定位。5.4 亲和力和污点、容忍度的配合双重保险最后说一下亲和力与污点Taint、容忍度Toleration的关系。亲和力解决的是“Pod想去哪”污点解决的是“节点拒绝谁”。调度器先做污点过滤再做亲和力过滤两条链路是叠加的。最常见的配合是GPU节点。给GPU节点打一个污点gputrue:NoSchedule普通Pod没有对应容忍度连Filter阶段都过不了推理Pod同时声明容忍度和nodeAffinity的gputrue硬性要求既确保能通过污点过滤又确保定向落在GPU节点上。这就是双保险一个从节点侧做排斥一个从Pod侧做吸引。反过来也成立如果只有容忍度没有亲和力Pod只是“允许”调度到GPU节点调度器并不保证一定去通常还需要配套节点选择或亲和力来“锁死”目标。5.5 我总结的五条实战原则文章最后把自己在多个集群里反复趟坑后总结出来的原则列在这里也算给这套机制做一个收束第一能用preferred就别用required除非有合规约束或者明确的故障隔离要求。required一旦和拓扑域数量对上扩容就是灾难。第二反亲和的topologyKey优先用topology.kubernetes.io/zone单节点故障和可用区故障都能扛如果只关心节点级故障再退回hostname。第三动手前先看节点标签。新旧版本集群的zone标签key不一样标签看清楚了再写YAML。第四不要给所有服务都加反亲和。每一条规则都会让调度器在调度时多执行一次匹配计算大规模集群里全部服务都塞反亲和调度耗时明显上升平台侧会很难受。第五HPA加副本数的场景一定要想清楚“最大副本数是否超过可用拓扑域数”。这个数字对不上required反亲和带来的不是高可用而是扩容事故。