颠覆 IT 世界的 20 万行代码：Kubernetes 的前世今生（文末有彩蛋）

引言

如今，Kubernetes 已成为容器编排的标准，但它的架构并非凭空诞生，而是深受 Google 管理大规模基础设施经验的影响。 要理解 Kubernetes 的起源，就必须追溯其技术血统——源自 Google 的两个内部系统：Borg 和 Omega。 早在 Kubernetes 开源之前，它们就已解决了现实中的调度、可靠性与可扩展性难题。 本文将深入剖析这两个系统如何塑造了 Kubernetes 的核心设计理念、动机以及早期开发路径。 背景：谷歌的 Borg 与 Omega 系统

Borg

Kubernetes 并非横空出世，而是继承了 Google 内部集群管理器 Borg 和 Omega 的技术血脉。 Borg 是 Google 在 2003-2004 年间开发的首个大规模容器管理系统，作为 Google 数据中心的“中央大脑”，Borg 能够在大量机器上编排数十万个任务，实现高资源利用率，具有容错性和极强的可扩展性。 Borg 几乎承载了 Google 的所有核心服务（搜索、Gmail、YouTube 等）。截至 2016 年，Borg 仍是 Google 内部的主要容器管理平台。 尽管目前的使用细节未对外公开，但 Borg 的架构与运维经验为 Kubernetes 的设计奠定了基础。 然而，随着时间推移，Borg 的系统逐渐变得复杂臃肿，形成了一个由不同团队为满足各自需求而拼凑出的工具、配置语言和流程的混合体。 这种复杂性最终促使 Google 决定设计一个更加灵活的新一代系统，也就是后来的 Omega。Omega

2013 年，Google 推出了 Omega，一个作为 Borg“后代”的第二代集群管理系统。 Omega 保留了 Borg 的许多成熟理念，但以更具原则性、模块化的架构重构了整个系统。 与 Borg “全知全能”的单体式 Master 不同，Omega 采用了共享状态架构：集群状态被保存在一个中心化、事务一致的存储系统中（基于 Paxos ），所有组件（如调度器）通过乐观并发控制（Optimistic Concurrency Control，OCC）读取和写入。 这种解耦设计打破了 Borg 中那个“全知全能”的 master，将其拆分为多个平行的组件，使得多个调度器可以并行运行，并且支持可插拔的控制面模块。 本质上，Omega 将 Borg 那种严格的中心化控制，转变为一种更分布式的架构，从而提升了灵活性和系统可扩展性。 在后来的发展中，Omega 的许多创新（如多调度器架构、基于 API 的状态存储等）都深深影响了 Kubernetes 的设计。Kubernetes 设计中的 Borg 与 Omega 启示

任务分组调度

Kubernetes 的创造者大多来自 Borg 团队，他们在构建这一新系统时有意融入了 Borg 和 Omega 的经验教训，其中一个被完整继承的重要理念，是“任务分组调度”的思路。 在 Borg 中，一个作业（Job）可以包含多个任务，这些任务被统一调度进一个名为 “Alloc”（分配的简称）的容器中。用户在使用过程中，通常会将辅助守护进程 Daemons（sidecar）与主任务一同部署在同一个 Alloc 中。 这种模式表明：如果调度器能够将任务组视为一级调度单元，系统设计将更加简洁。 Google 曾在 Borg 的后期版本和 Omega 中尝试引入这个概念（当时称为 “Scheduling Units” 或 SUnits），但由于 Borg 系统已非常成熟，强行加入这种新机制相当困难。 Kubernetes 直接采纳了这一设计思想：Pod 由一个或多个始终同时调度的容器组成，成为 Kubernetes 中最基本的部署单位，相当于 Omega 中的 SUnit。 Pods 的设计天然支持 Sidecar 模式与紧密耦合的服务协作运行，并共享网络和存储资源——这是对 Borg 使用模式的直接吸收与演化。 另一个重要影响是是对丰富元数据和灵活 API的需求。 Borg 起初缺乏针对工作负载的通用标记（tag）机制。Borg Job 最初不支持任意键/值标签，用户只能在冗长的 Job名称中编码版本、环境等信息，再事后解析，既低效又易出错。 2013 年，Google 工程师提出将一级标签（key-value metadata）引入 Borg 和 Google Cloud Platform，以统一描述应用程序属性。 最终，这一机制在 Kubernetes 中得以原生实现——Kubernetes 一开始就包含了标签和标签选择器，允许用户标记 Pod 和其他资源对象，然后选择其中一组对资源进行调度、监控、负载均衡。 这些标签系统还借鉴了 Google 监控系统的经验：有意避免使用 “OR” 逻辑，以确保选择器之间不会产生重叠，简化服务发现与发布管理。 Kubernetes 还引加入了注释 （Annotations），是非结构化键/值元数据，用于为对象附加任何辅助信息。补充了 Borg 仅有的 notes 字段，从而实现更强的可扩展性。 这些元数据机制使 Kubernetes 的用户体验和可扩展性远远超出其前身。工作负载管理

