Kubernetes 十周年！！

来源：CNCF

作者：Bob Killen（CNCF）、Chris Short（AWS）、Frederico Muñoz（SAS）、Kaslin Fields（Google）、Tim Bannister（The Scale Factory），以及全球每一位贡献者。

十年前，即 2014 年 6 月 6 日，Kubernetes 的首个提交被推送到 GitHub。这份包含 250 个文件和 47,501 行 go、bash 和 markdown 的初始提交，开启了我们如今拥有的项目。谁能预见，十年后，Kubernetes 将成长为迄今为止最大的开源项目之一，拥有超过 88,000 名来自 8,000 多家公司、遍及 44 个国家的贡献者。

这一里程碑不仅属于 Kubernetes，也属于从中蓬勃发展的云原生生态系统。CNCF 内有近 200 个项目，240,000 多名个人贡献者以及成千上万的更广泛生态系统的参与者。没有他们，没有 700 多万开发者，以及更大的用户社区，Kubernetes 不可能达到今天的地位。

Kubernetes 的起源 — 技术的融合

Kubernetes 背后的理念远早于首次提交，甚至早于 2013 年的第一个原型。在 2000 年代初，摩尔定律正全面生效。计算硬件以惊人的速度变得越来越强大。相应地，应用程序变得越来越复杂。硬件商品化与应用复杂性的结合指出了进一步抽象软件与硬件的需求，解决方案开始出现。

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

我们使用容器这个词来表示一种结构，用于追踪和收费工作负载如内存、任务等系统资源的使用。

Google 的大规模应用编排管理系统 Borg 在 2000 年代中期采用了 Linux 容器。此后，公司还开始研发名为“Omega”的系统新版本。熟悉 Borg 和 Omega 系统的 Google 工程师看到了 Docker 推动的容器化流行趋势。他们不仅认识到开源容器编排系统的需求，而且正如 Brendan Burns 在这篇博客文章[1]中所述，这是“不可避免”的。2013 年秋天的这一认识激发了一个小团队开始着手一个项目，后来成为 Kubernetes。该团队包括 Joe Beda、Brendan Burns、Craig McLuckie、Ville Aikas、Tim Hockin、Dawn Chen、Brian Grant 和 Daniel Smith。

2013 年 3 月，Solomon Hykes 在 PyCon 上进行了一个 5 分钟的闪电演讲，题为“Linux 容器的未来”，介绍了即将推出的名为“Docker”的开源工具，用于创建和使用 Linux 容器。Docker 为 Linux 容器引入了一种可用性水平，使其比以往任何时候都更容易为更多用户所用，Docker 的普及，从而 Linux 容器的普及，一飞冲天。随着 Docker 让 Linux 容器的抽象变得人人皆可访问，以更加便携和可重复的方式运行应用程序突然间成为了可能，但规模问题仍然存在。

Kubernetes 的十年历程

Kubernetes 的历史始于 2014 年 6 月 6 日的那次历史性提交，随后是 Google 工程师 Eric Brewer 在 2014 年 DockerCon 的 6 月 10 日主题演讲中宣布该项目（以及相应的 Google 博客）。

在接下来的一年里，主要来自 Google 和红帽的小型贡献者社区努力工作，最终在 2015 年 7 月 21 日发布了 1.0 版本。与 1.0 版同时，Google 宣布 Kubernetes 将捐赠给 Linux 基金会的一个新分支 —— 云原生计算基金会（CNCF）。

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

