Kubernetes近十年里程碑及版本偏差策略
1、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/批处理工作负载铺平了道路。
Kubernetes 提供的扩展点多得数不胜数。最初设计用于与 Docker 一起工作，现在你可以插入任何符合 CRI 标准的容器运行时。还有其他类似的接口：用于存储的 CSI 和用于网络的 CNI。 而且这还远远不是全部。在过去的十年中，出现了全新的模式，例如使用自定义资源定义（CRD） 来支持第三方控制器 - 这现在是 Kubernetes 生态系统的重要组成部分。
2、发行版本历史及版本偏差策略
2.1 发行版本历史
Kubernetes 项目维护最近三个次要版本（1.30、1.29、 1.28）的发布分支。 Kubernetes 1.19 和更新版本获得大约 1 年的补丁支持。 Kubernetes 1.18 及更早版本获得了大约 9 个月的补丁支持周期。
Kubernetes 版本表示为 x.y.z， 其中 x 是主要版本，y 是次要版本，z 是补丁版本，遵循语义版本控制术语。
适当的修复，包括安全问题修复，可能会被后沿三个发布分支，具体取决于问题的严重性和可行性。 补丁版本按常规节奏从这些分支中删除，并在需要时增加额外的紧急版本。
2.2 支持的版本偏差
（1）kube-apiserver
在高可用性（HA）集群中， 最新版和最老版的 kube-apiserver 实例版本偏差最多为一个次要版本。
例如：
- 最新的 kube-apiserver 实例处于 1.30 版本
- 其他 kube-apiserver 实例支持 1.30 和 1.29 版本
（2）kubelet
kubelet 版本不能比 kube-apiserver 版本新。
kubelet 可以比 kube-apiserver 低三个次要版本（如果 kubelet < 1.25，则只能比 kube-apiserver 低两个次要版本）。
例如：
- kube-apiserver 处于 1.30 版本
- kubelet 支持 1.30、1.29、1.28 和 1.27 版本
注意：如果 HA 集群中的 kube-apiserver 实例之间存在版本偏差，这会缩小允许的 kubelet 版本范围。
例如：
- kube-apiserver 实例处于 1.30 和 1.29 版本
- kubelet 支持 1.29、1.28 和 1.27 版本， （不支持 1.30 版本，因为这将比 kube-apiserver 1.29 版本的实例新）
（3）kube-proxy
- kube-proxy 不能比 kube-apiserver 新。
- kube-proxy 最多可以比 kube-apiserver 旧三个小版本（kube-proxy < 1.25 最多只能比 kube-apiserver 旧两个小版本）。
- kube-proxy 可能比它旁边运行的 kubelet 实例旧或新最多三个次要版本（kube-proxy < 1.25 最多只能是比它并行运行的 kubelet 实例旧或新的两个次要版本）。
例如：
- kube-apiserver 的版本是 1.30
- kube-proxy 支持的版本是 1.30、 1.29 、1.28 和 1.27
注意：如果在 HA 集群中的 kube-apiserver 实例之间存在版本偏差， 所允许的 kube-proxy 版本范围会被缩小。
例如：
- kube-apiserver 实例的版本是 1.30 和 1.29
- kube-proxy 版本为 1.29、 1.28 和 1.27。（1.30 将不被支持， 因为该版本将比 1.29 的 kube-apiserver 实例更新）
（4）kube-controller-manager、kube-scheduler 和 cloud-controller-manager
kube-controller-manager、kube-scheduler 和 cloud-controller-manager 不能比与它们通信的 kube-apiserver 实例新。 它们应该与 kube-apiserver 次要版本相匹配，但可能最多旧一个次要版本（允许实时升级）。
例如：
- kube-apiserver 处于 1.30 版本
- kube-controller-manager、kube-scheduler 和 cloud-controller-manager 支持 1.30 和 1.29 版本
注意：
如果 HA 集群中的 kube-apiserver 实例之间存在版本偏差， 并且这些组件可以与集群中的任何 kube-apiserver 实例通信（例如，通过负载均衡器），这会缩小这些组件所允许的版本范围。例如：
- kube-apiserver 实例处于 1.30 和 1.29 版本
- kube-controller-manager、kube-scheduler 和 cloud-controller-manager 与可以路由到任何 kube-apiserver 实例的负载均衡器通信
- kube-controller-manager、kube-scheduler 和 cloud-controller-manager 支持 1.29 版本（不支持 1.30 版本，因为它比 1.29 版本的 kube-apiserver 实例新）
（5）kubectl
kubectl 在 kube-apiserver 的一个次要版本（较旧或较新）中支持。
例如：
- kube-apiserver 处于 1.30 版本
- kubectl 支持 1.31、1.30 和 1.29 版本
注意：
如果 HA 集群中的 kube-apiserver 实例之间存在版本偏差，这会缩小支持的 kubectl 版本范围。
例如：
- kube-apiserver 实例处于 1.30 和 1.29 版本
- kubectl 支持 1.30 和 1.29 版本（其他版本将与 kube-apiserver 组件之一相差不止一个的次要版本）
3、Kubernetes现状
自项目初期以来，项目在技术能力、使用率和贡献方面取得了巨大的增长。 项目仍在积极努力改进并更好地为用户服务。
在即将发布的 1.31 版本中，该项目将庆祝一个重要的长期项目的完成：移除内部云提供商代码。在这个 Kubernetes 历史上最大的迁移中，大约删除了 150 万行代码，将核心组件的二进制文件大小减小了约 40%。在项目早期，很明显可扩展性是成功的关键。 然而，如何实现这种可扩展性并不总是很清楚。此次迁移从核心 Kubernetes 代码库中删除了各种特定于供应商的功能。 现在，特定于供应商的功能可以通过其他可插拔的扩展功能或模式更好地提供，例如自定义资源定义（CRD） 或 Gateway API 等 API 标准。 Kubernetes 在为其庞大的用户群体提供服务时也面临着新的挑战，社区正在相应地进行调整。其中一个例子是将镜像托管迁移到新的、由社区拥有的 registry.k8s.io。为用户提供预编译二进制镜像的出口带宽和成本已经变得非常巨大。这一新的仓库变更使社区能够以更具成本效益和性能高效的方式继续提供这些便利的镜像。 请务必查看此博客文章并更新你必须使用 registry.k8s.io 仓库的任何自动化设施！
4、Kubernetes 的未来
十年过去了，Kubernetes 的未来依然光明。社区正在优先考虑改进用户体验和增强项目可持续性的变革。 应用程序开发的世界不断演变，Kubernetes 正准备随之变化。
2024 年，人工智能的进展将一种曾经小众的工作负载类型变成了一种非常重要的工作负载类型。 分布式计算和工作负载调度一直与人工智能、机器学习和高性能计算工作负载的资源密集需求密切相关。 贡献者们密切关注新开发的工作负载的需求以及 Kubernetes 如何为它们提供最佳服务。新成立的 Serving 工作组 就是社区组织来解决这些工作负载需求的一个例子。未来几年可能会看到 Kubernetes 在管理各种类型的硬件以及管理跨硬件运行的大型批处理工作负载的调度能力方面的改进。
Kubernetes 周围的生态系统将继续发展壮大。未来，为了保持项目的可持续性， 像内部供应商代码的迁移和仓库变更这样的举措将变得更加重要。
参考：版本偏差策略
