> **本文是「架构实战·第二季」第二十六篇**。前面我们看了 K8s 整体架构和 Operator 开发，本篇深入 K8s 的"大脑"——kube-scheduler，理解它的扩展机制和实战配置。

---

## 引子：GPU 节点调度的"玄学"问题

去年我们做 AI 训练平台，碰到一个诡异的问题：

> 调度器把两个训练 Pod 调度到同一台 GPU 节点，结果 OOM 互相争抢；调过 affinity 还是没用。

最后我们意识到：**K8s 默认调度器根本不知道什么是"GPU 显存"**——它只看到 Node 上的 `nvidia.com/gpu: 8` 这种 label，但不知道每个 Pod 申请了多少、剩多少。

要解决这个问题，必须扩展调度器。

这一篇就是讲：**怎么让 K8s 调度器知道业务的"特殊维度"**。

---

## 一、调度框架全景

### 1.1 K8s 1.31 的调度流程

```
Pod → 调度队列 → 调度周期 → 绑定周期
        ↓           ↓          ↓
     排序等待   PreFilter/   Reserve/
                Filter/      Permit/
                Score/       PreBind/
                Reserve/     Bind/
                Permit/      PostBind
                PreBind
```

### 1.2 八个扩展点

| 阶段 | 作用 | 失败/返回 | 典型插件 |
|------|------|---------|---------|
| **PreFilter** | 提前过滤/缓存计算 | 错误 → Pod 不可调度 | NodePorts, PodTopologySpread |
| **Filter** | 节点过滤 | false → 节点被淘汰 | NodeName, NodeAffinity, Taints |
| **PostFilter** | Filter 全失败后兜底 | - | DefaultPreemption |
| **PreScore** | 打分前预处理 | 错误 → 0 分 | InterPodAffinity |
| **Score** | 节点打分 | 0-100 | NodeResourcesFit, ImageLocality |
| **NormalizeScore** | 分数归一化 | - | - |
| **Reserve** | 资源预留 | 错误 → Reserve 失败 | VolumeBinding |
| **Permit** | 异步准入 | wait/deny/approve | - |
| **PreBind** | 绑定前 | 错误 → 不绑定 | VolumeBinding |
| **Bind** | 实际绑定 | 错误 → Reserve 释放 | （默认实现）|
| **PostBind** | 绑定后清理 | - | - |

**关键观察**：Filter 决定"能不能"，Score 决定"选哪个"，Bind 决定"实际落位"。

### 1.3 调度周期 vs 绑定周期

| 周期 | 包含 | 是否可抢占 |
|------|------|----------|
| **调度周期** | PreFilter → Score → Reserve | 否（Filter 不可逆）|
| **绑定周期** | Permit → PreBind → Bind → PostBind | 否 |
| **抢占周期** | PostFilter | 是（选低优先级 Pod 驱逐）|

**抢占**：高优先级 Pod 没节点时，调度器找"驱逐代价最小"的低优先级 Pod 杀掉，腾出位置。

---

## 二、节点选择基础配置

### 2.1 nodeName（直接指定）

```yaml
apiVersion: v1
kind: Pod
spec:
  nodeName: gpu-node-01   # 直接绑死
```

简单粗暴，但**毫无灵活性**——节点挂了 Pod 不漂移。

### 2.2 nodeSelector（最简单选择器）

```bash
# 给节点打标签
kubectl label nodes gpu-node-01 accelerator=nvidia-a100
```

```yaml
apiVersion: v1
kind: Pod
spec:
  nodeSelector:
    accelerator: nvidia-a100
```

只能匹配"全等"，能力有限。

### 2.3 nodeAffinity（节点亲和性）

```yaml
apiVersion: v1
kind: Pod
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:  # 硬约束
        nodeSelectorTerms:
        - matchExpressions:
          - key: accelerator
            operator: In
            values: [nvidia-a100, nvidia-h100]
          - key: topology.kubernetes.io/zone
            operator: NotIn
            values: [us-east-1c]  # 排除故障域
      preferredDuringSchedulingIgnoredDuringExecution:   # 软约束
      - weight: 80
        preference:
          matchExpressions:
          - key: kubernetes.io/eos
            operator: In
            values: [ssd]
```

