📚 课程目录第4章 Pod调度核心

4. Pod 调度核心：Pod Spec 与调度字段、节点选择器 (nodeSelector)、节点亲和性 (nodeAffinity)

Pod 调度是 Kubernetes 集群资源分配与负载均衡的第一道关卡。调度器 (kube-scheduler) 依据 Pod Spec 中的调度约束字段，将 Pod 绑定到满足条件的 Node 上。理解 nodeSelector、nodeAffinity 以及 Pod Spec 中的关键调度字段，是构建高可用、高性能集群的基础。

4.1 Pod Spec 中的调度相关字段

Pod Spec 中与调度直接相关的字段主要分布在 spec 层级，下表列出了核心字段及其作用：

字段路径	类型	作用与说明
`spec.nodeName`	string	直接指定 Pod 运行的 Node 名称。跳过调度器，由 kubelet 直接创建。用于特殊场景（如 DaemonSet 管理、调试）。
`spec.nodeSelector`	map[string]string	最简单的节点选择约束。Pod 只能调度到包含所有指定标签的 Node 上。逻辑为 AND。
`spec.affinity.nodeAffinity`	NodeAffinity	节点亲和性，支持 requiredDuringSchedulingIgnoredDuringExecution（硬约束）和 preferredDuringSchedulingIgnoredDuringExecution（软约束）。
`spec.affinity.podAffinity`	PodAffinity	Pod 亲和性，将 Pod 调度到与某些 Pod 相同的拓扑域（如同一 Node、同一可用区）。
`spec.affinity.podAntiAffinity`	PodAntiAffinity	Pod 反亲和性，避免 Pod 调度到同一拓扑域，用于高可用分散部署。
`spec.topologySpreadConstraints`	[]TopologySpreadConstraint	拓扑分布约束，控制 Pod 在集群拓扑域（如 zone、hostname）中的均匀分布。
`spec.tolerations`	[]Toleration	容忍度，允许 Pod 调度到带有对应污点 (Taints) 的 Node 上。

关键认知： 调度器按优先级依次评估这些字段。先处理 nodeSelector 和 nodeAffinity 的硬约束，再计算软约束和拓扑分布，最后结合污点容忍度完成过滤与打分。

4.2 节点选择器 (nodeSelector) —— 简单直接的标签匹配

nodeSelector 是 Kubernetes 最早提供的节点选择机制。它通过 标签键值对精确匹配 来约束 Pod 的调度目标。

4.2.1 工作原理

调度器在过滤阶段检查每个 Node 是否包含 Pod 中 nodeSelector 定义的所有标签。
如果 Node 缺少任何一个标签，该 Node 被过滤掉。
多个标签之间是 AND 关系，必须全部满足。

4.2.2 使用示例

apiVersion: v1
kind: Pod
metadata:
  name: nginx-gpu
spec:
  nodeSelector:
    accelerator: nvidia-tesla-v100
    disktype: ssd
  containers:
  - name: nginx
    image: nginx:1.25

上述 Pod 只会被调度到同时具有 accelerator=nvidia-tesla-v100 和 disktype=ssd 标签的 Node 上。

4.2.3 局限性

仅支持精确匹配：无法表达“标签值属于某个集合”或“标签存在但值不限”等逻辑。
无软约束：要么调度成功，要么 Pod 一直处于 Pending 状态，无法设置优先级。
无表达式支持：不能使用 In、NotIn、Exists、DoesNotExist 等操作符。

风险提示： 在生产环境中，如果 Node 标签被误删除或变更，使用 nodeSelector 的 Pod 将无法调度，且不会自动迁移。建议配合 Node 标签变更审计 和 PodDisruptionBudget 使用。

4.3 节点亲和性 (nodeAffinity) —— 灵活强大的调度约束

nodeAffinity 是 nodeSelector 的升级版，提供了更丰富的匹配规则和软硬约束能力。它属于 spec.affinity 字段的一部分。

4.3.1 两种调度类型