Kubernetes 另一个显著演进的方向是工作负载管理。 在 Borg 中，所有类型的工作负载从长期运行的服务到批处理任务，再到系统守护进程都使用一种统一的抽象模型：Job（由多个任务组成的数组）。 Borg 的 Job 拥有大量配置参数，但在实际操作中仍需依赖外部辅助进程来实现某些特定行为。例如：

• 对于守护进程，需要确保每台机器只运行一个任务；
  
• 当集群中新增或移除节点时，需要处理任务的自动扩容或替换；
  
• Job 中的每个任务都有固定身份（index），类似于 Kubernetes 中 StatefulSet 提供的固定标识功能
  

Kubernetes 团队意识到，单一且僵化的抽象模型限制了系统的表达力和灵活性。因此，他们转而采用了多种控制器类型，根据不同工作负载的需求进行划分：

• 初始版本引入了 ReplicationController，用于支持可扩展的无状态应用；
  
• 后续又增加了适配不同场景的控制器，如：
  
  
  
  • DaemonSet：为每个节点部署守护进程；
    
  • StatefulSet：用于需要稳定身份的有状态应用；
    
  • Job：适用于一次性或批处理任务；
    
  
  

尽管这些控制器用途各异，但它们都遵循一个共同的设计模式：持续驱动实际集群状态向用户定义的期望状态靠拢。这种设计被称为 Reconciliation Loop（协调循环），也叫 Control Loop，灵感来源于 Borg 的自愈逻辑，但在 Kubernetes 中被做得更加模块化。 在 Borg 中，这种扩缩容与自愈操作都由集中式的 Borgmaster 在 Job 模型内完成；而在 Kubernetes 中，这些功能被拆分到多个控制器中，它们作为控制面的组件，通过监控状态变化、调用 API 进行操作（如扩容副本、重调度失败的 Pod）来不断接近期望状态。 这种异步控制器模式结合前面提到的标签选择器机制，让 Kubernetes 在无需构建一个庞大“超级抽象模型”的前提下，能够灵活支持多种类型的工作负载。 简而言之：

Borg 教会 Kubernetes 什么不该做：比如把所有工作负载都塞进一个类型 Kubernetes 的做法是：将 Pod、控制器、服务端点等设计为相互解耦的基础单元，让它们可以各自演进

控制平面设计

控制平面架构也是关键的设计演进点。 Borg 以 Borgmaster 为核心——这个 Master 掌控一切操作逻辑，所有集群状态都保存在它的内存中，组件之间耦合紧密，系统强大但也不易扩展；Omega 则放弃中心控制器，使用共享状态和并发访问，灵活但缺乏全局一致性保障。 Kubernetes 在 Borg 和 Omega 的两种架构风格之间找到了折中的方案。 Kubernetes 使用 ETCD 作为共享的持久存储，并通过监听机制来触发集群状态的响应更新。控制平面中的各个组件（如调度器、控制器）都根据监听状态变化采取行动。 与 Omega 不同的是，Kubernetes 并不会让组件直接访问数据库。所有组件都必须通过一个中心化的 API Server 来进行交互。这个 API Server 提供结构清晰的 RESTful API。 这样一来，Kubernetes 构建出了一个模块化、组件化的系统架构——调度器、控制器等都可以按需替换或扩展，而不会牺牲对全局一致性与集群语义的约束能力。 这种混合式架构，在实践中让 Kubernetes 具备了极高的可扩展性，这对于一个开源项目尤为关键，同时也避免了全分布式架构常见的脆弱性和混乱性。 此外，Kubernetes 的构建过程始终高度关注开发者在集群中运行应用的使用体验。 其最核心的设计目标是：让开发者可以更轻松地在集群中部署和管理复杂的分布式系统，既能充分利用容器带来的资源效率优势，又不必暴露给用户过多底层的复杂性。 相比 Borg 更偏运维人员的内向设计，Kubernetes 更能回应更广泛的 IT 社区真实需求——Google 希望借助 Kubernetes 来服务的不只是自己，而是整个开发者生态和企业用户群体。为何 Google 要开源多年经验？

