Kubernetes 10 周年

十（10）年前，即 2014 年 6 月 6 日，Kubernetes 的第一个 commit被推送到 GitHub。这第一个 commit 包含了 250 个文件和 47501 行 go、bash 和 markdown 代码，开启了我们今天所拥有的这个项目。谁能预料到 10 年后，Kubernetes 会成长为迄今为止最大的开源项目之一，拥有来自超过 8000 家公司、遍布 44 个国家的88,000 多名贡献者。

这个里程碑不仅属于 Kubernetes，也属于由它催生的云原生生态系统。仅在 CNCF 内部就有近 200 个项目，来自240,000 多名个人贡献者的贡献，而在更广泛的生态系统中还有数千个项目。没有他们、没有超过 700 万的开发者以及更庞大的用户社区，Kubernetes 不会有今天的成就，是大家共同塑造了今天的生态系统。

Kubernetes 的起源 - 技术的融合

Kubernetes 背后的思想早在第一个 commit 甚至第一个原型（诞生于 2013 年）之前就已经存在了。在 21 世纪初，摩尔定律正发挥着显著作用。计算硬件正以惊人的速度变得越来越强大。相应地，应用程序也变得越来越复杂。硬件的商品化和应用程序的复杂性相结合，表明需要进一步将软件从硬件中抽象出来，解决方案开始出现。

像当时许多公司一样，谷歌正在迅速扩张，其工程师对在 Linux 内核中创建一种隔离形式的想法很感兴趣。谷歌工程师 Rohit Seth 在 2006 年的一封电子邮件中描述了这个概念：

我们使用“容器”这个术语来表示一种结构，我们通过它来跟踪和计费工作负载所使用的系统资源，如内存、任务等。

2013 年 3 月，在 PyCon 大会上，一个名为“Linux 容器的未来”的 5 分钟闪电演讲（由 Solomon Hykes 发表）介绍了一款即将推出的名为“Docker”的开源工具，用于创建和使用 Linux 容器。Docker 为 Linux 容器带来了前所未有的易用性，使其对更多用户开放，Docker 以及 Linux 容器的普及度因此 skyrocketed。随着 Docker 让 Linux 容器的抽象变得人人可用，以更具可移植性和可重复性的方式运行应用程序突然成为可能，但规模化的问题依然存在。

谷歌用于大规模管理应用程序编排的 Borg 系统，在 21 世纪中期随着 Linux 容器的发展而采用了它们。自那时起，该公司也开始着手开发该系统的一个新版本，名为“Omega”。熟悉 Borg 和 Omega 系统的谷歌工程师们看到了由 Docker 推动的容器化技术的普及。他们不仅认识到一个开源容器编排系统的需求，还认识到它的“必然性”，正如 Brendan Burns 在这篇博文中所描述的。2013 年秋天的这一认识，激励了一个小团队开始着手一个项目，这个项目后来成为了 Kubernetes。该团队成员包括 Joe Beda、Brendan Burns、Craig McLuckie、Ville Aikas、Tim Hockin、Dawn Chen、Brian Grant 和 Daniel Smith。

Kubernetes 的十年

Kubernetes 的历史始于 2014 年 6 月 6 日那次历史性的提交，以及随后在 6 月 10 日 DockerCon 2014 大会上由谷歌工程师 Eric Brewer 发表的主题演讲中宣布该项目（及其对应的谷歌博客）。

在接下来的一年里，一个由主要来自谷歌和红帽的贡献者组成的小型社区努力开发该项目，最终于 2015 年 7 月 21 日发布了 1.0 版本。与 1.0 版本一同，谷歌宣布将 Kubernetes 捐赠给 Linux 基金会一个新成立的分支，名为云原生计算基金会 (CNCF)。

尽管达到了 1.0 版本，但 Kubernetes 项目仍然非常难以使用和理解。Kubernetes 贡献者 Kelsey Hightower 特别注意到了该项目在易用性方面的不足，并于 2016 年 7 月 7 日，他提交了他著名的“Kubernetes the Hard Way”指南的第一个 commit。

自最初的 1.0 版本发布以来，该项目发生了巨大的变化；经历了许多重大胜利，例如 1.16 版本中自定义资源定义（CRD）的正式发布（GA） 或 1.23 版本中全面双栈支持的推出，以及社区从 1.22 版本中移除广泛使用的 beta API 或弃用 Dockershim 中吸取的“经验教训”。

自 1.0 版本以来的一些值得注意的更新、里程碑和事件包括：

• 2016 年 12 月 — Kubernetes 1.5 引入了运行时可插拔性，初步支持 CRI，并提供了 Alpha 版本的 Windows 节点支持。OpenAPI 也首次出现，为客户端能够发现扩展 API 铺平了道路。
  • 此版本还引入了 Beta 阶段的 StatefulSets 和 PodDisruptionBudgets。
