By 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 代码，
开启了我们今天所拥有的项目。谁能预测到 10 年后，Kubernetes 会成长为迄今为止最大的开源项目之一，
拥有来自超过 8,000 家公司、来自 44 个国家的
88,000 名贡献者。
这一里程碑不仅属于 Kubernetes，也属于由此蓬勃发展的云原生生态系统。
在 CNCF 本身就有近 200 个项目，有来自
240,000 多名个人贡献者，
还有数千名来自更大的生态系统的贡献者的贡献。
如果没有 700 多万开发者和更庞大的用户社区，
Kubernetes 就不会达到今天的成就，他们一起帮助塑造了今天的生态系统。
Kubernetes 的起源 - 技术的融合
Kubernetes 背后的理念早在第一次提交之前，
甚至第一个原型（在 2013 年问世之前就已经存在。
在 21 世纪初，摩尔定律仍然成立。计算硬件正以惊人的速度变得越来越强大。
相应地，应用程序变得越来越复杂。硬件商品化和应用程序复杂性的结合表明需要进一步将软件从硬件中抽象出来，
因此解决方案开始出现。
像当时的许多公司一样，Google 正在快速扩张，其工程师对在 Linux 内核中创建一种隔离形式的想法很感兴趣。
Google 工程师 Rohit Seth 在 2006 年的一封电子邮件中描述了这个概念：
我们使用术语 “容器” 来表示一种结构，通过该结构我们可以对负载的系统资源（如内存、任务等）利用情况进行跟踪和计费。
2013 年 3 月，Solomon Hykes 在 PyCon 上进行了一场名为 “Linux容器的未来”的
5 分钟闪电演讲，介绍了名为 “Docker” 的一款即将被推出的开源工具，用于创建和使用 Linux 容器。Docker
提升了 Linux 容器的可用性，使其比以往更容易被更多用户使用，从而使
Docker 和Linux 容器的流行度飙升。随着 Docker 使 Linux 容器的抽象概念可供所有人使用，
以更便于移植且可重复的方式运行应用突然成为可能，但大规模使用的问题仍然存在。
Google 用来管理大规模应用编排的 Borg 系统在 2000 年代中期采用当时所开发的 Linux 容器技术。
此后，该公司还开始研发该系统的一个新版本，名为 “Omega”。
熟悉 Borg 和 Omega 系统的 Google 工程师们看到了 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 日的那次历史性提交，随后，
Google 工程师 Eric Brewer 在 2014 年 6 月 10 日的 DockerCon 2014
上的主题演讲(及其相应的 Google 博客)中由宣布了该项目。
在接下来的一年里，一个由主要来自 Google 和 Red Hat 等公司的贡献者组成的小型社区为该项目付出了辛勤的努力，最终在
2015 年 7 月 21 日发布了 1.0 版本。
在发布 1.0 版本的同时，Google 宣布将 Kubernetes 捐赠给 Linux 基金会下的一个新成立的分支，
即云原生计算基金会 (Cloud Native Computing Foundation，CNCF)。
尽管到了 1.0 版本，但 Kubernetes 项目的使用和理解仍然很困难。Kubernetes
贡献者 Kelsey Hightower 特别注意到了该项目在易用性方面的不足，并于 2016 年 7 月 7 日推出了他著名的
“Kubernetes the Hard Way” 指南的第一次提交。
自从最初的 1.0 版本发布以来，项目经历了巨大的变化，取得了许多重大的成就，例如
在 1.16 版本中正式发布的 Custom Resource Definitions (CRD) ，
或者在 1.23 版本中推出的全面双栈支持，以及社区从
1.22 版本中移除广泛使用的 Beta API
和弃用 Dockershim 中吸取的“教训”。
自 1.0 版本以来的一些值得注意的更新、里程碑和事件包括：
- 2016 年 12 月 - Kubernetes 1.5
引入了运行时可插拔性，初步支持 CRI 和 Alpha 版 Windows 节点支持。
OpenAPI 也首次出现，为客户端能够发现扩展 API 铺平了道路。- 此版本还引入了 Beta 版的 StatefulSet 和 PodDisruptionBudget。
- 2017 年 4 月 — 引入基于角色的访问控制（RBAC）。
- 2017 年 6 月 — 在 Kubernetes 1.7
中，ThirdPartyResources 或 "TPRs" 被 CustomResourceDefinitions（CRD）取代。 - 2017 年 12 月 — Kubernetes 1.9 中，
工作负载 API 成为 GA（正式可用）。发布博客中指出：“Deployment 和 ReplicaSet 是 Kubernetes 中最常用的两个对象，
在经过一年多的实际使用和反馈后，现在已经稳定下来。”
- 2018 年 12 月 — 在 1.13 版本中，容器存储接口（CSI）达到 GA，用于引导最小可用集群的 kubeadm 工具达到 GA，并且 CoreDNS 成为默认的 DNS 服务器。
- 2019 年 9 月 — 自定义资源定义（Custom Resource Definition）在 Kubernetes 1.16 中正式发布。
- 2020 年 8 月 — Kubernetes 1.19 将发布支持窗口增加到 1 年。
- 2020 年 12 月 — Dockershim 在 1.20 版本中被弃用。
- 2021 年 4 月 - Kubernetes 发布节奏变更，从每年发布 4 个版本变为每年发布 3 个版本。
- 2021 年 7 月 - 在 Kubernetes 1.22 中移除了广泛使用的 Beta API。
- 2022 年 5 月 - 在 Kubernetes 1.24 中，Beta API 默认被禁用，
以减少升级冲突，并移除了 Dockershim，导致用户普遍感到困惑
（我们已经改进了我们的沟通方式！） - 2022 年 12 月 - 在 1.26 版本中，进行了重大的批处理和作业 API 改进，
为更好地支持 AI/ML/批处理工作负载铺平了道路。
附言: 想亲自体会一下这个项目的进展么？可以查看由社区成员 Carlos Santana、Amim Moises Salum Knabben 和 James Spurin
创建的 Kubernetes 1.0 集群搭建教程。
Kubernetes 提供的扩展点多得数不胜数。最初设计用于与 Docker 一起工作，现在你可以插入任何符合
CRI 标准的容器运行时。还有其他类似的接口：用于存储的 CSI 和用于网络的 CNI。
而且这还远远不是全部。在过去的十年中，出现了全新的模式，例如使用自定义资源定义（CRD）
来支持第三方控制器 - 这现在是 Kubernetes 生态系统的重要组成部分。
在过去十年间，参与构建该项目的社区也得到了巨大的扩展。通过使用
DevStats，我们可以看到过去十年中令人难以置信的贡献量，这使得
Kubernetes 成为了全球第二大开源项目：
- 88,474 位贡献者
- 15,121 位代码提交者
- 4,228,347 次贡献
- 158,530 个问题
- 311,787 个拉取请求
Kubernetes 现状
自项目初期以来，项目在技术能力、使用率和贡献方面取得了巨大的增长。
项目仍在积极努力改进并更好地为用户服务。
在即将发布的 1.31 版本中，该项目将庆祝一个重要的长期项目的完成：移除内部云提供商代码。在这个
Kubernetes 历史上最大的迁移中，大约删除了
150 万行代码，将核心组件的二进制文件大小减小了约 40%。在项目早期，很明显可扩展性是成功的关键。
然而，如何实现这种可扩展性并不总是很清楚。此次迁移从核心 Kubernetes 代码库中删除了各种特定于供应商的功能。
现在，特定于供应商的功能可以通过其他可插拔的扩展功能或模式更好地提供，例如自定义资源定义（CRD）
或 Gateway API 等 API 标准。
Kubernetes 在为其庞大的用户群体提供服务时也面临着新的挑战，社区正在相应地进行调整。其中一个例子是将镜像托管迁移到新的、由社区拥有的
registry.k8s.io。为用户提供预编译二进制镜像的出口带宽和成本已经变得非常巨大。这一新的仓库变更使社区能够以更具成本效益和性能高效的方式继续提供这些便利的镜像。
请务必查看此博客文章并更新你必须使用 registry.k8s.io 仓库的任何自动化设施！
Kubernetes 的未来
十年过去了，Kubernetes 的未来依然光明。社区正在优先考虑改进用户体验和增强项目可持续性的变革。
应用程序开发的世界不断演变，Kubernetes 正准备随之变化。
2024 年，人工智能的进展将一种曾经小众的工作负载类型变成了一种非常重要的工作负载类型。
分布式计算和工作负载调度一直与人工智能、机器学习和高性能计算工作负载的资源密集需求密切相关。
贡献者们密切关注新开发的工作负载的需求以及 Kubernetes 如何为它们提供最佳服务。新成立的
Serving 工作组
就是社区组织来解决这些工作负载需求的一个例子。未来几年可能会看到
Kubernetes 在管理各种类型的硬件以及管理跨硬件运行的大型批处理工作负载的调度能力方面的改进。
Kubernetes 周围的生态系统将继续发展壮大。未来，为了保持项目的可持续性，
像内部供应商代码的迁移和仓库变更这样的举措将变得更加重要。
Kubernetes 的未来 10 年将由其用户和生态系统引领，但最重要的是，由为其做出贡献的人引领。
社区对新贡献者持开放态度。你可以在我们的新贡献者课程
https://k8s.dev/docs/onboarding 中找到更多有关贡献的信息。
我们期待与你一起构建 Kubernetes 的未来！
