2. Node亲和性：nodeSelector、nodeAffinity（required/preferred）配置与实战

Node亲和性是Kubernetes调度器将Pod绑定到特定节点的一组策略，属于调度约束的核心能力。与污点/容忍的“排斥-容忍”逻辑不同，亲和性采用“吸引-匹配”机制，主动引导Pod选择符合条件的节点。本章从最基础的nodeSelector入手，逐步深入到nodeAffinity的强制与偏好规则，并通过实战案例展示配置方法。

2.1 nodeSelector：最简单的节点选择器

nodeSelector是Kubernetes最早提供的节点选择机制，通过在Pod的spec中定义nodeSelector字段，要求节点必须包含指定的标签且值匹配。它只支持“与”逻辑（所有条件必须同时满足），不支持复杂表达式。

配置示例：

apiVersion: v1
kind: Pod
metadata:
  name: nginx-selector
spec:
  nodeSelector:
    disktype: ssd
    region: cn-east-1
  containers:
  - name: nginx
    image: nginx:1.25

上述Pod只会被调度到同时具有disktype=ssd和region=cn-east-1标签的节点上。如果集群中没有这样的节点，Pod将一直Pending。

2.2 nodeAffinity：增强型节点亲和性

nodeAffinity是nodeSelector的升级版，属于调度策略的进阶能力。它支持丰富的匹配操作符（In、NotIn、Exists、DoesNotExist、Gt、Lt），并分为两种类型：requiredDuringSchedulingIgnoredDuringExecution（硬亲和）和preferredDuringSchedulingIgnoredDuringExecution（软亲和）。

2.3 requiredDuringScheduling 实战配置

硬亲和适用于强依赖场景，例如GPU计算节点、特定硬件节点、合规区域节点。以下示例要求Pod必须调度到GPU节点且区域为cn-east：

apiVersion: v1
kind: Pod
metadata:
  name: gpu-inference
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: gpu-type
            operator: In
            values:
            - nvidia-a100
            - nvidia-h100
          - key: topology.kubernetes.io/zone
            operator: In
            values:
            - cn-east-1a
            - cn-east-1b
  containers:
  - name: inference
    image: inference:latest
    resources:
      limits:
        nvidia.com/gpu: 1

关键解析：

• nodeSelectorTerms：多个term之间是OR关系，满足任意一个term即可。
• matchExpressions：同一个term内的多个表达式是AND关系，必须全部满足。
• 操作符In：节点的标签值必须匹配values列表中的任意一个。
• 如果集群中没有同时满足gpu-type和zone条件的节点，Pod将无法调度。

2.4 preferredDuringScheduling 实战配置

软亲和适用于优化调度场景，例如优先将Pod调度到低延迟区域或高带宽节点，但不强制。调度器会为每个节点计算权重分数，分数越高越优先选择。

apiVersion: v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 5
  template:
    metadata:
      labels:
        app: web
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 80
            preference:
              matchExpressions:
              - key: network-tier
                operator: In
                values:
                - low-latency
          - weight: 20
            preference:
              matchExpressions:
              - key: disk-type
                operator: In
                values:
                - nvme-ssd
      containers:
      - name: web
        image: nginx:1.25

权重计算逻辑：

• 每个preference独立计算，满足条件则累加对应的weight值。
• 调度器将所有满足条件的preference权重相加，得到节点的总得分。
• 得分最高的节点被优先选中；如果多个节点得分相同，调度器按默认策略（如资源均衡）选择。
• 如果没有任何节点满足preference，Pod仍然可以调度到任意节点（权重为0）。

2.5 nodeSelector 与 nodeAffinity 对比

2.6 亲和性调度流程（SVG图）

下图展示了Kubernetes调度器在处理Node亲和性时的完整决策流程，从Pod创建到最终节点绑定：

2.7 实战：组合使用 nodeSelector 与 nodeAffinity

在实际生产环境中，nodeSelector和nodeAffinity可以同时使用，调度器会先检查nodeSelector（所有标签必须匹配），再检查nodeAffinity的required规则。以下是一个综合示例：

apiVersion: v1
kind: Pod
metadata:
  name: hybrid-affinity-pod
spec:
  # 第一层：nodeSelector 精确匹配
  nodeSelector:
    environment: production

  affinity:
    nodeAffinity:
      # 第二层：硬亲和 - 必须属于指定可用区
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: topology.kubernetes.io/zone
            operator: In
            values:
            - cn-east-1a
            - cn-east-1b

      # 第三层：软亲和 - 优先选择高内存节点
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 70
        preference:
          matchExpressions:
          - key: memory-size
            operator: In
            values:
            - large
            - xlarge
      - weight: 30
        preference:
          matchExpressions:
          - key: cpu-arch
            operator: In
            values:
            - amd64

  containers:
  - name: app
    image: app:latest

调度执行顺序：

1. 调度器首先过滤出所有environment=production的节点（nodeSelector）。
2. 从这些节点中，进一步筛选出zone为cn-east-1a或cn-east-1b的节点（required硬亲和）。
3. 对剩余节点，根据memory-size和cpu-arch的权重计算得分，选择最优节点（preferred软亲和）。

2.8 常见问题与避坑指南