Kubernetes 十周年

作者：Bob Killen (CNCF), Chris Short (AWS), Frederico Muñoz (SAS), Kaslin Fields (Google), Tim Bannister (The Scale Factory), 以及全球所有贡献者 | 2024 年 6 月 6 日，星期四

KCSEU 2024 group photo

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

这个里程碑不仅属于 Kubernetes，也属于从中蓬勃发展的云原生生态系统。CNCF 本身就有接近 200 个项目，来自 240,000 多名独立贡献者的贡献，以及更广阔生态系统中的数千名其他贡献者。没有他们、700 多万开发者以及更庞大的用户社区，Kubernetes 不会取得今天的成就，他们共同塑造了今天的生态系统。

Kubernetes 的开端——技术融合

Kubernetes 背后的理念早在第一个提交，甚至第一个原型（该原型于 2013 年出现）之前就已经萌芽。在 2000 年代初期，摩尔定律效应显著。计算硬件正以惊人的速度变得越来越强大。相应地，应用程序也变得越来越复杂。硬件的商品化和应用程序的复杂性的结合，指向了进一步将软件从硬件中抽象出来的需求，解决方案开始涌现。

像当时许多公司一样，Google 也在快速扩容，工程师们对在 Linux 内核中创建某种隔离的想法很感兴趣。Google 工程师 Rohit Seth 在 2006 年的一封电子邮件中描述了这个概念：

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

2013 年 3 月，在 PyCon 上，Solomon Hykes 发表了一场名为“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 年 DockerCon 大会 6 月 10 日的主题演讲（及其相应的Google 博客）中宣布该项目。

接下来的一年里，一个由主要来自 Google 和 Red Hat 的贡献者组成的小社区，努力工作，最终在 2015 年 7 月 21 日发布了 1.0 版本。伴随 1.0 版本的发布，Google 宣布将 Kubernetes 捐赠给一个新成立的 Linux Foundation 分支，称为云原生计算基金会 (CNCF)。

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

该项目自最初的 1.0 版本以来发生了巨大的变化；经历了一系列重大成功，例如Custom Resource Definitions (CRD) 在 1.16 版本达到正式发布，或者完整的双栈支持在 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”被替换为 CustomResourceDefinitions (CRDs)。
2017 年 12 月 — Kubernetes 1.9 中 Workloads API 达到正式发布 (Generally Available)。发布博客指出：“Deployment 和 ReplicaSet 是 Kubernetes 中最常用的两个对象，经过一年多的实际使用和反馈，现已稳定。”
2018 年 12 月 — 在 1.13 版本中，容器存储接口 (CSI) 达到正式发布，用于引导最小可行集群的 kubeadm 工具达到正式发布，CoreDNS 成为默认的 DNS 服务器。
2019 年 9 月 — Custom Resource Definitions 在 Kubernetes 1.16 中达到正式发布。
2020 年 8 月 — Kubernetes 1.19 将版本的支持窗口增加到 1 年。
2020 年 12 月 — Dockershim 在 1.20 版本中被弃用
2021 年 4 月 — Kubernetes 发布节奏从每年 4 个版本改为每年 3 个版本。
2021 年 7 月 — 广泛使用的 Beta API 在 Kubernetes 1.22 中被移除。
2022 年 5 月 — Kubernetes 1.24 将 Beta API默认禁用以减少升级冲突，并移除 Dockershim，导致广泛的用户困惑（此后我们改进了我们的沟通！）
2022 年 12 月 — 在 1.26 版本中，对批处理和 Job API 进行了重大 overhaul，为更好地支持 AI/ML/批处理工作负载铺平了道路。

PS：好奇项目已经发展到什么程度了吗？看看社区成员 Carlos Santana、Amim Moises Salum Knabben 和 James Spurin 创建的用于启动 Kubernetes 1.0 集群的教程。

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。为用户提供预编译二进制镜像的出站带宽和成本变得非常巨大。这项新的 registry 更改使社区能够以更具成本效益和性能效率的方式继续提供这些便捷的镜像。请务必查看博文，并更新您所有的自动化脚本以使用 registry.k8s.io！

Kubernetes 的未来

十年过去了，Kubernetes 的未来依然光明。社区正在优先进行改进用户体验和增强项目可持续性的改变。应用程序开发的世界持续演进，Kubernetes 也准备随之变化。

2024 年，人工智能的出现将曾经的小众工作负载类型变成了具有突出重要性的类型。分布式计算和工作负载调度一直与人工智能、机器学习和高性能计算工作负载对资源密集的需求紧密相连。贡献者们正密切关注新开发工作负载的需求，以及 Kubernetes 如何能够最好地为它们服务。新的服务工作组 (Serving Working Group) 是社区组织起来解决这些工作负载需求的一个例子。很可能未来几年 Kubernetes 在管理各种硬件类型以及管理在硬件上分块运行的大型批处理样式工作负载的调度能力方面将有所改进。

围绕 Kubernetes 的生态系统将持续增长和发展。未来，维护项目可持续性的举措，如内建供应商代码的迁移和 registry 的更改，将变得越来越重要。

Kubernetes 的下一个十年将由其用户和生态系统指导，但最重要的是由贡献者们塑造。社区始终对新贡献者开放。您可以在 https://k8s.dev/docs/onboarding 上的新贡献者课程中找到更多关于贡献的信息。

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