Kubernetes GPU 平台¶

Kubernetes 通过 Device Plugin 框架让 kubelet 发现并向 API Server 上报 GPU 等扩展资源。厂商插件通常以 DaemonSet 运行，并把 NVIDIA GPU 暴露为 nvidia.com/gpu。

设备可用链路¶

flowchart LR
    D[Node Driver] --> R[Container Runtime]
    D --> P[Device Plugin]
    P --> K[Kubelet]
    K --> A[API Server<br/>node capacity]
    S[Scheduler] --> A
    S --> Pod[GPU Pod]
    R --> Pod

任一环节不匹配，都可能出现“节点有卡但 Pod 用不了”：驱动/内核模块、容器 runtime、device plugin 注册、资源上报、scheduler 决策与容器注入要逐层验证。

最小 GPU Pod¶

apiVersion: v1
kind: Pod
metadata:
  name: gpu-smoke-test
spec:
  restartPolicy: Never
  containers:
    - name: cuda
      image: nvidia/cuda:12.6.3-base-ubuntu24.04
      command: ["bash", "-lc", "nvidia-smi && sleep 10"]
      resources:
        limits:
          nvidia.com/gpu: 1

Kubernetes 官方文档说明，GPU 扩展资源应写在 limits；可以只写 limits，此时其值同时用作 request。若同时写 request 与 limit，两者必须相等。扩展设备资源为整数且默认不可超卖。

调度不仅是“还有几张卡”¶

生产平台常需要表达：

• GPU 型号、显存容量、互连域、MIG profile；
• GPU 与 NIC/NUMA 的拓扑关系；
• 作业必须同时获得 N 张卡/多个 Pod 的 gang 语义；
• 队列、租户配额、公平性、优先级和抢占；
• 训练长作业与在线推理的隔离；
• 节点健康、维护、drain 与故障恢复。

Node Feature Discovery 可发现并标记硬件特征。标签表示能力，taint/toleration 控制哪些 workload 可以进入，node affinity 表达工作负载需求；不要让用户随意伪造受信任的硬件标签。

GPU 共享方式要区分¶

“可共享”不等于“适合多租户生产”。要根据安全、显存隔离、SLO 和故障域选择。

训练与服务的控制器¶

• 原生 Job 适合简单 batch；分布式训练通常还需要 gang scheduling、角色编排和容错控制器。
• 模型服务可从 Deployment + Service 起步；需要模型 CRD、revision、canary、autoscaling 与多框架数据面时再引入 KServe 等平台层。
• KServe 的 InferenceService 封装了模型服务生命周期、网络、健康检查、流量与扩缩；高级 LLM 场景还需评估队列、token 指标、prefix-aware routing 和多节点推理。

自动扩缩的现实约束¶

LLM 副本扩容包括节点供给、Pod 调度、镜像拉取、模型下载、权重加载、编译/warmup。总时间可能远大于普通 Web 服务。

因此：

• 以 queue time、running/waiting sequences、token rate 等负载信号补充 CPU/GPU utilization；
• 设置合理 min replicas 和预测性余量；
• 使用节点/镜像/模型缓存缩短冷启动；
• scale-down 要有稳定窗口，避免抖动和缓存反复丢失；
• 扩容策略必须通过突发流量演练验证。

节点上线与下线¶

节点上线前验证：驱动、GPU 健康、ECC/Xid、NVLink、NIC、存储、时间同步、device plugin 和基准性能。下线前先 cordon，迁移/结束 workload，再做 drain；训练作业要确认 checkpoint，推理要确认副本与 SLO 余量。

延伸阅读¶

• Kubernetes：Schedule GPUs
• Kubernetes Device Plugins
• KServe Administrator Guide