到 2010 年代初，Google 已拥有近十年大规模容器化工作负载的经验，但这本是 Google 的“护城河”。转折点出现在 2013 年，Docker 横空出世，让 Linux 容器以简单易用的形式走向大众开发者。 Docker 能够在单机上快速运行容器，但 Google 工程师（如 Craig McLuckie、Joe Beda、Brendan Burns）一眼看出，未来真正的挑战，是在多机集群上编排容器。而这，正是 Google 内部 Borg/Omega 已经解决的事情。 他们意识到，开源一个配合 Docker 的集群管理器是必然趋势。 2013 年底，Google 内部一个小团队启动原型项目，目标是把 Borg 和 Omega 的优点与 Docker 容器结合起来，这就是 Kubernetes 的雏形。 内部代号为 Project Seven of Nine，灵感来自《星际迷航》中脱离 Borg 集体的角色——暗喻将 Borg 的理念“释放”到开源世界。 开源 Kubernetes 有两个战略目的：

• 向全世界分享 Google 在大规模容器编排方面的最佳实践，占据云原生生态的制高点；
  
• 帮助开发者解决随着容器使用激增而带来的新问题，提供一个能自动化跨机器部署容器应用的解决方案。
  

Kubernetes 初始版本为“最小可用编排器”，仅提供核心能力（如副本管理、服务发现、自愈机制、批处理调度等），但打下坚实基础后快速迭代，目标是简化容器部署流程，并推动基础设施“云原生化”。关键事件时间线（2013–2025）

2013

2013 年秋：Google 内部小团队启动新一代容器编排系统的开发（受 Borg/Omega 以及 Docker 启发），这就是后来命名为 Kubernetes 的项目，标志着其在 Google 的诞生。2014

2014 年 6 月 6 日：Kubernetes 项目首次开源，第一份代码提交到 GitHub。Google 与 Red Hat、Microsoft、IBM、Docker 等业界伙伴一起作为早期协作者共建社区。2014 年 6 月 10 日：Google 工程副总裁 Eric Brewer 在 DockerCon 上正式发布 Kubernetes，Google 同日发表博客，将其作为开源容器编排平台对外宣布（代号“Project Seven”）。2015

2015 年 7 月 21 日：Kubernetes v1.0 在 O’Reilly OSCON 大会上正式发布，成为首个稳定版本。Google 同时宣布将 Kubernetes 捐赠给新成立的云原生计算基金会（CNCF），由 Linux 基金会托管，标志着该项目迈入中立治理阶段。2016

2016 年 3 月 10 日：Kubernetes 正式成为 CNCF 的首个托管项目。Kubernetes 的治理结构从 Google 转向由多方共同参与的中立基金会。2016 年 4 月：Kubernetes 社区设立 SIG，推动在多个子领域（如 SIG-OpenStack）开展协作，扩展贡献者规模。2016 年 12 月：v1.5 发布，引入 CRI（容器运行时接口）Alpha 支持、Windows Server 节点支持（Alpha），API Server 初次引入 OpenAPI 规范，并使 StatefulSets 和 Pod 中断预算进入 Beta 阶段。2017

2017 年 4 月：v1.6 发布，新增基于角色的访问控制（RBAC），成为细粒度权限定义的标准机制，取代之前的属性权限系统。2017 年 6 月：v1.7 弃用旧的 ThirdPartyResource 扩展机制，改为使用自定义资源定义 （Custom Resource Definitions，简称 CRD）——Kubernetes API 的主扩展机制。2017 年 10 月：首次举行指导委员会（Steering Committee）选举，7 名成员来自多个组织，正式确立社区驱动治理模式。2017 年 12 月：v1.9 发布，核心 Workloads API（Deployment、ReplicaSet 等）晋升为 GA（通用可用），标志着核心调度模型稳定成熟。2018

2018 年 3 月 6 日：Kubernetes 成为 CNCF 首个毕业项目，标志着其社区治理与技术成熟度达标，贡献者基础扎实。2018 年 12 月：v1.13 发布，CSI（容器存储接口）达 GA（General Availabilit），支持集群外部卷插件；集群启动工具 kubeadm 晋升为 GA，CoreDNS 替代 kube-dns 成为默认 DNS 服务。2019