自最初 1.0 版本发布以来，项目发生了巨大变化；经历了一系列重大胜利，例如自定义资源定义（CRD）在 1.16 中进入 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 中，第三方资源（“TPRs”）被 CustomResourceDefinitions（CRDs）取代。
2017 年 12 月 — Kubernetes 1.9 中，工作负载 API 成为 GA（General Availability）。发布博客指出：“Deployment 和 ReplicaSet，作为 Kubernetes 中最常用的对象，在经过一年的实际使用和反馈后，现在稳定下来。”
2018 年 12 月 — 在 1.13 版本中，容器存储接口（CSI）达到 GA，用于引导最小可行集群的 kubeadm 工具达到 GA，CoreDNS 成为默认的 DNS 服务器。
2019 年 9 月 — Custom Resource Definitions 在 Kubernetes 1.16 中达到 GA。
2020 年 8 月 — Kubernetes 1.19 将版本支持窗口增加至 1 年。
2020 年 12 月 — Dockershim 在 1.20 中被废弃。
2021 年 4 月 — Kubernetes 的发布节奏从每年 4 次改为每年 3 次。
2021 年 7 月 — 广泛使用的 Beta APIs 在 Kubernetes 1.22 中被移除。
2022 年 5 月 — Kubernetes 1.24 中，Beta APIs 默认禁用以减少升级冲突，Dockershim 的移除导致用户广泛困惑（我们已经改进了沟通！）
2022 年 12 月 — 在 1.26 中，批处理和 Job API 进行了重大改造，为 AI/ML/批处理工作负载提供更好支持。

PS: 想亲眼看看项目已经走了多远？查看由社区成员 Carlos Santana、Amim Moises Salum Knabben 和 James Spurin 创建的教程，学习如何启动一个 Kubernetes 1.0 集群[2]。

Kubernetes 提供了数不清的扩展点。最初设计只与 Docker 兼容，现在可以插入任何遵循 CRI 标准的容器运行时。还有其他类似的接口：CSI 用于存储，CNI 用于网络。而这远非全部。在过去十年，出现了全新的模式，比如使用 Custom Resource Definitions（CRDs）来支持第三方控制器——现在是 Kubernetes 生态系统的重要组成部分。

构建项目的社区在过去十年中也大幅扩展。通过 DevStats，我们可以看到过去十年中令人难以置信的贡献量，使 Kubernetes 成为世界第二大开源项目：

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

Kubernetes 现状

从早期开始，项目在技术能力、使用和贡献方面都经历了巨大增长。项目仍在积极工作，以改进并更好地服务其用户。

在即将到来的 1.31 版本中，项目将庆祝一个重要长期项目的完成：删除内置云提供商代码。在这次 Kubernetes 历史上最大的迁移中，大约 150 万行代码被移除，核心组件的二进制大小减少了约 40%。在项目早期，很明显，可扩展性是成功的关键。然而，如何实现这种可扩展性并不总是清晰的。这次迁移从核心 Kubernetes 代码库中移除了各种供应商特定功能。供应商特定功能现在可以通过其他可插拔的扩展特性或模式更好地提供，比如 Custom Resource Definitions（CRDs）或像 Gateway API 这样的 API 标准。Kubernetes 也面临着为庞大用户群服务的新挑战，社区正在相应调整。一个例子就是将镜像托管迁移到新的、社区所有的 registry.k8s.io。为用户提供预编译二进制镜像的出站带宽和成本变得巨大。这项新的注册表更改使社区能够以更经济高效和性能高效的方式继续提供这些方便的镜像。确保你阅读博客文章[3]并更新任何自动化流程以使用 registry.k8s.io！

Kubernetes 的未来

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

2024 年，人工智能的兴起将曾经的小众工作负载类型转变为至关重要的需求。分布式计算和工作负载调度始终与人工智能、机器学习和高性能计算工作负载的资源密集型需求紧密相关。贡献者密切关注新开发的工作负载需求以及 Kubernetes 如何最好地满足它们。新的Serving 工作组[4]就是一个例子，说明社区如何组织起来应对这些工作负载的需求。很可能未来几年我们将看到 Kubernetes 管理各种类型硬件的能力以及管理大批次风格工作负载调度的能力得到提升，这些工作负载是在硬件上分块运行的。

围绕 Kubernetes 的生态系统将继续增长和进化。未来，维护项目可持续性的举措，如内置供应商代码的迁移和注册表变更，将变得越来越重要。

Kubernetes 的下一个十年将由其用户和生态系统指导，但最重要的是，由那些为之做出贡献的人们引导。社区对新贡献者开放。你可以在我们的新贡献者指南中找到更多信息，网址是https://k8s.dev/contributors。

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