类型	字段名	行为	典型场景
硬约束	`requiredDuringSchedulingIgnoredDuringExecution`	调度时必须满足，否则 Pod 无法调度（Pending）。运行时 Node 标签变更不影响已运行的 Pod。	强制将 Pod 调度到 GPU 节点、合规区域。
软约束	`preferredDuringSchedulingIgnoredDuringExecution`	调度时尽量满足，不满足时仍可调度到其他 Node。支持设置 `weight`（权重 1-100）。	优先调度到高性能节点，但允许降级到普通节点。

4.3.2 匹配表达式操作符

操作符	说明	示例
`In`	标签值在给定集合中	`values: ["ssd", "nvme"]`
`NotIn`	标签值不在给定集合中	`values: ["hdd"]`
`Exists`	标签存在（值不限）	无 values 字段
`DoesNotExist`	标签不存在	无 values 字段
`Gt`	标签值大于给定数值（字符串比较）	`values: ["64"]`
`Lt`	标签值小于给定数值	`values: ["128"]`

4.3.3 完整配置示例

apiVersion: v1
kind: Pod
metadata:
  name: app-frontend
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: topology.kubernetes.io/zone
            operator: In
            values:
            - us-east-1a
            - us-east-1b
          - key: node-type
            operator: Exists
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 80
        preference:
          matchExpressions:
          - key: cpu-model
            operator: In
            values:
            - "amd-epyc-7xx"
      - weight: 20
        preference:
          matchExpressions:
          - key: disktype
            operator: In
            values:
            - "nvme"
  containers:
  - name: nginx
    image: nginx:1.25

该 Pod 的调度逻辑：

硬约束：必须调度到 us-east-1a 或 us-east-1b 可用区，且 Node 必须存在 node-type 标签。
软约束：优先选择 cpu-model=amd-epyc-7xx 的 Node（权重 80），其次选择 disktype=nvme 的 Node（权重 20）。

4.4 nodeSelector vs nodeAffinity 对比

维度	nodeSelector	nodeAffinity
表达能力	仅精确匹配（AND）	支持 In/NotIn/Exists/DoesNotExist/Gt/Lt 操作符
约束类型	仅硬约束	硬约束 + 软约束（带权重）
多条件组合	多个标签之间 AND	支持 `nodeSelectorTerms` 之间 OR，`matchExpressions` 之间 AND
配置复杂度	低	中高
推荐场景	简单、固定的标签匹配	复杂调度策略、多维度约束、优先级调度

4.5 调度决策流程与风险控制

下图展示了调度器在处理 Pod 调度约束时的核心决策流程：

4.6 风险控制与最佳实践

  策略矩阵复核要点：
  标签一致性审计：确保 Node 标签与 Pod 调度约束字段保持同步，避免因标签缺失导致大面积 Pod Pending。
软约束权重平衡：多个 preferredDuringScheduling 项的权重差异不宜过大（建议最大权重差 < 50），防止调度器过度偏向某一特征。
硬约束兜底：关键业务 Pod 必须设置 requiredDuringScheduling 硬约束，防止调度到不满足合规或性能要求的 Node。
拓扑分布配合：将 nodeAffinity 与 topologySpreadConstraints 结合使用，避免 Pod 集中调度到同一可用区或同一 Node。
变更管理：Node 标签的增删改必须通过变更审批流程，并触发调度约束的重新验证。

常见故障模式：

标签漂移：Node 标签被误删除或修改，导致已有 Pod 不受影响，但新 Pod 无法调度。
软约束饥饿：高权重软约束条件过于严格，导致调度器反复尝试高权重 Node 而忽略低权重候选，影响调度效率。
硬约束冲突：多个 nodeSelectorTerms 之间是 OR 关系，但内部 matchExpressions 是 AND 关系，配置不当可能导致无 Node 满足条件。

4.7 本章小结

nodeSelector 适用于简单、固定的标签匹配场景，配置成本低；nodeAffinity 则提供了企业级调度所需的灵活性和表达能力。在实际生产环境中，建议以 nodeAffinity 为主，nodeSelector 为辅，并结合拓扑分布约束和污点容忍度构建完整的调度策略矩阵。定期复核调度约束与 Node 标签的一致性，是保障集群调度稳定性的核心风险控制手段。