Kubernetes GPU编排：管理数千GPU集群

更新于2025年12月8日

2025年12月更新： Kubernetes 1.31+ 动态资源分配(DRA)现已正式发布，支持细粒度GPU分区和时间切片。NVIDIA GPU Operator 24.6+ 增加Blackwell支持和改进的MIG管理。Kueue（Kubernetes原生作业队列）在AI工作负载方面达到生产成熟度。Run:ai和CoreWeave在Kubernetes上展示50,000+ GPU集群。多集群联邦工具（Liqo、Admiralty）支持跨云GPU编排。vGPU支持改善多租户推理部署。

OpenAI在多个Kubernetes集群中编排25,000个GPU来训练GPT模型，使用自定义算子自动处理GPU故障、实时重新平衡工作负载，在平均每2.5小时发生硬件故障的情况下仍保持97%利用率。¹ 该公司的基础设施团队发现，原生Kubernetes在没有大量修改的情况下在大约5,000个节点时会崩溃，迫使他们实施分层集群联邦、自定义调度算法和GPU感知自动扩缩容，将每个价值30,000美元的H100视为需要单独跟踪的珍贵资源。大规模管理GPU与CPU编排根本不同——分布式训练期间的GPU故障可能浪费数百万计算时间，而分离通过NVLink连接的GPU的糟糕调度会导致8倍性能下降。成功在Kubernetes上编排数千GPU的组织报告，与裸机管理相比，利用率提高35%、部署时间快60%、运营开销减少90%。²

Kubernetes以88%的市场份额主导容器编排，但GPU支持起步较晚且在规模化方面仍具挑战性。³ NVIDIA GPU Operator于2019年推出，最终为Kubernetes带来企业级GPU管理，支持动态驱动安装、自动设备插件部署和GPU健康监控等功能。在Kubernetes上运行AI工作负载的组织必须应对设备插件配置、节点亲和性规则、拓扑感知调度以及防止单个团队垄断GPU资源的资源配额。然而，掌握Kubernetes GPU编排的组织能够将数千个GPU视为单一可编程资源池，实现传统HPC调度器无法达到的利用率和运营效率。

GPU设备插件架构

Kubernetes设备插件框架支持跨集群的GPU发现、分配和健康监控：

NVIDIA GPU设备插件作为Kubernetes与NVIDIA GPU之间的主要接口。⁴ 插件在每个GPU节点上作为DaemonSet运行，将GPU注册为kubelet的可调度资源。初始化期间，插件查询NVIDIA管理库(NVML)以发现可用GPU、其内存容量、计算能力和互连拓扑。插件使用nvidia.com/gpu资源名称向Kubernetes调度器发布GPU，使pod能够通过标准资源规范请求GPU。

设备插件注册流程： 1. 插件启动并通过NVML发现本地GPU 2. 通过/var/lib/kubelet/device-plugins/的Unix套接字向kubelet注册 3. 使用唯一设备ID发布可用GPU 4. 实现Allocate() RPC用于容器GPU分配 5. 监控GPU健康状况并向kubelet报告故障 6. 在pod终止期间处理GPU清理

多实例GPU(MIG)支持支持将A100和H100 GPU分区为隔离实例。⁵ 每个MIG实例在Kubernetes中显示为单独的GPU，允许细粒度资源分配。设备插件管理MIG配置文件，处理实例的创建、删除和分配。组织通过为较小工作负载分区未充分利用的GPU实现7倍更好的GPU利用率。MIG配置需要仔细规划，因为分区模式无法在不排空节点的情况下更改。

替代设备插件提供供应商多样性： - AMD设备插件支持启用ROCm的GPU如MI250X - Intel设备插件管理Intel GPU和Gaudi加速器 - Xilinx FPGA设备插件编排FPGA资源 - Google TPU设备插件用于GKE集群

GPU工作负载的调度策略

有效的GPU调度在保持性能的同时最大化利用率：

集群调度确保分布式训练作业同时接收所有请求的GPU。没有集群调度，部分资源分配会导致死锁——作业永远等待永远不可用的剩余GPU。像Volcano和Apache YuniKorn这样的Kubernetes调度器插件通过PodGroups实现集群调度。⁶ 作业指定最小GPU要求，调度器要么分配所有资源，要么将整个作业排队。集群调度将集群利用率降低10-15%，但防止训练作业饥饿。

拓扑感知调度基于硬件互连优化GPU放置。通过NVLink连接的GPU实现600GB/s带宽，而通过PCIe仅32GB/s。⁷ 调度器检查节点拓扑以将相关pod放置在具有快速互连的GPU上。NVIDIA GPU特性发现使用拓扑信息标记节点，支持亲和性规则。糟糕的拓扑决策对通信密集型工作负载造成3-8倍性能下降。拓扑感知在超过8个GPU的作业中变得关键。

装箱与分散：装箱将工作负载整合到更少的节点上，改善缓存局部性并减少网络流量。分散将工作分布到各节点以获得更好的容错性和热管理。最佳策略取决于工作负载特征——训练作业受益于装箱，而推理偏好分散。动态策略根据集群利用率和工作负载混合进行调整。

