📚 课程目录第3章 Pod亲和性与反亲和性

3. Pod亲和性与反亲和性：podAffinity与podAntiAffinity、拓扑键topologyKey、跨节点调度约束

Pod亲和性与反亲和性是Kubernetes调度系统中用于控制Pod之间相对位置关系的核心机制。与节点亲和性（nodeAffinity）不同，Pod亲和性关注的是“Pod与Pod之间的调度关系”，而非“Pod与节点标签的关系”。这一特性在微服务架构、缓存集群、数据密集型应用等场景中至关重要。

3.1 核心概念与调度语义

Pod亲和性（podAffinity）与反亲和性（podAntiAffinity）通过拓扑键（topologyKey）定义调度约束的作用范围，调度器根据目标Pod的标签选择器，在指定的拓扑域内决定新Pod的放置位置。

规则类型	调度语义	典型场景
podAffinity	新Pod倾向于/必须与满足标签条件的Pod调度到同一拓扑域	Web服务与缓存服务同节点部署，减少网络延迟
podAntiAffinity	新Pod倾向于/必须与满足标签条件的Pod调度到不同拓扑域	应用多副本分散在不同节点/可用区，提升高可用性

关键区别：亲和性将Pod“拉近”，反亲和性将Pod“推开”。两者都依赖topologyKey定义“拓扑域”的边界，例如节点（kubernetes.io/hostname）、可用区（topology.kubernetes.io/zone）或地域（topology.kubernetes.io/region）。

3.2 拓扑键（topologyKey）的作用机制

topologyKey是Pod亲和性/反亲和性规则中的必填字段，它决定了调度器在哪个层级上评估Pod的分布。调度器会检查所有满足标签选择器的Pod，然后根据topologyKey的值将节点分组，最后在分组内执行亲和或反亲和的匹配逻辑。

apiVersion: v1
kind: Pod
metadata:
  name: web-server
  labels:
    app: web
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - cache
        topologyKey: kubernetes.io/hostname
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - web
          topologyKey: topology.kubernetes.io/zone
  containers:
  - name: web
    image: nginx:1.25

  配置解读：
  podAffinity.requiredDuringSchedulingIgnoredDuringExecution：强制要求web-server与带有app=cache标签的Pod调度到同一节点（hostname级别）。
podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution：尽量让web-server与带有app=web标签的Pod分布在不同可用区（zone级别），权重为100。

3.3 调度约束的两种模式

与节点亲和性类似，Pod亲和性/反亲和性也支持两种执行模式：硬约束（required）和软约束（preferred）。两者的行为差异直接影响调度成功率与集群资源利用率。

模式	调度行为	失败处理	适用场景
requiredDuringScheduling	必须满足规则，否则Pod无法调度	Pod处于Pending状态，调度器持续重试	强依赖关系（如Sidecar与主容器同节点）
preferredDuringScheduling	尽量满足规则，不满足时仍可调度到其他节点	调度器降低该节点优先级，选择次优节点	性能优化（如缓存亲和但允许降级）

性能警告：requiredDuringSchedulingIgnoredDuringExecution类型的反亲和性（尤其是使用kubernetes.io/hostname作为topologyKey时）会显著增加调度器的计算开销。对于大规模集群（节点数>1000），建议优先使用preferred模式，或结合Pod拓扑分布约束（topologySpreadConstraints）替代。

3.4 跨节点调度约束与拓扑分布

Pod反亲和性天然支持跨节点调度约束：通过设置topologyKey为kubernetes.io/hostname，可以确保同一应用的多个副本不会调度到同一节点。但更精细的跨节点分布需要结合拓扑分布约束（topologySpreadConstraints）来实现。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 5
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: web
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: web
            topologyKey: topology.kubernetes.io/zone
      containers:
      - name: nginx
        image: nginx:1.25

  组合策略说明：
  topologySpreadConstraints：控制Pod在节点级别的均匀分布，maxSkew=1表示任意两个节点上的Pod数量差不超过1。
podAntiAffinity：在可用区级别强制反亲和，确保每个可用区最多只有一个Pod副本。
两者结合实现了“节点级均匀分布 + 可用区级互斥”的多层级调度约束。

3.5 Pod亲和性/反亲和性工作流程

下图展示了调度器在处理Pod亲和性与反亲和性规则时的核心决策流程，包括标签匹配、拓扑域分组、约束验证与节点打分。

3.6 实战案例：微服务亲和部署

在微服务架构中，将前端服务与后端API服务调度到同一节点可以显著降低网络延迟。同时，使用反亲和性确保后端服务的多个副本分布在不同的可用区，以保障高可用性。

apiVersion: v1
kind: Pod
metadata:
  name: frontend
  labels:
    app: frontend
    tier: web
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - backend-api
        topologyKey: kubernetes.io/hostname
  containers:
  - name: nginx
    image: nginx:1.25
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: backend-api
  template:
    metadata:
      labels:
        app: backend-api
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - backend-api
            topologyKey: topology.kubernetes.io/zone
      containers:
      - name: api
        image: myapp/api:1.0

部署效果：

frontend Pod会强制与任意一个backend-api Pod调度到同一节点，确保本地网络通信。
backend-api的3个副本强制分布在不同可用区，单个可用区故障不影响整体服务。
如果某个节点上已有backend-api Pod，新调度的frontend Pod会优先选择该节点。

3.7 常见陷阱与最佳实践

陷阱	问题描述	解决方案
调度死锁	多个Pod相互要求亲和，但集群中没有节点能同时满足所有约束	避免循环依赖；使用preferred模式替代required；设置合理的调度超时
topologyKey选择不当	使用`kubernetes.io/hostname`作为反亲和topologyKey导致大规模集群调度性能下降	优先使用zone或region级别的topologyKey；结合topologySpreadConstraints
标签选择器过于宽泛	labelSelector匹配到大量不相关的Pod，导致调度约束失效或过度约束	使用精确的标签组合；为不同应用层设计独立的标签体系
忽略IgnoredDuringExecution	运行时Pod标签变化不会触发重新调度，可能导致实际分布与约束不一致	使用Operator或控制器定期校验Pod分布；结合descheduler进行重平衡

性能优化建议：

对于大规模集群（节点数>500），避免在required模式中使用kubernetes.io/hostname作为反亲和topologyKey。
优先使用拓扑分布约束（topologySpreadConstraints）替代复杂的反亲和规则，其计算效率更高。
在preferred模式中合理设置weight值（1-100），避免权重过高导致调度器过度倾斜。

3.8 与节点亲和性的协同使用

Pod亲和性/反亲和性可以与节点亲和性（nodeAffinity）同时使用，形成多层次的调度策略。调度器会先通过节点亲和性过滤出符合条件的节点集，再在剩余节点上执行Pod亲和性/反亲和性匹配。

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: topology.kubernetes.io/zone
            operator: In
            values:
            - us-east-1a
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 50
        podAffinityTerm:
          labelSelector:
            matchLabels:
              app: database
          topologyKey: kubernetes.io/hostname

  协同效果：
  节点亲和性将Pod限制在us-east-1a可用区。
Pod反亲和性尽量让Pod与database应用分布在不同的节点上。
最终调度结果：Pod落在指定可用区，且与数据库Pod错开节点部署。

通过合理组合Pod亲和性、反亲和性与节点亲和性，运维人员可以构建出满足低延迟、高可用、资源均衡等多维度需求的调度策略，充分发挥Kubernetes集群的调度能力。