Kubernetes集群不是在升级，就是在升级的路上。而对于维护K8s集群的团队来说，最担心的莫过于，系统因为K8s升级而引发了服务器大规模崩溃。

想象一下，K8s升级发生在某个晚上，突然某个集群因为强制更新，导致了所有服务器的崩溃，也没有快速的方法来恢复，造成的损失将会有多么大呢？

因此，旧版本的稳定性就会显得尤其重要。那么既然如此，Kubernetes为何不推出一个LTS版本呢？

企业期望稳定性并不是出于保守或惰性，而是太多现实的原因——客户与供应商达成的合同、监管和法定要求、技术风险政策的限制，都在此列。

但为了灵活而生的K8s，似乎在作为基础设施的层面上，并不是一个足够稳重的搭档，它的更新速度非常快，大大超出业务迭代。

即便K8s社区支持的深度和广度足够可靠的支持使用者能从社区类似的问题中找到答案，即便大多数组织能够忍受部署K8s的痛苦，但频繁的升级操作却让许多用户叫苦不迭。

据一位开发者反映，在K8s之上运行GKE升级方案中，经常会导致服务中断数周。对于如何修复或升级控制平面和节点池，给出的默认值选项也非常抽象，集群在不知情下的情况下升级并任意中断服务，更会让人感到恐慌。

不断重写东西，对于中小型团队而言几乎是不可能的。

Kubernetes 遵循“N-2”支持政策（最近的 3 个次要版本获得安全和错误修复）以及“15周”的发布周期。因此，一个版本会支持14个月（12 个月的支持期和 2 个月的升级期）。

如果我们将此与Debian的支持周期进行比较，我们可以看到直接明显的区别。

比如，RedHat就是建立在组织无法经常升级的基础上的，它向用户展示了一些组织可以以何种节奏推出大型变更。

然而，即便是云供应商有能力保持最新，也不会让他们的客户遵守这些极其紧迫的时间窗口。谷歌的GCP 可以接触到许多 Kubernetes 维护人员，且与该项目密切合作，但也没有让客户遵守这些时间表。

AWS 或 Azure 同样也没有这样做。

现实情况是，稳定大于一切。没有人期望公司能够跟上K8s这样的发布节奏。因为跟上节奏的代价很高：

首先，验证集群是否可以升级以及是否安全需要使用第三方工具，或者很好地了解哪些 API 何时被弃用。

其次，在临时环境中进行验证的时间以及维护 Kubernetes 集群升级所需的大量时间，一个明显的问题就出现了。

最后，这些组件和模块需要经过持续的维护和更新，以确保其安全性和稳定性。

因此，通过提供 LTS 版本，可以为用户提供一个稳定的基础，使他们能够在长期内使用 Kubernetes 而不必频繁升级。

没有手动升级过K8s集群的人，自然不知道其中的辛酸，下面粗略的清单。

的确，上述这些并不是什么“造火箭”的技术，而且所有这些都可以自动化，但这仍然需要有人熟练掌握这些版本。最重要的是，它并不比创建一个新集群容易得多。

即便升级充其量只是比创建新集群稍微容易（通常是更困难）一些，团队也会陷入困境，不清楚到底怎样做才是正确的行动方针。然而，鉴于发布速度如此之快，为每个新版本建立一个新集群并将服务迁移到该集群在逻辑上可能确实具有挑战性。

考虑到团队不想使用 K8s版本的 .0，通常是 0.2，这会损失相当长的14个月时间来等待该标准。然后启动新集群并开始将服务迁移到其中。对于大多数团队来说，这涉及大量的重复和资源浪费，因为至少在一段时间内运行的节点数量可能会增加一倍。CI/CD 管道需要修改，文档需要更改，DNS 条目必须交换。

有些情况或许并不是那么困难，但它由于每一个细节都至关重要，即使采用自动化，其中一个步骤的悄然失败，所造成的风险也足以高到令想干人整日提心吊胆。于是，集群似乎就处于不断落后的状态，除非哪天团队被通知：将“跟上升级进度”视为他们给组织带来的“关键价值”。