优先级和抢占：生产工作负载比开发作业获得更高优先级。当资源稀缺时，调度器抢占低优先级pod。仔细的优先级配置防止研究作业阻塞生产推理。抢占检查点确保训练进度不会丢失。优先级类别从系统关键(1000000)到开发(100)。

公平共享和配额：资源配额防止单个团队垄断GPU。分层配额支持组织范围限制和团队特定子配额。公平共享调度确保随时间的公平资源分配。消耗较少资源的用户为未来突发容量累积积分。像Kueue这样的队列系统提供具有复杂准入控制的作业队列。

扩展考虑

将Kubernetes扩展到数千GPU需要架构修改：

集群大小限制：单个Kubernetes集群在etcd性能下降前支持最多5,000个节点。⁸ 由于监视机制，API服务器负载随节点数量二次增长。控制器管理器协调循环在超过1,000个节点后变慢。网络策略在规模上变得笨拙。大多数组织将集群限制在500-1,000个GPU节点以获得运营稳定性。

多集群联邦：大型部署使用通过联邦管理的多个Kubernetes集群。Admiralty或Virtual Kubelet支持跨集群调度。像Flux或ArgoCD这样的GitOps工具在集群间同步配置。服务网格技术提供跨集群网络。联邦增加复杂性但支持超越单集群限制的水平扩展。

分层资源管理：分层组织集群，管理集群控制工作负载集群。管理集群运行控制平面组件和调度逻辑。工作负载集群托管GPU pod而无复杂控制器。分层设计减少故障爆炸半径。清晰的关注点分离简化故障排除。

AI工作负载的自定义资源定义(CRDs)： - TrainingJob：定义分布式训练规范 - InferenceService：管理模型服务部署 - GPUPool：表示逻辑GPU分组 - Checkpoint：处理训练状态持久化 - ModelVersion：跟踪模型迭代和血统

规模化性能优化： - 禁用未使用的准入webhook减少API延迟 - 实施pod拓扑分散约束以实现均匀分布 - 使用本地SSD存储容器镜像避免网络瓶颈 - 启用CPU管理器保证CPU分配 - 为大模型内存需求配置大页面

监控和可观测性

全面监控防止数百万美元的GPU空闲时间：

NVIDIA数据中心GPU管理器(DCGM)提供标准Kubernetes监控无法获得的GPU特定指标。⁹ DCGM导出100多个指标，包括SM利用率、内存带宽、温度、功耗和ECC错误。Prometheus集成支持长期指标存储和告警。Grafana仪表板可视化整个fleet的GPU性能。自定义告警在故障发生前检测未充分利用的GPU、热节流和硬件退化。

Kubernetes监控的关键GPU指标： - GPU利用率：活跃SM百分比(目标>90%) - 内存利用率：已分配与可用GPU内存 - 功耗：实际与TDP指示节流 - 温度：GPU和内存温度 - PCIe带宽：到/从GPU的数据传输速率 - NVLink流量：GPU间通信带宽 - 训练指标：损失曲线、梯度范数、学习率 - 推理指标：每秒请求数、P99延迟、批大小

分布式跟踪跟踪跨多个GPU和节点的请求。OpenTelemetry仪器捕获训练步骤时间、数据加载延迟和检查点持续时间。Jaeger或Tempo提供分布式跟踪存储和分析。跟踪与指标的关联识别性能瓶颈。端到端可见性将平均恢复时间减少70%。

日志聚合集中数千GPU pod的日志。Fluentd或Fluent Bit以最小开销收集容器日志。Elasticsearch存储具有自动索引和保留策略的日志。Kibana支持整个集群的日志搜索和分析。一致格式的结构化日志简化故障排除。对指示系统性问题的错误模式发出告警。

Introl在我们的全球覆盖区域部署和管理用于GPU编排的Kubernetes集群，具有扩展到10,000+ GPU部署的专业知识。¹⁰ 我们的平台工程团队已实施自定义算子和调度增强以实现最佳GPU利用率。

生产部署模式

Anthropic的训练集群架构： - 规模：8个Kubernetes集群中的4,000个GPU - 拓扑：具有中央调度器的分层联邦 - 存储：用于训练数据的分布式Lustre文件系统 - 网络：每节点200Gbps的RoCE v2架构 - 调度：具有拓扑感知的自定义集群调度器 - 监控：DCGM + Prometheus，15秒抓取间隔 - 结果：94% GPU利用率，训练时间减少50%

Uber的推理平台： - 工作负载：每日5亿次预测 - 基础设施：20个地区的2,000个T4 GPU - 编排：Kubernetes与Knative用于无服务器 - 自动扩缩容：基于流量模式的预测性扩缩容 - 负载均衡：具有最小延迟路由的Envoy代理 - 优化：模型缓存将冷启动减少到2秒 - 结果：与之前架构相比成本降低65%

Spotify的混合训练-推理： - GPU：3,000混合V100/A100/T4机队 - 调度：开发的时间切片共享 - 隔离：用于多租户安全的Kata容器 - 成本