Kubernetes 十周年
十年前，即 2014 年 6 月 6 日，Kubernetes 的第一次提交被推送到了 GitHub。那次包含 250 个文件和 47,501 行 go、bash 和 markdown 代码的首次提交启动了我们今天的项目。谁能预料到 10 年后，Kubernetes 会发展成为迄今为止最大的开源项目之一，拥有来自 44 个国家，8000 多家公司的 88,000 多名贡献者。
这个里程碑不仅属于 Kubernetes，也属于由此蓬勃发展的云原生生态系统。CNCF 本身就有近 200 个项目，来自 240,000 多名个人贡献者，并且在更大的生态系统中还有成千上万的贡献者。如果没有他们，700 多万名开发者，以及更大的用户社区，Kubernetes 就不会有今天的成就，他们都帮助塑造了今天的生态系统。
Kubernetes 的开端 - 技术的融合
Kubernetes 的基本思想早在第一次提交之前，甚至在第一个原型（大约在 2013 年出现）之前就已开始酝酿。在 21 世纪初，摩尔定律正在发挥作用。计算硬件正以惊人的速度变得越来越强大。相应地，应用程序也变得越来越复杂。硬件商品化和应用程序复杂性的这种结合表明，需要进一步将软件从硬件中抽象出来，并且解决方案开始涌现。
像当时许多公司一样，谷歌正在快速扩张，其工程师对在 Linux 内核中创建一种隔离形式的想法很感兴趣。谷歌工程师 Rohit Seth 在 2006 年的一封电子邮件中描述了这个概念：
我们使用术语“容器”来表示一种结构，我们使用它来跟踪和计算工作负载的系统资源（如内存、任务等）的利用率。
2013 年 3 月，在 PyCon 上，Solomon Hykes 发表了一个名为“Linux 容器的未来”的 5 分钟闪电演讲，介绍了一个即将推出的开源工具，名为“Docker”，用于创建和使用 Linux 容器。Docker 为 Linux 容器引入了可用性，使其比以往任何时候都更容易被更多用户访问，并且 Docker 的普及，以及 Linux 容器的普及，迅速飙升。随着 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 日，谷歌工程师 Eric Brewer 在 DockerCon 2014 的主题演讲（以及相应的谷歌博客）中宣布该项目。
在接下来的一年里，一个由主要来自谷歌和红帽的贡献者组成的小社区努力工作，最终在 2015 年 7 月 21 日发布了 1.0 版本。与 1.0 版本一起，谷歌宣布 Kubernetes 将被捐赠给 Linux 基金会新成立的一个分支，称为云原生计算基金会 (CNCF)。
尽管达到了 1.0 版本，但 Kubernetes 项目仍然非常难以使用和理解。Kubernetes 贡献者 Kelsey Hightower 特别注意到了该项目在易用性方面的缺点，并在 2016 年 7 月 7 日，他推送了他著名的“Kubernetes Hard Way”指南的首次提交。
自最初的 1.0 版本以来，该项目发生了巨大变化；经历了一些重大胜利，例如 1.16 版本中正式发布的自定义资源定义 (CRD)或 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 (CRD) 取代。
- 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 月 — 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 进行了重大改造，为更好地支持 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) 或 API 标准（如 Gateway API）。Kubernetes 在服务其庞大的用户群方面也面临着新的挑战，社区正在相应地进行调整。这方面的一个例子是将镜像托管迁移到新的社区所有 registry.k8s.io。为用户提供预编译二进制镜像的出站带宽和成本已经变得非常巨大。这项新的注册表变更使社区能够以更具成本效益和性能效率的方式继续提供这些便捷的镜像。请务必查看博客文章并更新您的任何自动化脚本以使用 registry.k8s.io！
Kubernetes 的未来
十年过去了，Kubernetes 的未来仍然一片光明。社区正在优先考虑既能改善用户体验又能增强项目可持续性的变更。应用程序开发领域不断发展，Kubernetes 也将随之改变。
2024 年，人工智能的出现将曾经的小众工作负载类型转变为最重要的工作负载类型之一。分布式计算和工作负载调度一直与人工智能、机器学习和高性能计算工作负载的资源密集型需求密不可分。贡献者正在密切关注新开发的工作负载的需求，以及 Kubernetes 如何才能最好地为它们服务。新的 Serving 工作组是社区如何组织起来解决这些工作负载需求的一个例子。未来几年，Kubernetes 在管理各种类型硬件的能力以及管理跨硬件分块运行的大型批处理式工作负载的调度能力方面可能会有所改进。
围绕 Kubernetes 的生态系统将继续发展和演变。未来，为了维护项目的可持续性，诸如迁移树内供应商代码和注册表变更之类的举措将变得更加重要。
Kubernetes 的未来 10 年将由其用户和生态系统指导，但最重要的是由为其做出贡献的人们指导。社区仍然欢迎新的贡献者。您可以在我们的新贡献者课程中找到有关贡献的更多信息，网址为 https://k8s.dev/docs/onboarding。
我们期待与您共同构建 Kubernetes 的未来！
