Kubernetes 的出身：从 Borg 到 GPU 事实编排器
Kubernetes 原本为无状态微服务而生；它成为 GPU 编排器，不是因为设计初衷，而是因为它无处不在、可扩展，而推理时代的所有需求它都已经具备。
Kubernetes 之前的世界
在 Kubernetes 出现之前，部署分布式应用意味着两个痛苦选择之一：用手工部署脚本管理裸机服务器，或用 Chef、Puppet、Ansible 之类的工具管理虚拟机。扩容意味着手工开通新虚机；故障转移依赖自定义脚本；环境一致性是神话，生产环境“在我机器上是好的”问题就是日常。
2013 年，Solomon Hykes 在 PyCon 上做了五分钟的闪电演讲，改变了一切：他演示了一个即将发布的工具 Docker。Docker 用干净的 API 包装了底层命名空间与 cgroups 的复杂性，把 Linux 容器带入主流。突然之间，你可以把应用及其全部依赖打包成一个可移植、可复现的镜像。容器革命开始了。
但容器带来了新问题：现在你有几百个容器分布在几十台主机上，全都需要被启动、停止、扩缩、更新和健康检查。编排（orchestration）成了必需品。
诞生于 Google 的 Borg
Google 从 2003 年起就在内部以一套叫 Borg 的集群管理系统大规模运行容器化工作负载。Docker 时代到来时，Google 工程师 Joe Beda、Brendan Burns 和 Craig McLuckie 看到了把 Borg 的经验带进开源世界的机会。这个内部项目的代号是 Project 7，致敬《星际迷航》中脱离了 Borg 集合的角色“九之七”（Seven of Nine），Kubernetes 标志上的七根辐条正源于此。
| 时间 | 里程碑 | 发生了什么 |
|---|---|---|
| 2014 年 6 月 | 首次 GitHub 提交 | Google 在 DockerCon 上发布 Kubernetes，Eric Brewer 的主题演讲把 K8s 带给世界 |
| 2015 年 7 月 | K8s v1.0：生产就绪 | Kubernetes 1.0 发布。Google 联合 Linux 基金会成立 CNCF，K8s 作为首个种子项目捐出 |
| 2015–16 | CNCF 与生态成长 | Microsoft、Red Hat、IBM 加入；面向有状态应用的 StatefulSets；包管理器 Helm 诞生 |
| 2017 | K8s 1.8：RBAC + 设备插件 | 基于角色的访问控制 GA；关键：设备插件框架以 1.8 alpha 引入，GPU 从此可以暴露给 K8s |
| 2018 | K8s 1.10：设备插件稳定 | 设备插件框架进入 beta；CRI-O 运行时；CoreDNS 成为默认；GKE/EKS/AKS 上线 |
| 2019–20 | K8s 成为中坚 | 91% 的组织在运行容器；K8s 用于微服务、数据库、ML 工作负载、网络功能 |
| 2020–22 | AI 工作负载规模化 | GPT-3、BERT、Stable Diffusion 全部在 GPU 集群上训练；GPU Operator v1.0 发布 |
| 2022 | ChatGPT 改变一切 | GPU 需求爆炸，每个组织都需要 GPU 基础设施，而 Kubernetes 正是它们的运行方式 |
| 2024–26 | DRA 时代开启 | K8s 1.32（DRA beta）、1.34（DRA GA）；NVIDIA 向 CNCF 捐赠 DRA Driver 并成为白金会员 |
注意 2017 年这一行：设备插件框架（详见设备资源抽象）与 GPU 的结缘从 K8s 1.8 就开始了，此后近十年 GPU 接入 Kubernetes 的方式都围绕它展开，直到 DRA 登场。
为什么 Kubernetes 成了 GPU 编排器
下面这个关键洞察解释了为什么原本为无状态微服务构建的 Kubernetes，成了 GPU 工作负载的事实编排器：
- 无处不在： 到 2020 年，Kubernetes 已经运行在每个主要数据中心里。团队熟悉它、工具链存在、云厂商提供托管版本。另建一套 GPU 调度系统，意味着重建 Kubernetes 已有的一切：网络、RBAC、服务发现、存储集成。
- 可扩展性： K8s 生来为扩展而设计：自定义资源定义（CRD）、准入 Webhook、设备插件、Operator 模式。NVIDIA 无需 fork Kubernetes 就能接入 GPU 支持。
- AI 接理爆炸： 训练一个模型与大规模服务它有不同的需求。推理需要弹性伸缩、多租户、负载均衡、滚动更新，这些 Kubernetes 都已具备。在 Kubernetes 之外做推理，意味着把这一切重建一遍。
总结
Kubernetes 的胜利不是功能清单的胜利，而是生态位的选择：它在正确的时间（容器标准化）、以正确的架构（可扩展控制面）占据了编排层，使 GPU 支持可以被“插入”而非“重造”。理解这段历史，就能理解为什么后续章节中的设备插件、GPU Operator 与 DRA 都以“扩展 Kubernetes”而非“绕开 Kubernetes”的方式演化。