2019 年 3 月 25 日：v1.14 发布，正式支持 Windows Server 容器节点，Windows 与 Linux 工作负载可共存在集群中，节点管理能力齐备。2019 年 9 月：v1.16 发布，CRD 晋升为 GA，完全取代 ThirdPartyResources；同时清理多个废弃 API，对用户配置迁移是一场实战演练。2020

2020 年 8 月：v1.19 将支持的补丁升级周期从 9 个月延长到 1 年，以适应企业升级周期，特别是在疫情期间减轻运维压力。2020 年 12 月：v1.20 正式弃用 Docker，转而使用 CRI 接口支持 containerd、CRI-O 等运行时。该重大更改引发社区广泛讨论，明确 Kubernetes 与 Docker 引擎的解耦。2021

2021 年 4 月：Kubernetes 发布节奏从每年四次调整为三次，以减轻开发负担并提升版本质量。2021 年 7 月：v1.22 移除多个已废弃的 Beta API（如旧版 Ingress、RBAC），再次强化 API 生命周期管理。2021 年 12 月：v1.23 发布，IPv4/IPv6 双栈网络能力达到 GA，可原生支持双协议的 Pod 与服务，满足现代混合网络需求。2022

2022 年 5 月：v1.24 发布，彻底移除 Dockershim，不再直接支持 Docker Engine。默认关闭旧版 Beta API，继续推进 API 精简与稳定策略。2022 年 12 月：v1.26 更新批处理调度系统，增强 Job API，提升对 AI/ML 等大规模并行计算场景的支持，持续扩展容器平台边界。2023

2023 年 4 月 3 日：完成镜像仓库迁移，原 k8s.gcr.io 仓库冻结，全部镜像转移至 registry.k8s.io，由社区运营，解决成本与扩展问题。2023 年 11 月：Kubernetes 成为仅次于 Linux 内核的全球第二大开源项目，贡献者超过 88000 人，涉及 8000 多家公司，生态影响力空前。2024

2024 年 6 月 6 日：Kubernetes 首次提交 10 周年，社区回顾其从 Google 小团队起步，到发展为全球最大云原生生态的历程。2024 年 10 月 1 日：v1.31 发布，完成“去除内置云厂商插件”大迁移——约 150 万行云厂商相关代码被移出核心代码，改由 Cloud Controller Manager 插件接管，提升安全性与中立性。2025

2025 年 4 月 23 日：v1.33（代号 Octarine）发布，带来 60 多项增强，重点提升安全性、可扩展性与开发者体验。最关键更新是为 Pod 启用 Linux 用户命名空间（Beta 默认开启），实现容器默认“无根化”运行，增强安全隔离。这一能力历经多年筹备，标志 Kubernetes 安全体系进一步成熟。 

在之前的文章中我们对 K8s 1.33 的原地扩缩容功能进行了详细介绍：详解K8s 1.33原地扩缩容功能：原理、实践、局限与发展 - CloudPilotAI - 博客园

最后的思考

在早期（2013–2016）的发展阶段，Kubernetes 借鉴了 Google 十余年在 Borg 和 Omega 上的实战经验，将这些久经考验的设计思想，重新打磨为一个模块化、可扩展、开放可用的容器编排平台。 从 Pod 和控制器，到标签 API 和状态存储机制，几乎每一项核心设计都能追溯到 Borg 与 Omega 的技术遗产。 与此同时，Kubernetes 的架构师有意识地避开了 Borg 的一些设计陷阱，同时也保留并优化了它的优势（高效调度、自我修复、高资源利用等），并将这些能力以更加开发者友好的方式呈现出来。 Kubernetes 的开源成功并非偶然，背后有着非常清晰的动因：解决容器使用爆炸式增长所带来的新问题，并以一种任何公司或开发者都能受益的方式来实现，而不仅仅是为 Google 自己服务。 Google 在早期将 Kubernetes 捐赠给 CNCF，并推动社区共建，这一关键决策让 Kubernetes 不只是一个内部工具，而是成为了现代云计算基础设施的基石。 如今回顾 2013–2016 年的演进，从首次提交到 v1.0 的发布，再到广泛社区参与，这段历史是 Kubernetes 从 Google 原型成长为全球生态标准的真实缩影。 即便发展至今，Kubernetes 的核心理念仍植根于当年 Borg 和 Omega 所开创的技术传统，成为推动软件部署方式变革的原动力。彩蛋
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！