4. 调度器故障模式：节点资源不足、污点/容忍度不匹配、节点选择器冲突、亲和性规则失败

在 GitOps 工作流中，当应用通过 Argo CD 或 Flux 自动同步到 Kubernetes 集群时，调度器（kube-scheduler）负责将新创建的 Pod 分配到合适的节点。如果调度失败，回滚窗口内的自动修复机制将无法生效。本章深入分析四种最常见的调度器故障模式，帮助 SRE 在回滚窗口内快速定位根因。

4.1 故障模式总览

下表对比了四种调度故障的触发条件、典型现象与排查入口：

4.2 节点资源不足

资源不足是最常见的调度故障。调度器在预选阶段会检查每个节点的剩余资源是否满足 Pod 的 requests。如果所有节点都不满足，Pod 将一直处于 Pending 状态。

以下是一个典型的资源不足事件输出：

Events:
  Type     Reason            Age   From               Message
  ----     ------            ----  ----               -------
  Warning  FailedScheduling  12s   default-scheduler  0/3 nodes are available: 1 Insufficient cpu, 2 Insufficient memory.

在 GitOps 场景中，如果回滚窗口内自动触发回滚，但新版本 Pod 仍然因为资源不足无法调度，需要检查回滚目标版本的资源请求是否合理，或者集群是否需要扩容。

4.3 污点/容忍度不匹配

污点（Taint）用于标记节点不应调度某些 Pod，容忍度（Toleration）允许 Pod 忽略特定污点。如果 Pod 没有定义容忍度，调度器会跳过带有对应污点的节点。

常见的污点效果（Effect）有三种：

• NoSchedule：新 Pod 不会调度到该节点（已有 Pod 不受影响）。
• PreferNoSchedule：调度器尽量不将 Pod 调度到该节点（软限制）。
• NoExecute：新 Pod 不会调度，且已有 Pod 如果未容忍该污点会被驱逐。

以下是一个污点与容忍度匹配的 YAML 示例：

# 节点污点
apiVersion: v1
kind: Node
metadata:
  name: gpu-node-1
spec:
  taints:
  - key: "gpu"
    value: "true"
    effect: "NoSchedule"

# Pod 容忍度
apiVersion: v1
kind: Pod
metadata:
  name: gpu-pod
spec:
  tolerations:
  - key: "gpu"
    operator: "Equal"
    value: "true"
    effect: "NoSchedule"
  containers:
  - name: cuda-container
    image: nvidia/cuda:12.0

4.4 节点选择器冲突

nodeSelector 是最简单的节点选择机制，要求节点必须包含 Pod 指定的所有标签。如果集群中没有节点同时满足所有标签，调度将失败。

以下是一个节点选择器冲突的排查流程：

1. 检查 Pod 的 nodeSelector：kubectl get pod <pod> -o yaml | grep -A 5 nodeSelector
2. 列出所有节点的标签：kubectl get nodes --show-labels
3. 确认是否有节点同时包含所有必需的标签键值对。
4. 如果标签存在但值不匹配，检查是否有拼写错误或大小写问题。

在 GitOps 回滚场景中，如果回滚后的应用版本使用了不同的 nodeSelector，而目标节点标签已被清理或重命名，会导致调度失败。建议在 GitOps 仓库中为节点标签定义统一的标签策略（如 tier: frontend、disk: ssd），避免硬编码节点名称。

4.5 亲和性规则失败

亲和性规则比 nodeSelector 更灵活，支持更复杂的调度约束。故障通常发生在以下三种情况：

• 节点亲和性（nodeAffinity）：requiredDuringSchedulingIgnoredDuringExecution 规则无法匹配任何节点。
• Pod 间亲和性（podAffinity）：要求 Pod 与某些标签的 Pod 部署在同一节点/拓扑域，但目标 Pod 不存在或数量不足。
• Pod 间反亲和性（podAntiAffinity）：要求 Pod 不与某些标签的 Pod 部署在同一节点，但节点数量不足以分散。

以下是一个 Pod 间反亲和性导致调度失败的典型场景：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  template:
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - web-app
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: nginx
        image: nginx:1.25

如果集群只有 2 个节点，而副本数为 3，反亲和性要求每个节点最多运行 1 个 Pod，那么第 3 个 Pod 将永远无法调度。

4.6 调度故障排查流程图

以下 SVG 图展示了从 Pod Pending 事件到定位四种故障模式的排查路径：

4.7 故障模式对比与 GitOps 回滚策略

下表总结了四种故障模式在 GitOps 回滚窗口内的处理策略：