从 Borg 到云原生基石：Kubernetes（K8s）的发展历史与演变之路
引言
在当今的云计算与软件工程领域，Kubernetes（通常简称为 K8s）已经成为容器编排的事实标准。作为开源社区最活跃的项目之一，K8s 的成功并非偶然，而是基础设施架构经历数十年演进的必然产物。本文将系统地介绍 Kubernetes 的历史渊源、诞生背景、核心演进阶段以及它如何逐步确立其在云原生生态中的主导地位。
一、 背景与前传：容器技术的崛起与痛点
在理解 Kubernetes 的诞生之前，需要先了解其所解决的历史技术痛点。
1. 物理机到虚拟化，再到容器化
- 物理机时代：早期的应用直接部署在物理服务器上，面临资源利用率低、部署周期长、环境隔离性差等问题。
- 虚拟化时代（VMware / KVM）：虚拟机（VM）通过 hypervisor 实现了硬件资源的切分和隔离，提高了资源利用率，但由于每个 VM 都需要运行完整的操作系统，导致启动慢、资源开销大。
- 容器化时代（Docker 的崛起）：2013 年，Docker 正式开源。它利用 Linux 内核的
Namespaces和Cgroups技术，实现了轻量级的进程级隔离，并引入了“镜像（Image）”的概念，解决了“在我的机器上可以运行，在生产环境不行”的环境一致性问题。
2. 容器编排的“最后公里”
Docker 解决了单个容器的打包和运行问题。然而，当企业试图在生产环境中大规模部署数百甚至数千个容器时，面临了新的挑战：
- 如何跨多台机器调度容器？
- 如何实现容器的自动扩缩容？
- 容器挂掉后如何自动恢复（自愈）？
- 容器之间如何进行服务发现与负载均衡？
这些问题属于容器编排（Container Orchestration）的范畴。正是在这种背景下，业界开始探索容器编排解决方案。
二、 谷歌的秘密武器：Borg 与 Omega
Kubernetes 并非凭空诞生，其底层设计思想和技术基因源自谷歌内部运行了十余年的大规模集群管理系统——Borg 和 Omega。
+-------------------------------------------------+
| Google Borg (2003~) | <-- 谷歌第一代内部集群管理系统 (C++)
+-------------------------------------------------+
|
v
+-------------------------------------------------+
| Google Omega (2011~) | <-- 共享状态、乐观锁架构研究项目
+-------------------------------------------------+
|
v
+-------------------------------------------------+
| Kubernetes (2014~) | <-- 汲取 Borg/Omega 经验的开源 Go 语言实现
+-------------------------------------------------+
1. Borg：谷歌的大脑
自 2000 年代初起，谷歌内部几乎所有的服务（包括搜索、Gmail、YouTube 等）都运行在名为 Borg 的集群管理系统上。Borg 负责管理成千上万个作业，运行在数万台机器上。
- 贡献的概念：Borg 引入了许多今天 K8s 用户熟悉的概念。例如，Borg 中的 “Alloc” 对应 K8s 的 “Pod”，Borg 中的 “Job” 对应 K8s 的 “Deployment” 或 “Job”。
- 局限性：Borg 是用 C++ 编写的，与谷歌内部的特定基础设施（如其独有的网络和存储系统）深度绑定，无法直接开源或在通用环境中推广。
2. Omega：共享状态的探索
为了解决 Borg 在扩展性和灵活性上的限制，谷歌在 2011 年左右启动了 Omega 项目。Omega 引入了“共享状态（Shared State）”架构，使用乐观并发控制（OCC）来提高调度器的吞吐量。Omega 的研究成果直接启发了后来 Kubernetes API Server 的声明式设计和存储机制。
三、 Kubernetes 的诞生（2014年）
随着 AWS 在公有云市场的崛起，谷歌意识到需要改变竞争维度。2014 年，谷歌决定将 Borg/Omega 的设计经验转化为一个开源项目，以此来推动容器化标准并促进 Google Cloud Platform (GCP) 的发展。
1. 关键奠基人与 Project 7
2014 年中，谷歌工程师 Joe Beda、Brendan Burns 和 Craig McLuckie 共同发起了这个项目。
- 代号“Project 7”：该项目最初的代号是“Project 7”，致敬了《星际迷航》中的角色“Seven of Nine”（九之七）。这也是为什么 Kubernetes 的 Logo 是一个七角舵轮的原因。
- 重新编写：设计团队决定放弃 C++，改用当时新兴的 Go 语言 从零开始编写该系统。Go 语言的并发特性和编译成单个二进制文件的便利性，使其成为编写系统级中间件的理想选择。
2. 命名与开源
项目最终被命名为 Kubernetes，该词源于希腊语（κυβερνήτης），意为“舵手”或“飞行员”。为了便于书写，社区将其简称为 K8s（用数字“8”代替字母“u-b-e-r-n-e-t-e-”中的 8 个字符）。
2014 年 6 月，在旧金山举行的 DockerCon 上，谷歌正式向外界宣布了 Kubernetes 项目。
四、 社区化与“容器战争”（2015-2018年）
Kubernetes 发布之初，容器编排领域并非一枝独秀。当时市场上存在着激烈的“三国杀”竞争：
- Docker Swarm：Docker 公司推出的原生编排工具。优点是与 Docker 引擎无缝集成，使用简单，学习曲线平缓。
- Apache Mesos / Marathon：在大型数据中心拥有深厚积累，适合大规模混合任务（如 Spark、Hadoop 与容器混合运行）调度。
- Kubernetes：谷歌背景，架构设计先进，但早期安装和使用门槛较高。
1. CNCF 的成立（2015年）
为了消除企业对 Kubernetes 被谷歌一家公司垄断的担忧，2015 年 7 月，谷歌联合 Linux 基金会成立了云原生计算基金会（CNCF, Cloud Native Computing Foundation）。谷歌将 Kubernetes v1.0 作为初始项目捐赠给了 CNCF。
这一举措确立了 K8s 的中立地位，吸引了包括 Red Hat、Microsoft、IBM、AWS、华为、阿里巴巴等行业巨头的加入，形成了庞大的开发者生态。
2. 胜出原因分析
到 2017 年底，Kubernetes 基本赢得了这场“容器战争”。其胜出的核心原因在于：
- 声明式 API 与自愈能力：与 Docker Swarm 的命令式（Imperative）操作不同，K8s 采用声明式（Declarative）API。用户只需定义“期望状态”，系统自动调整以达到并维持该状态。
- 开放的设计理念（插件化架构）：K8s 没有试图自己解决所有问题，而是定义了清晰的接口标准，允许生态伙伴接入自己的实现：
- CRI (Container Runtime Interface)：容器运行时接口，使得 K8s 不仅能运行 Docker，还能运行 containerd、CRI-O 等。
- CNI (Container Network Interface)：容器网络接口，兼容 Calico、Flannel 等多种网络方案。
- CSI (Container Storage Interface)：容器存储接口，支持各类云厂商和私有存储。
- 社区的力量：CNCF 规范的运作确保了项目的开放性，避免了单一商业实体的利益冲突。
2017 年 10 月，Docker 公司宣布在其企业版中内置对 Kubernetes 的支持；2018 年，Mesosphere（Mesos 母公司）也宣布全面支持 K8s。至此，编排之争尘埃落定。
五、 演变之路：关键技术演进阶段
Kubernetes 的架构和功能演进可以大致分为三个主要阶段：
+------------------------------------------------------------+
| 第一阶段：奠定基石 (v1.0 - v1.5) |
| - 确立 Pod, Service, ReplicaSet, Deployment 核心概念 |
+------------------------------------------------------------+
|
v
+------------------------------------------------------------+
| 第二阶段：解耦与标准化 (v1.6 - v1.12) |
| - 引入 CRI, CNI, CSI 接口标准 |
| - 推出 CRD & Operator 模式，实现高度可扩展性 |
+------------------------------------------------------------+
|
v
+------------------------------------------------------------+
| 第三阶段：生态成熟与生产落地 (v1.13 - 至今) |
| - 移除旧组件 (如 dockershim)，优化边缘、AI、多集群支持 |
+------------------------------------------------------------+
1. 第一阶段：奠定基础（2015 - 2016年）
这一阶段主要充实和稳定核心控制平面。
- 核心概念确立：确立了 Pod 作为最小调度单位，并引入了 Replication Controller（后演进为 ReplicaSet）、Service、Volume 和 Namespace 等核心资源。
- Deployment 的引入：在 v1.2 中引入了 Deployment 资源，极大地简化了无状态应用的声明式升级和回滚。
2. 第二阶段：解耦与标准化（2017 - 2019年）
为了支撑庞大的生态，K8s 开始精简其核心代码（“Out-of-Tree”计划），将非核心逻辑（如特定的云厂商驱动）移出核心仓库。
- 三大接口的标准化：CRI、CNI 和 CSI 的相继成熟，使得 K8s 成为一个高度可插拔的框架。
- CRD 与 Operator 模式：Custom Resource Definitions (CRD) 的引入允许用户像定义内置资源一样定义自己的资源，配合 CoreOS 提出的 Operator 模式，K8s 具备了管理复杂有状态服务（如数据库、消息队列）的能力。
3. 第三阶段：生态成熟与生产规模化（2020年至今）
在这一阶段，K8s 更加注重安全、稳定性和特定领域的扩展。
- 废弃 Dockershim：在 v1.20 版本中宣布、并在 v1.24 中正式移除了对 Docker 引擎的直接维护（Dockershim），转向更轻量、符合 OCI 标准的 containerd 或 CRI-O。
- 边缘计算与轻量化：出现了 K3s 等轻量化发行版，使得 K8s 能够运行在资源受限的边缘设备上。
- 多集群与混合云：随着企业业务规模扩大，多集群管理（如 Cluster API、Karmada）成为研究和应用热点。
六、 总结与未来展望
Kubernetes 从 2014 年谷歌内部的一个开源尝试，演变为今天全球云计算的“分布式操作系统”。它的成功不仅在于谷歌十余年的技术沉淀，更在于其声明式的设计理念、高度可扩展的插件化架构，以及开放、中立的社区治理模式。
当前，Kubernetes 正在与新兴的技术领域进行更深度的融合：
- AI 与机器学习：通过 Kubeflow 等项目，K8s 正在成为管理 GPU 算力资源和 AI 模型训练管线的主流基础设施。
- 无服务器架构（Serverless）：如 Knative 与 K8s 的结合，进一步降低了开发者对底层基础设施的感知。
作为云原生技术栈的基石，Kubernetes 的演进历程展示了软件工程在面对大规模分布式系统时的思考与实践，其倡导的“声明式”与“控制循环”思想，将持续影响未来软件架构的设计方向。
浙公网安备 33010602011771号