4. 节点亲和性语法详解：matchExpressions、matchFields 与 operator

节点亲和性（Node Affinity）是 Kubernetes 调度器将 Pod 绑定到特定节点池的核心机制。在滚动升级场景中，通过精确的亲和性规则，可以确保新 Pod 只调度到已升级的节点，从而控制流量迁移粒度。本节深入解析 matchExpressions、matchFields 以及六种 operator 的完整语法与实战用法。

4.1 节点亲和性规则结构

节点亲和性定义在 Pod 的 spec.affinity.nodeAffinity 字段下，包含两种规则类型：

两种规则内部都使用 matchExpressions 或 matchFields 定义选择条件。每个条件由 key、operator 和 values（部分 operator 不需要）组成。

4.2 matchExpressions：基于节点标签的选择

matchExpressions 是最常用的选择器，它根据节点的 标签（Label） 进行匹配。节点标签是键值对，例如 node-pool: upgraded、zone: us-east-1。

4.2.1 operator 详解

Kubernetes 为 matchExpressions 提供了六种 operator，覆盖了从精确匹配到存在性检查的完整需求：

4.2.2 实战代码示例

以下 YAML 展示了一个完整的节点亲和性配置，使用 matchExpressions 实现滚动升级中的流量控制：

apiVersion: v1
kind: Pod
metadata:
  name: app-v2
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: node-pool-version
            operator: In
            values:
            - "v2"
          - key: node-type
            operator: NotIn
            values:
            - "spot"
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 80
        preference:
          matchExpressions:
          - key: zone
            operator: In
            values:
            - "us-east-1a"
          - key: cpu-capacity
            operator: Gt
            values:
            - "8"
  containers:
  - name: app
    image: myapp:2.0

规则解读：

• 硬性规则： Pod 必须调度到 node-pool-version=v2 且 node-type 不是 spot 的节点。这确保了新版本 Pod 只进入已升级的节点池，并排除竞价实例。
• 软性偏好： 在满足硬性规则的基础上，优先选择 zone=us-east-1a 且 cpu-capacity 大于 8 的节点，权重为 80。

4.3 matchFields：基于节点字段的选择

matchFields 与 matchExpressions 语法完全相同，但匹配的是节点的 字段（Field） 而非标签。字段是节点对象的固定属性，例如 metadata.name、status.nodeInfo.architecture。

4.3.1 matchFields 示例

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchFields:
          - key: metadata.name
            operator: In
            values:
            - "node-01"
            - "node-02"

上述规则将 Pod 强制调度到名为 node-01 或 node-02 的节点。注意：matchFields 不支持 Gt 和 Lt，因为字段值通常不是数值。

4.4 节点亲和性选择流程 SVG

下图展示了调度器在处理节点亲和性时的完整决策流程，重点突出 matchExpressions 与 matchFields 的协同工作方式：

4.5 多表达式组合与逻辑规则

一个 nodeSelectorTerm 中可以包含多个 matchExpressions，它们之间是 AND 关系——所有表达式必须同时满足。如果需要 OR 关系，则定义多个 nodeSelectorTerms。

4.6 常见错误与避坑指南

• operator 与 values 不匹配： Exists 和 DoesNotExist 不能带 values，否则 API 校验失败；In 和 NotIn 必须至少提供一个 values。
• Gt/Lt 值类型错误： 确保 label value 是纯数字字符串（如 "10"），不能包含单位（如 "10Gi" 会解析失败）。
• matchFields 的 key 必须正确： 字段名必须使用 Kubernetes 内部表示，例如 metadata.name 而非 name。可以通过 kubectl get node <node-name> -o json 查看可用字段。
• 硬性规则过于严格导致 Pod 无法调度： 在滚动升级初期，如果只有少量节点满足条件，大量 Pod 会处于 Pending 状态。建议配合 preferred 规则或使用 PodDisruptionBudget 控制升级速率。

4.7 节点亲和性与节点选择器对比

Kubernetes 还提供了更简单的 nodeSelector 字段，但功能有限。下表帮助你在两者之间做出选择：