• 2017 年 4 月 — 引入了基于角色的访问控制（RBAC）。
• 2017 年 6 月 — 在 Kubernetes 1.7 中，ThirdPartyResources 或 "TPRs" 被自定义资源定义（CRDs）取代。
• 2017 年 12 月 — Kubernetes 1.9 见证了 Workloads API 达到正式发布（GA）状态。该版本的博客文章指出：“Deployment 和 ReplicaSet 这两个 Kubernetes 中最常用的对象，在经过一年多的实际使用和反馈后，现已稳定。”
• 2018 年 12 月 — 在 1.13 版本中，容器存储接口（CSI）达到正式发布（GA）状态，用于引导最小可行性集群的 kubeadm 工具也达到 GA 状态，CoreDNS 成为默认的 DNS 服务器。
• 2019 年 9 月 — 在 Kubernetes 1.16 中，自定义资源定义达到正式发布（GA）状态。
• 2020 年 8 月 — Kubernetes 1.19 将版本的支持窗口延长至 1 年。
• 2020 年 12 月 — 在 1.20 版本中，Dockershim 被弃用。
• 2021 年 4 月 — Kubernetes 的发布节奏从每年 4 个版本改为每年 3 个版本。
• 2021 年 7 月 — 在 Kubernetes 1.22 中，广泛使用的 beta API 被移除。
• 2022 年 5 月 — Kubernetes 1.24 版本中，beta API 默认被禁用，以减少升级冲突，并移除了 Dockershim，导致了广泛的用户困惑（此后我们改进了我们的沟通！）
• 2022 年 12 月 — 在 1.26 版本中，对批处理和 Job API 进行了重大改造，为更好地支持 AI / ML / 批处理工作负载铺平了道路。

附言：想亲眼看看这个项目走了多远吗？可以看看社区成员 Carlos Santana、Amim Moises Salum Knabben 和 James Spurin 创建的这个搭建 Kubernetes 1.0 集群的教程。

Kubernetes 提供了数不清的扩展点。最初设计为只与 Docker 配合使用，现在你可以插入任何遵循 CRI 标准的容器运行时。还有其他类似的接口：用于存储的 CSI 和用于网络的 CNI。但这远非你能做的全部。在过去十年中，全新的模式已经出现，例如使用

自定义资源定义 (CRDs) 来支持第三方控制器 - 这现在是 Kubernetes 生态系统的一个巨大组成部分。

在过去十年中，构建该项目的社区也极大地扩展了。使用 DevStats，我们可以看到过去十年中巨大的贡献量，这使得 Kubernetes 成为全球第二大开源项目。

• 88,474 名贡献者
• 15,121 位代码提交者
• 4,228,347 次贡献
• 158,530 个 Issue
• 311,787 个拉取请求

今日的 Kubernetes

自早期以来，该项目在技术能力、使用和贡献方面都取得了巨大的增长。该项目仍在积极努力改进，以更好地为其用户服务。

在即将到来的 1.31 版本中，该项目将庆祝一个重要的长期项目的 culmination：移除树内云提供商代码。在这场Kubernetes 历史上最大规模的迁移中，大约 150 万行代码被移除，核心组件的二进制文件大小减少了约 40%。在该项目的早期，很明显可扩展性将是成功的关键。然而，如何实现这种可扩展性并不总是那么清晰。这次迁移从核心 Kubernetes 代码库中移除了各种特定于供应商的功能。特定于供应商的功能现在可以由其他可插拔的扩展性特性或模式更好地服务，例如自定义资源定义 (CRDs) 或像 Gateway API 这样的 API 标准。Kubernetes 在服务其庞大的用户群方面也面临着新的挑战，社区正在相应地进行调整。其中一个例子是将镜像托管迁移到新的、社区拥有的 registry.k8s.io。为用户消费提供预编译二进制镜像的出站带宽和成本已经变得巨大。这个新的注册中心变更使社区能够以更具成本和性能效益的方式继续提供这些方便的镜像。请务必查看博文并更新您拥有的任何自动化，以使用 registry.k8s.io！

Kubernetes 的未来

十年过去了，Kubernetes 的未来依然光明。社区正在优先考虑那些既能改善用户体验，又能增强项目可持续性的变革。应用程序开发的世界在不断演进，Kubernetes 也准备好随之改变。

2024 年，人工智能的出现将一种曾经小众的工作负载类型转变为具有突出重要性的类型。分布式计算和工作负载调度一直与人工智能、机器学习和高性能计算工作负载的资源密集型需求紧密相连。贡献者们正密切关注新开发的工作负载的需求，以及 Kubernetes 如何能最好地为它们服务。新的服务工作组是社区如何组织起来以满足这些工作负载需求的一个例子。很可能在未来几年，我们会看到 Kubernetes 在管理各种类型硬件方面的能力得到提升，以及其在管理跨硬件分块运行的大型批处理式工作负载调度方面的能力得到增强。

围绕 Kubernetes 的生态系统将继续增长和演变。未来，像迁移树内供应商代码和注册中心变更这样的项目可持续性举措将变得越来越重要。

Kubernetes 的下一个十年将由其用户和生态系统引导，但最重要的是，由为其做出贡献的人们引导。社区仍然对新的贡献者开放。您可以在我们的新贡献者课程中找到更多关于贡献的信息，网址是 https://k8s.dev/docs/onboarding。

我们期待与您一起构建 Kubernetes 的未来！

• ←上一篇
• 下一篇→