不少人都有类似的经历：基础团队的集群已经闲置太久，维护者担心它是否还能够进行安全升级。因此为了避免给整个现有系统带来严重的麻烦，通常都会在运行旧集群的前三个月，告诉领导层：“我需要稍微超出预算来启动一个新集群，并逐个命名空间切换到它。”

即便这种流程方式看起来不太温和。

当然，想要永久使用一个版本而不升级，也是不太可能的。因此有人建议，有没有一种可能，K8s可以有一种“死胡同”版本，没有任何升级路径。这个LTS版本提供正式发布后 24 个月的支持，并且Kubernetes团队不会提供到下一个 LTS 的升级。

这种做法似乎更符合目前很多组织的安全升级的现状。这样的话，运维团队的工作流程就变成了运行 24 个月的集群，然后组织需要迁移它们并创建一个新的集群。

而且，这个工作流程有很多意义。首先，定期创建新节点将成为最佳实践，组织可以升级底层 Linux 操作系统和虚拟机管理程序。虽然这个频率显然要短于每两年一升级，但这将是一个很好的检查点。

其次，基础设施的运维团队需要再次审视整个堆栈，从新的 ETCD、新版本的 Ingress 控制器开始，而不是像以往，除非绝对必要，组织很可能不愿意触及所有关键部分。

然后，这种做法可能对于商业产品或OSS工具来说，也是一个不错的切入点。目前不少云厂商都有类似的收费版K8s（托管平台），比如谷歌的GKE（Google Kubernetes Engine）允许用户使用1.24版本584天，1.26版本可以使用572天。而微软Azure的LTS日期更为宽松，从正式发布日期算起为期2年，AWS的EKS则更长，从发布到LTS结束，版本支持的时间约为800天。

K8s社区可以通过提供大量关于LTS版本升级的指导来协助这些产品或工具。而这也不至于令维护人员束缚在升级项目上。

有业内人士认为，K8s（以及相关软件）存在定期引进重大更改的情况，开发者在工作中需要很多的时间精力去完成升级工作。因此，应该提供LTS版本。

许多其他开源软件都提供具有支持多年的LTS版本，例如Ubuntu/Debian 提供5年的LTS版本，NodeJS提供2.5年的支持。还有人认为，即便是2年的支持期对于大型企业而言也不够长。

总结下来，支持派的专家认为，K8s是一个复杂的软件集合，有很多移动部件，继续维护原状来进行测试变得太多棘手，可以说已经达到了大多数人在整个职业生涯中不需要考虑的规模。将如此繁杂的升级工作交给同一波维护人员是不公平的。

在世界各地的托管平台和OSS堆栈间建立一个更nice的中间场地。对于世界各地的 K8s运营商来说，不必处于“繁忙且不安”的不断升级现有集群的状态，这将是一个巨大的好处。

此外，这样还将有利于简化第三方生态系统，从而可以更轻松地针对将存在一段时间的、已知稳定目标进行验证。

同时，这样还会鼓励集群运维员采用更好的工作流程，推动其养成定期创建新集群的习惯，而不是永久保留一个集群升级到天黑，直至刷到“宕机”。

但反对派的观点也不容易忽视：“LTS为运维人员带来了便捷，但也会给开发人员增加潜在的向后移植安全修复的复杂性，而且获得LTS支持的成本同样很高。”

在他们看来，K8s是为了灵活性而生的，本来不适合那些想要使用90年代软件开发流程的大公司。

“经常进行升级和发布，才能确保堆栈中的所有内容都得到充分理解，并且防止让堆栈变得僵化，而且尽早而不是堆积的升级，往往更容易处理。”

针对上述两种观点，一位K8s某个发行版的前开发人员提到了一种折中的看法：“有些客户出于各种原因希望延长支持期限。真正的问题应该是，LTS是否应该留给发行版。”

许多发行版会选择不提供比上游更长期的版本，但会提供一些更商业的产品，这些产品对于客户足够重要且需付费。“如果让Kubernetes作者承担LTS的责任，那么项目速度方面就会牺牲不少。因此还是将LTS留给K8s分销商更合适。”

不可否认，在容器思维盛行的开发范式下，Kubernetes 作为容器编排领域的王者，不管你喜欢还是讨厌，它都已经成为行业广泛采用的标准平台。那么，各位又是如何看待K8s版本升级过快的问题呢？