**运算符**：

| Operator | 含义 |
|----------|------|
| In | 标签值在列表中 |
| NotIn | 不在列表中 |
| Exists | 标签存在（忽略值）|
| DoesNotExist | 标签不存在 |
| Gt / Lt | 大于/小于（仅数字）|

**required vs preferred**：
- `required`：不满足不调度；
- `preferred`：尽量满足，不满足也能跑。

### 2.4 podAffinity / podAntiAffinity（Pod 亲和性）

```yaml
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            app: redis-master
        topologyKey: kubernetes.io/hostname   # 同节点
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchLabels:
              app: web
          topologyKey: kubernetes.io/hostname  # 跨节点
```

**典型用法**：
- `podAffinity`：缓存和数据库同节点（减少网络）；
- `podAntiAffinity`：Web 多副本跨节点（高可用）。

### 2.5 Taints and Tolerations（污点和容忍）

```bash
# 给节点打污点
kubectl taint nodes gpu-node-01 nvidia.com/gpu=reserved:NoSchedule
```

- `NoSchedule`：不容忍就不调度；
- `PreferNoSchedule`：尽量不调度，但没资源时也会调；
- `NoExecute`：不容忍就驱逐。

```yaml
# Pod 加容忍
spec:
  tolerations:
  - key: nvidia.com/gpu
    operator: Equal
    value: reserved
    effect: NoSchedule
    tolerationSeconds: 300  # 容忍 5 分钟后再驱逐
```

**Toleration 运算符**：

| Operator | 含义 |
|----------|------|
| Equal | key=value（默认） |
| Exists | 只看 key 不看 value |

---

## 三、自定义调度插件开发

### 3.1 场景：按 GPU 显存调度

我们的需求：
- 每个 Pod 声明需要的显存（如 16GB）；
- 调度器看节点上"已分配显存"，选有空闲的；
- 节点上 GPU 1 卡被占满 1 卡的，应该不让再调度。

### 3.2 思路

