📚 课程目录第3章云原生AI算力平台架构

3. 云原生AI算力平台架构

云原生AI算力平台并不是把GPU服务器简单塞进Kubernetes集群，而是要让“GPU”成为一种可被声明、可被调度、可被隔离、可被观测的资源。理解这套架构，关键是沿着一条纵向链路看：用户提交AI工作负载，Kubernetes负责编排，容器运行时负责隔离，设备插件负责把GPU暴露给容器，GPU Operator负责把驱动与组件自动化，调度器扩展负责把GPU放到合适的节点上。每一层缺失或错位，都会表现为“Pod Pending”“CUDA不可用”“多卡通信异常”等典型故障。

一、从资源声明到容器可见：GPU如何进入Pod

在Kubernetes中，GPU默认不是内置资源，而是通过设备插件（Device Plugin）机制扩展出来的资源。设备插件以DaemonSet形式运行在每个GPU节点上，向kubelet注册资源名，例如nvidia.com/gpu，并上报节点上可用的GPU数量。用户只需在Pod的resources.limits中声明：

resources:
  limits:
    nvidia.com/gpu: 2

调度器看到该声明后，只会把Pod调度到剩余GPU数量足够的节点。Pod被绑定到节点后，kubelet调用设备插件的Allocate接口，插件返回该容器应使用的GPU设备ID、设备节点路径以及必要的环境变量。随后容器运行时（如containerd）在创建容器时，把这些设备节点挂载进容器，并注入NVIDIA_VISIBLE_DEVICES等变量。最终容器内执行nvidia-smi时，只能看到被分配的那几张卡，而不是整机所有GPU。

这里有一个容易被忽略的细节：设备插件只负责“暴露设备”，不负责安装驱动。如果节点上没有正确的NVIDIA驱动和容器运行时钩子，设备插件即使注册成功，容器内仍然无法调用CUDA。因此，驱动、容器运行时、设备插件三者必须版本匹配。

二、GPU Operator：把节点准备过程自动化

手动在每台GPU节点安装驱动、配置containerd、部署设备插件和监控组件，规模一大就难以维护。GPU Operator通过Operator模式，把节点上GPU相关组件的生命周期统一管理起来。它通常包含以下组件：

NVIDIA驱动容器：在节点上以容器方式安装或预编译驱动，避免手工登录节点。
Container Toolkit：配置容器运行时，使容器能够访问GPU设备。
Device Plugin：注册nvidia.com/gpu资源。
DCGM Exporter：采集GPU利用率、显存、温度、功耗等指标。
Node Feature Discovery：识别节点GPU型号、驱动版本等标签，供调度使用。

GPU Operator的价值在于“声明式节点准备”。管理员只需给节点打上标签，Operator便自动完成驱动安装、运行时配置和插件部署。实际运维中，应重点关注驱动版本与CUDA版本的兼容矩阵，以及Operator升级时是否会触发节点重启。

三、调度器扩展：GPU调度不只是数卡

原生Kubernetes调度器只按GPU数量做整数分配，但AI工作负载往往有更复杂的需求：

GPU型号与架构：A100、H100、V100不能混用在同一训练任务中。
拓扑感知：多卡训练希望GPU位于同一NVLink域或同一PCIe Switch下，减少通信开销。
MIG切分：A100/H100支持将一张物理GPU切分为多个MIG实例，调度粒度从“整卡”变为“实例”。
共享与隔离：推理场景可能希望多Pod共享一张GPU，需要时间片或MPS支持。
队列与优先级：训练任务和在线推理任务需要不同的抢占策略。

因此，生产平台通常引入调度器扩展，例如通过Scheduler Framework插件、Volcano、Kueue或自研调度器，实现Gang Scheduling（一组Pod要么全部调度成功，要么全部等待）、拓扑感知分配和队列配额。以Gang Scheduling为例，分布式训练需要多个Worker同时启动，如果只调度部分Pod，其余Pod会一直等待，造成资源死锁。调度器扩展通过“全部满足才绑定”的策略解决这一问题。

四、AI工作负载特征对架构的反向要求

AI工作负载与普通Web服务差异明显：训练任务通常长时间占用整卡，启动慢、检查点大；推理任务则要求低延迟、弹性伸缩和GPU共享。这些特征反向要求平台具备：GPU资源池化与配额管理、任务排队与抢占、故障自愈与断点续训、以及细粒度监控。只有把设备插件、GPU Operator和调度器扩展组合起来，才能让GPU从“物理设备”变成“可编排资源”。

五、关键配置与排障要点

在实际部署中，建议按以下顺序检查GPU资源链路是否贯通：

节点上执行nvidia-smi，确认驱动正常、GPU可见。
检查kubectl get nodes -o json中节点的nvidia.com/gpu容量是否等于物理卡数。
查看设备插件Pod日志，确认注册无报错。
提交一个最小测试Pod，在容器内执行nvidia-smi -L，确认只看到被分配的GPU。
若使用多卡训练，检查Pod是否被调度到同一NVLink域，必要时通过节点标签和亲和性约束。

设备插件注册的资源名可以自定义，但一旦确定，所有工作负载和调度策略都必须使用同一资源名，否则会出现“节点有卡但Pod无法申请”的情况。

GPU Operator升级驱动时可能触发节点重启或驱动重载，生产环境应先在灰度节点验证，并确认训练任务已保存检查点。

总结来看，Kubernetes提供编排框架，容器运行时提供隔离边界，设备插件打通设备可见性，GPU Operator负责节点自动化，调度器扩展解决AI任务的复杂放置需求。五者协同，才构成可生产、可治理的云原生AI算力平台。