Pod调度亲和性机制概述

Kubernetes Pod调度亲和性是控制Pod与节点、Pod与Pod之间位置关系的核心机制。在大规模集群中，合理配置亲和性规则能够有效提升服务可用性、降低跨可用区流量成本、保障性能敏感型工作负载的资源独占。Kubernetes调度器在Filter阶段根据亲和性规则筛选候选节点，在Score阶段对满足亲和性的节点加权打分，最终选择最优节点绑定。

亲和性规则分为节点亲和性（Node Affinity）和Pod间亲和性（Pod Affinity/Anti-Affinity）两大类。节点亲和性约束Pod运行在具备特定标签的节点上，Pod间亲和性约束Pod与指定标签的其他Pod运行在同一拓扑域或不同拓扑域。

节点亲和性requiredDuringScheduling与preferredDuringScheduling

节点亲和性提供硬性要求和软性偏好两种模式：

apiVersion: v1kind: Podmetadata:  name: gpu-workloadspec:  affinity:    nodeAffinity:      requiredDuringSchedulingIgnoredDuringExecution:        nodeSelectorTerms:        - matchExpressions:          - key: node.kubernetes.io/instance-type            operator: In            values: ["p4d.24xlarge"]      preferredDuringSchedulingIgnoredDuringExecution:      - weight: 80        preference:          matchExpressions:          - key: topology.kubernetes.io/zone            operator: In            values: ["us-east-1a"]

requiredDuringSchedulingIgnoredDuringExecution是硬性约束，不满足条件的节点直接淘汰。preferredDuringSchedulingIgnoredDuringExecution是软性偏好，weight取值1~100，调度器在打分阶段对满足偏好的节点增加对应权重分。上面示例表示Pod必须调度到p4d实例类型节点，优先选择us-east-1a可用区。

operator支持In、NotIn、Exists、DoesNotExist、Gt、Lt六种操作符，覆盖绝大多数标签匹配场景。

Pod间亲和与反亲和的拓扑域配置

Pod间亲和性通过topologyKey指定拓扑域维度。同一拓扑域内的节点共享相同标签值。典型用法：

affinity:  podAntiAffinity:    preferredDuringSchedulingIgnoredDuringExecution:    - weight: 100      podAffinityTerm:        labelSelector:          matchExpressions:          - key: app            operator: In            values: ["api-server"]        topologyKey: topology.kubernetes.io/zone

这段配置确保同一个Deployment的api-server Pod尽量分散到不同可用区。topologyKey设为zone表示以可用区为拓扑域，同区内的节点被视为同一拓扑域。若改为kubernetes.io/hostname，则表示以单节点为拓扑域，强制每个Pod独占一个节点。

生产环境推荐：有状态服务（如数据库主从）使用Pod反亲和+zone拓扑域，确保主从分布在不同可用区；无状态服务使用Pod反亲和+hostname拓扑域，避免同一节点堆积过多副本。

Topology Spread Constraints拓扑分布约束

拓扑分布约束比Pod反亲和更精细地控制Pod在拓扑域上的均匀分布：

apiVersion: v1kind: Podmetadata:  name: web-appspec:  topologySpreadConstraints:  - maxSkew: 1    topologyKey: topology.kubernetes.io/zone    whenUnsatisfiable: DoNotSchedule    labelSelector:      matchLabels:        app: web  - maxSkew: 1    topologyKey: kubernetes.io/hostname    whenUnsatisfiable: ScheduleAnyway    labelSelector:      matchLabels:        app: web

maxSkew定义最大偏差，即拓扑域间Pod数量的最大差值。maxSkew=1意味着任意两个可用区的web Pod数量差异不超过1。whenUnsatisfiable=DoNotSchedule是硬性约束，偏差超过maxSkew时拒绝调度；ScheduleAnyway是软性约束，偏差较大时降低打分但不拒绝。

拓扑分布约束相比Pod反亲和的优势：反亲和只能在”同一拓扑域有Pod则避开”和”不同拓扑域有Pod则靠近”之间选择，无法精确控制分布均匀度；拓扑分布约束通过maxSkew精确量化偏差容忍度，适合大规模集群中需要均匀分布的场景。

亲和性规则与拓扑约束的优先级关系

调度器处理顺序：节点硬性亲和性筛选 -> Pod硬性反亲和性筛选 -> 拓扑分布硬约束筛选 -> 节点软性亲和性打分 -> Pod软性反亲和性打分 -> 拓扑分布软约束打分。硬性规则之间是AND关系，必须同时满足。软性规则的weight值越大优先级越高。