| 维度 | 实现 |
|------|------|
| GPU 资源类型 | 自定义 Extended Resource `nvidia.com/gpu-memory` |
| Pod 申请 | `resources.requests.nvidia.com/gpu-memory: 16` |
| 节点信息 | Device Plugin 上报（参考 [GPU Operator](https://github.com/NVIDIA/gpu-operator)）|
| 调度逻辑 | 自定义 Filter + Score 插件 |

### 3.3 完整插件实现

```go
// 1. 插件定义
type GPUFit struct {
    handle framework.Handle
}

func (pl *GPUFit) Name() string { return "GPUFit" }

// 2. 调度框架注册
type GPUFitArgs struct {
    Enabled bool `json:"enabled,omitempty"`
}

func (pl *GPUFit) EventsToRegister() []framework.ClusterEventWithHint {
    return []framework.ClusterEventWithHint{
        // 监听 Pod 变更（已分配的资源会变）
        {EventType: framework.Pod, ActionType: framework.All, Name: "pod-changed"},
    }
}

func (pl *GPUFit) AddPod(ctx context.Context, pod *v1.Pod) { /* ... */ }
func (pl *GPUFit) RemovePod(ctx context.Context, pod *v1.Pod) { /* ... */ }
func (pl *GPUFit) UpdatePod(old, new *v1.Pod) { /* ... */ }

// 3. 实现 PreFilter（提前缓存 Pod 申请的 GPU）
func (pl *GPUFit) PreFilter(ctx context.Context, state *framework.CycleState, pod *v1.Pod) (*framework.PreFilterResult, *framework.Status) {
    mem := getRequestedGPUMemory(pod)  // 解析 resources.requests
    if mem == 0 {
        return nil, nil
    }
    state.Write(preFilterStateKey, &preFilterState{mem: mem})
    return nil, nil
}

func (pl *GPUFit) PreFilterExtensions() framework.PreFilterExtensions {
    return nil
}

// 4. 实现 Filter（看节点剩余显存够不够）
func (pl *GPUFit) Filter(ctx context.Context, state *framework.CycleState, pod *v1.Pod, node *framework.NodeInfo) *framework.Status {
    // 1. 读 Pod 申请的显存
    s := &preFilterState{}
    if err := state.Read(preFilterStateKey, s); err != nil {
        return nil
    }
    requested := s.mem
    
    // 2. 算节点已分配显存（其他 Pod 申请之和）
    allocated := int64(0)
    for _, p := range node.Pods {
        allocated += getRequestedGPUMemory(p.Pod)
    }
    
    // 3. 节点总显存（从 label 读）
    totalStr := node.Node().Labels["nvidia.com/gpu-memory.total"]
    total, _ := strconv.ParseInt(totalStr, 10, 64)
    
    // 4. 判断
    if allocated + requested > total {
        return framework.NewStatus(framework.Unschedulable, "GPU memory insufficient")
    }
    return nil
}

// 5. 实现 Score（显存剩余越多，分越高）
func (pl *GPUFit) Score(ctx context.Context, state *framework.CycleState, pod *v1.Pod, nodeName string) (int64, *framework.Status) {
    node, _ := pl.handle.SnapshotSharedLister().NodeInfos().Get(nodeName)
    
    total, _ := strconv.ParseInt(node.Node().Labels["nvidia.com/gpu-memory.total"], 10, 64)
    allocated := int64(0)
    for _, p := range node.Pods {
        allocated += getRequestedGPUMemory(p.Pod)
    }
    free := total - allocated
    
    return free, nil  // 剩余越多分越高
}

func (pl *GPUFit) ScoreExtensions() framework.ScoreExtensions {
    return nil
}
```

### 3.4 注册插件（K8s 1.26+）

```go
// main.go
func main() {
    cmd := app.NewSchedulerCommand(
        app.WithPlugin("GPUFit", func(_ context.Context, _ runtime.Object, h framework.Handle) (framework.Plugin, error) {
            return &GPUFit{handle: h}, nil
        }),
    )
    if err := cmd.Execute(); err != nil {
        os.Exit(1)
    }
}
```

### 3.5 部署自定义调度器

```yaml
# scheduler-config.yaml
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: gpu-scheduler
  plugins:
    filter:
      enabled:
      - name: GPUFit
    score:
      enabled:
      - name: GPUFit
        weight: 80
      disabled:
      - name: NodeResourcesFit
```

```bash
# 用自定义镜像跑
docker build -t my-scheduler:v1 .
kubectl apply -f scheduler-config.yaml
```

### 3.6 在 Pod 中使用

```yaml
apiVersion: v1
kind: Pod
spec:
  schedulerName: gpu-scheduler
  containers:
  - name: train
    image: train-job:v1
    resources:
      requests:
        nvidia.com/gpu: 1
        nvidia.com/gpu-memory: 16  # 自定义扩展资源
```

---

## 四、调度器的实战策略

### 4.1 多调度器并存

```yaml
# Pod 选择调度器
spec:
  schedulerName: gpu-scheduler  # 默认 default-scheduler
```

**典型场景**：
- `default-scheduler`：通用负载；
- `gpu-scheduler`：AI 训练；
- `batch-scheduler`：Spark/Flink 批任务。

### 4.2 抢占（Preemption）

```yaml
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: critical
value: 1000000
preemptionPolicy: PreemptLowerPriority  # 抢占低优先级
globalDefault: false
description: "Critical priority class"
```

```yaml
spec:
  priorityClassName: critical
```

### 4.3 调度器配置（K8s 1.31）

```yaml
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler
  percentageOfNodesToScore: 50      # 大集群只评 50% 节点
  pluginConfig:
  - name: NodeResourcesFit
    args:
      scoringStrategy:
        type: LeastAllocated
        resources:
        - name: cpu
          weight: 1
        - name: memory
          weight: 1
  - name: InterPodAffinity
    args:
      ignoredKeyPaths:
      - /spec/affinity
```

### 4.4 节点选择性能优化

大集群（5000+ 节点）调度慢的优化：

| 优化 | 说明 |
|------|------|
| `percentageOfNodesToScore: 30` | 只评 30% 节点就足够 |
| `NodeResourcesFit` 改 `LeastAllocated` | 选剩余最多 |
| 关闭不必要的 Score 插件 | 减少打分计算 |
| 缓存 NodeInfo | 避免重复 Get |

---

## 五、调度器 Profile 与多 Profile

### 5.1 多 Profile 场景

```yaml
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler
  plugins:
    filter:
      enabled:
      - name: PodAffinity
- schedulerName: latency-scheduler
  plugins:
    filter:
      enabled:
      - name: PodAffinity
      - name: NodeLabel
        weight: 100
  pluginConfig:
  - name: NodeLabel
    args:
      presentLabels:
      - latency-zone
```

```yaml
# 不同 Pod 选不同 profile
spec:
  schedulerName: latency-scheduler
```

### 5.2 调度器扩展 vs 自定义调度器

| 维度 | 扩展（Profile）| 独立调度器 |
|------|--------------|----------|
| 部署 | 共用 K8s | 自己部署 |
| 集群视图 | 共享 | 独立（可能不一致）|
| HA | 复用 K8s HA | 自己处理 |
| 适用 | 80% 场景 | 完全自定义逻辑 |

**建议**：优先用扩展，自己部署独立调度器维护成本太高。

---

## 六、调度器可观测

### 6.1 关键指标

```promql
scheduler_pending_pods{queue}                  # 等待调度的 Pod 数
scheduler_queue_incoming_pods_total            # 入队 Pod 数
scheduler_schedule_attempts_total{result}      # 调度尝试
scheduler_e2e_scheduling_duration_seconds      # 端到端延迟
scheduler_pod_scheduling_sli_duration_seconds  # SLI 延迟
scheduler_plugin_score_duration_seconds{plugin}  # 各插件延迟
```

### 6.2 调试工具

```bash
# 1. 看为什么没调度
kubectl describe pod my-pod
# 重点看 Events → Warning 段

# 2. 看调度器日志
kubectl logs -n kube-system kube-scheduler-master-0

# 3. 调度器 trace（开启 -v=4）
kube-scheduler --v=4

# 4. 调度画像（profiling）
kube-scheduler --profiling
# 访问 http://localhost:10259/debug/pprof
```

### 6.3 常见调度问题诊断

| 现象 | 原因 | 排查 |
|------|------|------|
| Pod Pending 一直不动 | 节点资源不够 / taint 阻止 | `kubectl describe pod` 看 Events |
| Pod 调度到错节点 | nodeSelector/Affinity 写错 | `kubectl get pod -o wide` 看实际节点 |
| 调度非常慢 | 大集群、插件多 | 看 metrics，启用 percentageOfNodesToScore |
| 高优先级 Pod 不抢占 | PreemptionPolicy 配置错 | 看 PriorityClass 设置 |

---

## 七、踩坑提示

### 坑 1：nodeSelector 太死板

**症状**：新加节点忘了打 label，Pod 全部 Pending。

**解决**：
- 用 `preferredDuringScheduling` 而不是 `requiredDuringScheduling`；
- 用 DaemonSet 给节点自动打 label；
- 用节点生命周期 Controller 同步 label。

### 坑 2：Taint 驱逐

**症状**：节点维护打 `NoExecute`，Pod 全部被驱逐。

**解决**：
- 维护用 `cordon` 而不是 taint；
- 重要 Pod 加 toleration；
- PDB（PodDisruptionBudget）限制同时驱逐数。

### 坑 3：Pod 反亲和导致调度失败

**症状**：`requiredDuringScheduling` + 反亲和 = 没节点可选。

**解决**：
- 用 `preferredDuringScheduling`（软约束）；
- 加大集群规模；
- 用 `topologyKey: kubernetes.io/zone`（区域级）而不是 `hostname`（节点级）。

### 坑 4：自定义调度器没生效

**症状**：Pod 写了 `schedulerName`，但还是被 default 调度。

**解决**：
- 确认自定义调度器 Pod 正常运行；
- `kubectl logs -n kube-system` 看调度器日志；
- 检查 scheduler-config 加载正确。

### 坑 5：Filter 写得过于严苛

**症状**：所有节点 Filter 失败，Pod 一直 Pending。

**解决**：
- Filter 必须能 `framework.NewStatus(framework.Unschedulable, ...)`；
- 错误信息要详细（"GPU memory insufficient" 而非 "unschedulable"）；
- 关键：Filter 失败不等于 Reconcile 失败，调度器会持续重试。

### 坑 6：忽略 Pod overhead

**症状**：节点内存剩余 1GB，但实际 Pod 申请 1.5GB，节点 OOM。

**解决**：
- K8s 1.28+ 支持 `resources.overhead`，调度时考虑 sandbox/runtime 开销；
- 给系统预留内存（`--system-reserved`、`--kube-reserved`）。

### 坑 7：忽略 topologyKey 限制

**症状**：`podAntiAffinity` 配了但没生效，Pod 全在同一节点。

**解决**：
- `topologyKey` 必须存在（`kubernetes.io/hostname`、`topology.kubernetes.io/zone`）；
- 自定义 topology key 需要节点预打 label。

---

## 八、本篇要点回顾

| 主题 | 关键点 |
|------|--------|
| 调度框架 | 8 扩展点（PreFilter/Filter/PreScore/Score/NormalizeScore/Reserve/Permit/PreBind/Bind/PostBind）|
| 节点选择 | nodeSelector < nodeAffinity < 自定义插件 |
| 亲和性 | 硬约束（required）vs 软约束（preferred）|
| 污点 | taints 阻止 + tolerations 容忍 |
| 自定义插件 | Filter（能不能）+ Score（选哪个）|
| 实战场景 | GPU 调度、批任务调度、延迟敏感调度 |
| 可观测 | metrics + pprof + 日志 |

**调度器扩展的三个核心原则**：

1. **优先用内置能力**——nodeAffinity、taints、PodAntiAffinity 覆盖 80% 场景；
2. **必须用扩展点，不要重写调度器**——独立调度器维护成本极高；
3. **Filter 信息要详细**——"GPU memory insufficient: node has 8GB, pod needs 16GB" 远比 "unschedulable" 有用。

---

## 九、下一篇预告

下一篇 【架构实战】**K8s网络深入：CNI、Service与Ingress实现原理**，我们深入 K8s 最复杂的子系统——网络：

- CNI 规范与主流实现（Calico / Cilium / Flannel）的架构差异；
- Service 三种模式（ClusterIP / NodePort / LoadBalancer）的实现原理；
- iptables / IPVS / eBPF 三种 kube-proxy 模式源码级对比；
- Ingress / Gateway API 的演进与生产实践。

网络是 K8s 的"血液"——懂了它，集群性能、Service Mesh、跨集群通信都通了。

---

> **作者**：架构实战 第二季
> **版本**：v1.0
> **最后更新**：2026-10
> **全文约 6500 字**

本文是「架构实战·第二季」第二十六篇。前面我们看了 K8s 整体架构和 Operator 开发，本篇深入 K8s 的"大脑"——kube-scheduler，理解它的扩展机制和实战配置。

【架构实战】K8s调度器扩展：自定义调度与节点亲和性

研发部经理

编程语言

本文深入解析K8s调度器kube-scheduler的扩展机制与实战配置，涵盖8个调度扩展点、节点亲和性/污点容忍等基础配置、自定义GPU显存调度插件开发全流程，并总结多调度器并存、性能优化、故障排查及踩坑经验，助你掌握K8s调度核心能力。

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

【架构实战】K8s调度器扩展：自定义调度与节点亲和性-腾讯云开发者社区-腾讯云

【架构实战】K8s调度器扩展：自定义调度与节点亲和性

【架构实战】K8s调度器扩展：自定义调度与节点亲和性

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