揭秘 Kubernetes 技术起源！Borg 和 Omega 如何影响 Kubernetes 的核心设计？Pod、标签选择器、控制器等关键概念竟源于谷歌内部系统。从单体 Master 到 API Server，Kubernetes 架构演进之路。Docker 与 Kubernetes 的相遇，又碰撞出怎样的火花？一文读懂云原生编排王者 Kubernetes 的前世今生！
译自：From Google to Global: The Technical Origins of Kubernetes
作者：Abhimanyu Saharan
Kubernetes 已经成为容器编排的标准，但它的架构并非凭空产生。它大量借鉴了谷歌管理大规模基础设施的经验。要理解 Kubernetes 的起源，需要追溯其通过谷歌的两个内部系统 Borg 和 Omega 的发展历程，这两个系统在 Kubernetes 开源之前很久就解决了实际的调度、可靠性和可扩展性挑战。本文档深入探讨了这些系统如何影响 Kubernetes 的核心设计、动机和早期开发。
背景：谷歌的 Borg 和 Omega
Kubernetes 并非凭空出现，它的血统可以追溯到谷歌的内部集群管理器 Borg 和 Omega。Borg 是谷歌的第一个大规模容器管理系统，开发于 2003-2004 年左右。作为谷歌数据中心的集中式“大脑”，Borg 在许多机器上协调了数十万个作业，实现了高资源利用率、容错性和大规模可扩展性。Borg 的成功使其成为运行几乎所有谷歌服务（搜索、Gmail、YouTube 等）的支柱，并且它仍然是谷歌主要的内部容器管理系统。然而，随着时间的推移，Borg 的生态系统变得非常复杂，是由不同团队构建的异构的临时工具、配置语言和流程的集合，以满足各种需求。这种复杂性促使谷歌设计一个更灵活的继任者。
2013 年，谷歌推出了 Omega，这是作为 Borg 的“后代”构建的第二代集群管理器。Omega 保留了 Borg 的许多经过验证的想法，但使用更具原则性的模块化架构进行了重建。与 Borg 的单体主节点不同，Omega 使用共享状态方法：集群的状态保存在集中式的、事务一致的存储中（由 Paxos 支持），所有组件（调度器等）都可以使用乐观并发控制进行读/写。这种解耦的设计允许将 Borg 的全知主节点分解为单独的对等组件，从而实现多个并行调度器和可插拔的控制平面模块。本质上，Omega 用更分布式的方案取代了 Borg 严格的集中式控制，从而提高了工程灵活性和可扩展性。Omega 的许多创新（例如，多调度器架构和以 API 为中心的状态存储）后来影响了 Kubernetes 的设计。
Kubernetes 设计中来自 Borg 和 Omega 的经验教训
Kubernetes 的创建者是 Borg 团队的资深人士，他们明确地着手在构建新系统时应用来自 Borg 和 Omega 的经验教训。Kubernetes 中采用的一个基本概念是将任务分组为单元的想法。在 Borg 中，作业可以将多个任务调度到单个“Alloc”（资源分配）中，并且用户经常将辅助守护程序（sidecar）与主任务共同放置在同一 Alloc 中。这种模式表明，如果调度器将这样的组视为一等公民，则会更简单。谷歌在后期的 Borg 和 Omega 中试验了这个概念（称为“调度单元”或 SUnits），但很难将其改造到成熟的 Borg 系统中。Kubernetes 直接采用了这个想法**：Pod**，一个或多个始终一起调度的容器的小组，成为基本的部署单元，类似于 Omega SUnit。Pod 使得 sidecar 模式和紧密耦合的服务能够以共享的网络和存储一起运行，这是直接从 Borg 的使用模式中吸取的教训。
另一个关键影响是对丰富的元数据和灵活 API 的需求。Borg 缺乏通用的工作负载标记机制，Borg 任务最初不支持任意的键/值标签，迫使用户将环境或版本信息编码到冗长的任务名称中，并在以后解析它们。这很容易出错且相互孤立。2013 年，Google 工程师提议向 Borg 和 Google 的云平台添加一流的标签（键值元数据），以统一描述应用程序属性。在一个全新的项目中实现这一点比在 Borg 的代码库中容易得多。因此，Kubernetes 从一开始就包含了标签和标签选择器，允许用户标记 Pod 和其他对象，并在以后选择它们的分组以进行调度、放置、监控和负载平衡。Kubernetes 中的标签选择器是根据 Google 监控系统的经验设计的，它们特意排除了 OR（析取）逻辑，因此任何两个不同的标签查询都不会重叠，从而简化了可靠的服务发现和部署自动化。Kubernetes 还引入了注解（非结构化的键/值元数据）以将任何辅助信息附加到对象，这是对 Borg 的单个“notes”字段的回应，该字段被证明不足以进行扩展。这些元数据机制使 Kubernetes 比其前身更具可扩展性和工具友好性。
工作负载管理是另一个演变领域。Borg 使用一种称为“Job”（任务数组）的通用抽象来处理各种工作负载类型，从长时间运行的服务到批处理作业和系统守护程序。Borg Job 有许多参数，仍然需要外部辅助进程来实现某些行为（例如，确保每个机器一个守护程序任务，或在添加/删除机器时处理替换）。Borg Job 中的每个任务也都有一个固定的身份（索引），类似于 Kubernetes 中 StatefulSets 提供的功能。Kubernetes 团队认识到这种僵化的模型过于局限。相反，Kubernetes 采用了多种控制器类型：最初的版本具有用于可扩展的无状态工作负载的 ReplicationController，并且很快添加了其他控制器以用于不同的模式（例如，用于机器守护程序的 DaemonSets，用于稳定标识符的 StatefulSets，批处理 Jobs 等）。所有这些控制器都共享一个通用模式：它们不断地将实际集群状态驱动到用户定义的期望状态。这种协调循环设计（有时称为控制循环）受到 Borg 的自动化自我修复方法的影响，但 Kubernetes 使其更加模块化。在 Borg 中，中央 Borgmaster 处理 Job 抽象中的扩展和修复；在 Kubernetes 中，控制器是单独的控制平面代理，它们监视状态并通过 API 进行调整（例如，扩展副本，重新调度失败的 Pod）。这种异步控制器模式，结合使用标签选择器对资源进行分组，使 Kubernetes 具有更大的灵活性来支持各种工作负载类型，而无需构建一个巨大的超级抽象。简而言之，Borg 教会了不该做什么（重载一个对象类型），而 Kubernetes 则将 Pod、控制器和服务端点建模为可以独立发展的解耦原语。
或许最重要的架构经验是如何构建控制平面。Borg 的架构以单体 Master 节点 (Borgmaster) 为中心，它知道如何执行每个操作并在内存中管理所有集群状态，组件之间紧密耦合。相比之下，Omega 除了状态存储之外，没有单一的中央大脑；它的组件是共享数据的客户端，这最大限度地提高了灵活性，但也使得全局一致性成为管理并发更新的难题。Kubernetes 在这些方法之间取得了中间立场。与 Omega 类似，Kubernetes 使用共享持久存储 (etcd) 作为事实来源，并采用 watch/notify 机制，各种控制平面组件（调度器、控制器）充当对状态变化做出反应的独立观察者。但与 Omega 不同，Kubernetes 不直接暴露数据库；所有组件都通过一个中央 API 服务器进行交互，该服务器具有定义良好的 RESTful API。这个 API 服务器充当网关，对状态强制执行版本化的模式、验证和策略。结果是一个模块化、组件化的系统（可以添加或替换调度器和控制器），而不会牺牲在整个集群中强制执行全局不变性和一致语义的能力。在实践中，这种混合设计使 Kubernetes 具有高度的可扩展性（对于开源至关重要），同时避免了完全分布式协调的脆弱性。此外，Kubernetes 的构建非常注重在集群上运行应用程序的开发者体验。主要的设计目标是轻松地在集群上部署和管理复杂的分布式系统，利用容器效率而不会暴露过多的复杂性。相对于 Borg 面向内部的设计，这种对简单性和以开发者为中心的功能的强调，是对 Google 希望通过 Kubernetes 服务于更广泛的 IT 社区的需求的直接回应。
Kubernetes 的动机：为什么 Google 开源了十年的技术诀窍
到 2010 年代初，Google 在大规模容器化工作负载方面拥有近十年的经验，但这是内部的竞争优势。Kubernetes 的催化剂出现在 2013 年，当时 Docker 突然出现，并在 Google 之外普及了 Linux 容器。Docker 为开发人员提供了一种简单的方式将应用程序打包到轻量级容器中并在单个主机上运行它们，从而大大降低了容器采用的门槛。Google 的工程师，包括 Craig McLuckie, Joe Beda, 和 Brendan Burns，对这一发展感到兴奋。他们看到，虽然 Docker 可以在一台机器上启动一个容器，但真正的挑战将是为实际应用程序跨机器集群协调容器。Google 已经通过 Borg/Omega 在内部解决了这个问题，并认识到开源集群管理器补充 Docker 的机会（并且可以说是不可避免的）。2013 年秋天，Google 内部的一个小团队开始原型化 Kubernetes，旨在“将 Borg/Omega 的所有宏伟元素与 Docker 的容器结合起来”。这项工作最初的代号是 “Project Seven of Nine”，以致敬《星际迷航》的 Borg（Seven of Nine 是一个重新获得自主权的 Borg 角色，这是一个关于将 Borg 的概念解放到开源中的内部笑话）。
一个主要的动机是使 Google 的基础设施技术诀窍能够被世界各地的开发人员访问，这意味着 Kubernetes 必须是开源的。Google 的云平台在 2013-2014 年仍然很年轻，如果他们想建立一个新的标准，仅仅提供一个闭源的“Google 专用”编排器是不可行的。开源 Kubernetes 最初是一个有争议的想法，甚至 Google 的 CTO Urs Hölzle 也对“放弃我们最具竞争力的优势之一”持谨慎态度。然而，领导层认识到，为了“弥合内部和外部之间的差距”并建立一个充满活力的技术生态系统，开源是唯一的选择。Kubernetes 从一开始就被设计成一个其他人可以在任何地方（本地或任何云上）运行的平台，而不是 Google 专有的服务。这一决定顺应了云原生运动的兴起：公司开始寻求混合云和多云解决方案，而可移植的编排器与这一趋势完美契合。 总而言之，Google 对 Kubernetes 的目标有两方面**：(1)** 与世界分享他们在大规模运行容器方面的最佳实践（从 Borg/Omega 中学到的），并在此过程中成为新兴的云原生生态系统的领导者；(2) 解决开发人员随着容器采用量激增而面临的新挑战，提供一种简单、自动化的方式来管理跨多个主机的容器化应用程序，这是 Docker 单独无法做到的。Kubernetes 团队有意从“最小可行编排器”开始，仅包含在生产环境中运行容器所需的基本功能，并计划快速迭代。核心功能集来自 Google 的经验**：复制**（运行服务的多个实例以实现规模和可靠性）、服务发现和负载均衡（将流量路由到容器）、健康检查和自我修复（在容器或节点发生故障时自动重启/替换）以及批量调度（将机器池视为一个聚合资源）。有了这个基础，Kubernetes 旨在解决部署容器的痛苦的手动流程，并实现一种可以在各种基础设施上工作的“云原生”应用程序部署方法。这是一个大胆的愿景，旨在普及 Google 诞生的容器编排概念。
从内部项目到开源成功：早期时间线 (2013-2016)
2013 - 起源： Google 的 Omega 项目在内部启动，改进了 Borg 的想法（例如，使用共享的 Paxos 支持的存储和多个调度器）。与此同时，Docker 在 2013 年 3 月的公开发布激发了人们对容器的广泛兴趣。在 2013 年下半年，看到 Docker 的势头，Google 工程师 Brendan Burns, Joe Beda, Craig McLuckie（以及其他人）开始原型设计一种受 Borg/Omega 影响的新容器管理器，这个秘密项目（最终成为 Kubernetes）在 Google 内部诞生。到 2013 年 10 月，该团队正在研究早期的 Kubernetes API 设计，尽管尚未决定该项目是纯粹的内部项目还是开源项目。代号“Project Seven of Nine”在此阶段在内部使用。
2014 - 开源亮相： 2014 年年中，Google 公开了 Kubernetes。第一个 Kubernetes 提交于 2014 年 6 月 6 日被推送到 GitHub，为该项目提供了大约 47,000 行代码（Go、Bash 等）。几天后的 6 月 10 日，Google 的 Eric Brewer 在 DockerCon 2014 的主题演讲中向世界宣布了 Kubernetes。在发布时，Kubernetes 被呈现为 Google 内部集群管理技术的开源版本，本质上是“为外部世界重新设计的 Borg”。Google 从一开始就有意邀请广泛的社区协作：Microsoft、Red Hat、IBM 和 Docker Inc. 等其他行业领导者是 Kubernetes 项目的早期合作伙伴。Kubernetes 的初始公共版本 (v0.1) 已经包含了容器编排的基本构建块：pod 的概念、集群调度、复制控制器、通过集群 IP 的服务发现和健康监控。该项目迅速引起了 GitHub 和邮件列表的兴趣，因为它填补了单主机 Docker 之外的多容器自动化的明显空白。在 2014 年末，Google 和一个小型开源社区公开迭代 Kubernetes，添加功能并修复错误，为生产就绪的发布做准备。
2015 - Kubernetes 1.0 和 CNCF 捐赠： 经过一年的快速开发，Kubernetes 在 2015 年 7 月 21 日发布 1.0 版本时达到了一个重要的里程碑。这在 O'Reilly OSCON 会议上公布，标志着 Kubernetes 毕业成为一个稳定、生产就绪的编排器。1.0 版本巩固了核心功能（例如 pod、复制控制器、服务、卷等的稳定 API），并整合了早期用户的反馈。至关重要的是，Google 同时宣布它将 Kubernetes 捐赠给一个新的开源基金会，即 Linux 基金会旗下的云原生计算基金会 (CNCF)。CNCF 刚刚由一个科技公司联盟（Google、Red Hat、Microsoft、Docker、IBM 等）成立，其使命是促进云原生软件的发展。捐赠 Kubernetes 是一项战略举措，旨在向社区保证这项技术是真正开放的，不受 Google 的 sole 控制。在 1.0 之后，贡献者基础显着扩大：Google 的初始团队加入了来自 Red Hat（将其 OpenShift 平台与 Kubernetes 集成）和其他公司的工程师，带来了宝贵的企业和开源经验。到 2015 年底，Kubernetes 迅速成为 GitHub 上最受欢迎的项目之一，其他容器编排解决方案（如带有 Marathon 的 Mesos、Docker 的 Swarm 等）开始注意到它的快速崛起。
2016 - 快速增长和首个 CNCF 项目： 2016 年，Kubernetes 在功能和采用方面都进入了高速发展期。该项目作为其首个托管项目转移到 CNCF（实际上是在中立治理下孵化 Kubernetes）。凭借开放的治理模式和不断扩大的社区，开发速度加快。Kubernetes v1.1 和 v1.2（分别于 2015 年底和 2016 年第一季度发布）引入了重大改进，如水平 Pod 自动缩放和第一个版本的 Deployments（用于滚动更新），反映了该项目对实现工作负载高级自动化的关注。到 2016 年年中，各种规模的公司都在现场试用 Kubernetes。然而，陡峭的学习曲线显而易见，著名的倡导者 Kelsey Hightower 于 2016 年 7 月发布了 “Kubernetes the Hard Way”，以帮助用户了解 Kubernetes 的手动设置，强调可用性仍需改进。社区通过开发更简单的安装工具和更多文档来回应。Kubernetes v1.3 和 v1.4（2016 年夏季/秋季）扩展了对有状态应用程序的支持（为数据库等应用程序引入了 StatefulSets，以及处于 Beta 阶段的 PetSets），并添加了诸如批处理 Jobs 和 DaemonSets 之类的功能作为稳定的 API，证明 Kubernetes 可以处理云原生 12 因素应用程序和更传统的工作负载。到 2016 年底，Kubernetes v1.5 带来了对 Windows 容器（Alpha）和容器运行时接口（CRI）的支持，以允许可插拔的容器引擎，展示了一个成熟的架构。
进入 2017 年，Kubernetes 的发展势头明显。贡献者和采用组织的数量呈指数级增长。事实上，到 2017 年，Kubernetes 已经超越了竞争对手的编排平台（Docker Swarm、Apache Mesos 等），并且正在成为容器编排的事实上的行业标准。在 CNCF 下开源的早期决定得到了回报：通过培养一个多供应商社区，Kubernetes 的发展速度远远超过任何专有项目。2013 年最初作为一个大胆的内部想法，在短短几年内，已经转变为历史上增长最快的开源项目之一，从根本上塑造了云基础设施的未来。
关键事件时间表（2013-2025）¶
2013¶
- 2013 年秋季： Google 的一个小团队开始开发一个新的容器编排系统（灵感来自 Google 内部的 Borg/Omega 系统和 Docker 的兴起），该系统后来被命名为 Kubernetes。这标志着该项目在 Google 内部的开始。
2014¶
- 2014 年 6 月 6 日： Kubernetes 项目开源，第一个代码提交被推送到 GitHub。Google 与其他行业参与者（包括 Red Hat、Microsoft、IBM 和 Docker）合作，作为开源社区的早期合作者。
- 2014 年 6 月 10 日： Kubernetes 在 DockerCon 2014 上由 Google 的 Eric Brewer 在主题演讲中公开亮相。Google 在同一天的博客文章中正式宣布 Kubernetes 为开源容器编排平台（代号为“Project Seven”），向世界介绍了该项目。
2015¶
- 2015 年 7 月 21 日： Kubernetes v1.0 在 O’Reilly OSCON 会议上发布，标志着该项目的第一个稳定版本。与 v1.0 一起，Google 宣布将 Kubernetes 捐赠给 Linux 基金会下新成立的云原生计算基金会（CNCF）。Kubernetes 成为 CNCF 的种子技术，为供应商中立的治理奠定了基础。
2016¶
- 2016 年 3 月 10 日： Kubernetes 正式加入 CNCF，成为其首个托管项目。此举将 Kubernetes 的治理权移交给一个多方利益相关者的基金会，确保该项目不受任何一家公司的控制。
- 2016 年 4 月： Kubernetes 社区建立了特殊兴趣小组（SIG），以组织跨特定领域（例如，与 OpenStack 集成的 SIG-OpenStack）的开发和设计工作。这些 SIG 实现了来自许多组织的贡献者之间的重点协作，并有助于扩展快速增长的贡献者基础。
- 2016 年 12 月： Kubernetes v1.5 发布，引入了 Alpha 版本的容器运行时接口（CRI）（允许可插拔的容器运行时）和初始的 Windows Server 节点支持（Alpha）。API 服务器还首次采用 OpenAPI 规范，为可扩展的 API 铺平了道路，并且诸如StatefulSets（用于有状态应用程序）和 Pod Disruption Budgets 之类的功能达到了 Beta 状态。
2017¶
- 2017年4月：Kubernetes v1.6 引入了基于角色的访问控制 (RBAC)，以增强集群安全性。RBAC 成为定义细粒度权限的标准机制，取代了以前基于属性的访问控制。
- 2017年6月：Kubernetes v1.7 弃用了旧的 ThirdPartyResource 扩展机制，并以自定义资源定义 (CRD) 取代。CRD 使⽤户能够使⽤⾃⼰的资源类型扩展 Kubernetes API，从⽽极⼤地提⾼了平台的可扩展性。
- 2017年10月：Kubernetes 社区举行了首次指导委员会选举。成立了一个由 7 名成员组成的指导委员会，负责监督项目治理。该委员会（由社区选举产生的来自多个组织的贡献者组成）正式确定了 Kubernetes 的治理，标志着该项目向社区驱动的领导模式过渡。
- 2017年12月：Kubernetes v1.9 见证了核心工作负载 API（Deployments、ReplicaSets 等）升级为正式发布 (GA)。Deployments 和 ReplicaSets（经过一年多的实际使用）的稳定标志着核心的成熟；该版本的博客指出，这些 API 现在可以稳定地用于生产环境。
2018
- 2018 年 3 月 6 日：Kubernetes 成为第一个从 CNCF 孵化器状态毕业的项目。毕业反映了项目的成熟度、治理稳定性和多供应商贡献。到那时，Kubernetes 迅速扩大了其贡献者基础，并巩固了其作为行业标准容器编排器的地位。
- 2018 年 12 月： Kubernetes v1.13 发布，其中包含多项重大增强功能。容器存储接口 (CSI) 达到正式发布 (GA)，为 Kubernetes 启用了树外存储卷插件。集群引导工具 kubeadm 也升级为 GA，成为初始化生产集群的官方工具。此外，CoreDNS 在此版本中取代 kube-dns 成为 Kubernetes 集群的默认 DNS 服务，从而提高了集群 DNS 的可靠性和可扩展性。
2019
- 2019 年 3 月 25 日： Kubernetes v1.14 提供了对 Windows Server 容器和节点的生产级支持，允许在集群中与 Linux 工作负载一起调度 Windows 工作负载。经过几个版本的 Beta 测试后，Windows 节点支持现在已正式稳定，使组织能够在 Kubernetes 上运行基于 Windows 的应用程序，并具有完整的节点管理和编排功能。
- 2019 年 9 月： Kubernetes v1.16 标志着自定义资源定义 (CRD) 达到正式发布 (GA)。这一里程碑巩固了 CRD 作为自定义 Kubernetes API 的主要扩展机制（完全取代 ThirdPartyResources），并反映了该项目对可扩展性的重视。1.16 版本还著名地删除了几个已弃用的 API 和旧资源版本，要求用户迁移到稳定的 API——这是对社区弃用政策的早期测试。
2020
- 2020 年 8 月： Kubernetes v1.19 将支持的补丁升级窗口延长至 1 年（之前约为 9 个月）。做出此更改是为了增加支持的版本的数量，以便更好地适应企业升级周期并降低升级频率，尤其是在 COVID-19 大流行带来的挑战下。
- 2020 年 12 月： Kubernetes v1.20 正式弃用 Docker 作为容器运行时（“Dockershim”组件）。此具有里程碑意义的弃用（通过 v1.20 发行说明宣布）标志着该项目已完全过渡到容器运行时接口：Kubernetes 将依赖于符合 OCI 的运行时（如 containerd 或 CRI-O），而不是 Docker Engine。此更改引发了广泛的讨论，因为它明确了 Kubernetes 内部不再需要特定于 Docker 的集成。
2021
- 2021 年 4 月： Kubernetes 发布节奏从每年四个版本调整为每年三个版本。发布 SIG 做出此决定是为了提高质量并减少倦怠，从而为贡献者提供更多版本之间的间隔时间。它体现了社区对项目规模和可持续性的响应。
- 2021 年 7 月： Kubernetes v1.22 停止使用许多长期弃用的 beta API，而改用稳定的等效项。这包括删除几个被广泛使用的 beta API 版本，这是一项重大的清理工作，加强了 Kubernetes 的 API 弃用策略（例如，在发出多年警告后，较旧的 Ingress 和 RBAC beta API 已被删除）。集群运营商必须确保他们的配置已更新，这标志着在沟通重大更改方面“吸取了教训”。
- 2021 年 12 月： Kubernetes v1.23 实现了 双栈 IPv4/IPv6 网络正式发布 (GA)。经过多个版本的努力，集群可以原生支持具有 IPv4 和 IPv6 地址的 Pod 和服务。双栈 GA 是一个重要的网络里程碑，使 Kubernetes 能够处理混合 IP 环境的现代网络需求。
2022
- 2022年5月：Kubernetes v1.24 发布，并完全移除了 Dockershim 组件，这意味着 Docker Engine 不能再直接用作 Kubernetes 的容器运行时。用户必须使用符合 CRI 的运行时（如 containerd 或 CRI-O）。在 v1.24 中，该项目还默认禁用了旧的 Beta API，以减少升级冲突，这是 API 清理策略的延续。Dockershim 的移除引起了一些用户的困惑和迁移痛点，促使社区改进未来关于弃用的沟通。
- 2022年12月：Kubernetes v1.26 包括对批处理调度系统的重大改革，并更新了 Job API。这些改进通过增强作业排队和执行可靠性，更好地支持 AI/ML 和其他批处理工作负载。此版本突显了 Kubernetes 为适应新兴用例（如机器学习）所做的持续努力，通过发展核心 API（Batch/Job）使其对于大规模并行作业更加健壮和功能丰富。
2023
- 2023年4月3日： Kubernetes 项目完成镜像仓库迁移。旧的容器镜像仓库 k8s.gcr.io 在此日期被冻结，所有 Kubernetes 镜像都迁移到社区控制的 registry.k8s.io。此举迁移到 CNCF 拥有的仓库，确保了该项目的工件（容器镜像）位于供应商中立的位置，并解决了 Kubernetes 镜像下载量持续增长带来的可扩展性和成本问题。（在此之后，新的 Kubernetes 版本和组件仅发布到 registry.k8s.io 仓库。）
- 2023年11月： Kubernetes 保持着其作为世界上最大的开源项目之一的地位，其贡献者总数仅次于 Linux 内核。到 2023 年底，该项目已聚集了来自全球 8,000 多家公司的超过 88,000 名贡献者，这证明了推动该项目向前发展的庞大社区和行业采用。（这是一个项目状态的里程碑，反映了其在过去十年中贡献者和用户的巨大增长。）
2024
- 2024年6月6日：Kubernetes 庆祝其自首次公开提交以来的 10 周年。在回顾中，社区强调了 Kubernetes 演变为拥有数百万贡献的全球生态系统，并指出 Kubernetes 已成为全球贡献者人数第一或第二大的开源项目。该项目爆炸性的增长（从 2014 年的少数 Google 工程师到 2024 年的数万名贡献者）突显了其对现代云计算的影响。
- 2024年10月1日：Kubernetes v1.31 发布，完成了长期计划的从核心 Kubernetes 代码库中移除所有“内置”云提供商代码。与云提供商（AWS、Azure、GCP、vSphere、OpenStack）的集成现在通过外部云控制器管理器插件完成，而不是通过内置代码完成。这被描述为“Kubernetes 历史上最大的迁移”，大约删除了 150 万行供应商特定的代码，以实现更精简、真正供应商中立的核心。移除内置云提供商（始于 2018 年）显著减小了 Kubernetes 的二进制文件大小和攻击面，并表明了该项目对可扩展性而非内置云逻辑的承诺。
2025
- 2025年4月23日：Kubernetes v1.33 发布（代号“Octarine”），引入了 60 多项增强功能，重点是安全性、可扩展性和开发者体验。值得注意的是，此版本默认启用 Linux 用户命名空间用于 Pod（默认启用 Beta 功能），这是一个重要的安全里程碑，允许将每个 Pod 的 root 用户映射到主机上的非特权 UID，从而提高隔离性（即默认支持“无根”容器）。这一历时多年的变化通过限制容器突破的潜在影响，加强了 Kubernetes 容器的安全性。到 2025 年，Kubernetes 将继续通过此类渐进式改进而成熟，同时保持向后兼容及其单一的“v1.x”版本沿袭，反映了该项目对进化式进步的重视，而没有破坏性的“2.0”。
最后的想法
在其早期开发阶段（2013-2016年），Kubernetes 大量借鉴了 Google 在 Borg 和 Omega 方面十年的经验，将经过实战检验的概念移植到一个更易于访问、模块化的系统中。几乎每一个设计选择，从 Pod 和控制器，到基于标签的 API 和可观察的期望状态存储，都可以追溯到这些内部系统中所汲取的经验教训。Kubernetes 的架构师有意识地避免了 Borg 的缺陷（单体设计和一刀切的抽象），同时在对开发者友好的软件包中采纳了它的优势（高效调度、自我修复、高利用率）。该项目快速的开源演进是由明确的动机驱动的：解决随着容器使用量激增而出现的紧迫的新问题，并以任何公司或开发者都可以利用的方式来解决，而不仅仅是 Google。通过尽早将 Kubernetes 捐赠给 CNCF 并建立广泛的社区，Google 确保 Kubernetes 不仅仅是一个内部工具，它成为了一个蓬勃发展的云原生生态系统标准。2013-2016 年的技术里程碑，从第一次公开提交到 1.0 版本发布及以后，讲述了 Kubernetes 从 Google 内部原型到现代基础设施基石的转变历程。虽然 Kubernetes 在 2016 年之后仍在不断发展，但其核心架构和目标在早期就已通过 Borg 和 Omega 的影响而得到巩固，为我们部署和扩展软件的方式带来了一场革命奠定了基础。
常见问题解答
什么系统启发了 Kubernetes 的设计？
Kubernetes 受 Google 内部集群管理器 Borg 和 Omega 的影响很大。这些系统塑造了 Pod、调度和控制平面设计等关键概念。
为什么 Google 决定开源 Kubernetes？
Google 开源 Kubernetes 是为了分享其基础设施专业知识，加速容器编排的采用，并培养一个中立的、社区驱动的生态系统。
Pod 抽象在 Kubernetes 中的意义是什么？
Pod 起源于 Borg 中的模式，在 Borg 中，密切相关的任务被共同定位。Kubernetes 将这个概念形式化，以简化调度和容器分组。
Kubernetes 在架构上与 Borg 和 Omega 有何不同？
与 Borg 的单体主节点或 Omega 的共享状态模型不同，Kubernetes 引入了一个以 API 服务器、控制器和 etcd 为中心的模块化架构。
Kubernetes 何时成为 CNCF 的一部分，为什么？
Kubernetes 于 2015 年 7 月捐赠给 CNCF，以确保供应商中立的治理并加速社区采用，使其成为 CNCF 的第一个托管项目。