常见陷阱：硬性节点亲和与硬性Pod反亲和组合导致无节点可调度，Pod一直Pending。调试时用kubectl describe pod查看调度失败原因，逐条排查约束是否过严。建议生产环境优先使用preferredDuringScheduling软约束，保留调度灵活性。

Pod调度亲和性与反亲和性机制

Kubernetes调度器决定Pod运行在哪个节点上，亲和性（Affinity）和反亲和性（Anti-Affinity）规则是最精细的调度控制手段。亲和性让Pod倾向调度到满足条件的节点，反亲和性让Pod远离特定节点，两者结合实现高可用、低延迟、故障隔离等目标。

亲和性分nodeAffinity和podAffinity两类：nodeAffinity基于节点标签筛选，podAffinity基于已有Pod的拓扑位置筛选。以下配置让Web Pod调度到有SSD标签的节点，且与同一Deployment的其他副本分散在不同可用区：

apiVersion: v1
kind: Pod
metadata:
name: web-server
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: disk-type
operator: In
values: ["ssd"]
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchLabels:
app: web-server
topologyKey: topology.kubernetes.io/zone

requiredDuringScheduling前缀表示硬性约束，不满足则Pod无法调度（Pending状态）；preferredDuringScheduling前缀表示软性偏好，调度器尽量满足但不保证。

Topology Spread Constraints拓扑分布约束

亲和性规则在处理多副本均匀分布时逻辑复杂，Kubernetes 1.19引入的Topology Spread Constraints提供了更直观的方案。它基于拓扑域（如可用区、节点）将Pod均匀分布，避免所有副本集中在同一域内。

apiVersion: apps/v1
kind: Deployment
metadata:
name: api-server
spec:
replicas: 6
selector:
matchLabels:
app: api-server
template:
metadata:
labels:
app: api-server
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: api-server
- maxSkew: 2
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app: api-server

maxSkew定义最大偏斜度——拓扑域间Pod数量的最大差值。whenUnsatisfiable: DoNotSchedule表示硬性约束（类似required），ScheduleAnyway表示软性约束（类似preferred）。上面配置确保6个副本在可用区间均匀分布（差值不超过1），在节点间尽量均匀（差值不超过2）。

调度策略与PDB联动

Pod调度不仅影响初始放置，还影响滚动更新和节点维护期间的可用性。Pod Disruption Budget（PDB）与亲和性规则联动，确保在主动驱逐Pod时不超过最小可用数量：

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: api-server-pdb
spec:
minAvailable: 4
selector:
matchLabels:
app: api-server

PDB限制同一时刻被驱逐的Pod数量，配合反亲和性规则确保6副本中始终有4个以上处于Ready状态。节点排空（kubectl drain）时调度器会遵守PDB约束，逐批迁移Pod而非一次性驱逐。

自定义调度器与打分扩展

内置调度器无法覆盖所有场景时，可通过Scheduler Framework扩展调度逻辑。常见扩展点包括Filter（过滤不满足条件的节点）、Score（对候选节点打分）、Bind（执行绑定决策）。以下是一个自定义打分插件的示例：

import prometheus_client

# 注册到Scheduler Framework
# apiVersion: kubescheduler.config.k8s.io/v1
# kind: KubeSchedulerConfiguration
# profiles:
# - schedulerName: custom-scheduler
# plugins:
# score:
# enabled:
# - name: CpuUsageScore

自定义调度器适用于GPU共享调度、NUMA感知调度、跨集群调度等特殊场景。开发时注意Score插件的调用频率极高（每个Pod调度时对所有候选节点打分），内部逻辑必须轻量，重计算应预缓存。

常见调度故障排查

Pod调度失败时通过kubectl describe pod查看Events字段是最直接的排查路径。典型问题及解决方案：

1. Pending + Insufficient cpu/memory：集群资源不足，需扩容节点或调整Pod资源请求
2. Pending + node(s) didn’t match node selector：亲和性约束过严，检查节点标签是否正确
3. Pending + didn’t match pod anti-affinity rules：反亲和性导致所有拓扑域都不可用，检查maxSkew和replicas的比例关系
4. ImagePullBackOff：非调度问题，镜像拉取失败，检查镜像地址和网络策略

调度问题的根因往往是约束冲突——多重亲和性规则互相矛盾时，调度器找不到满足所有条件的节点。设计调度策略时应从单一维度逐步添加约束，每加一条规则都验证可调度性，避免过度约束导致Pod无法运行。