Kubernetes长期支持迎来巨变：Canonical推出15年LTS保障企业级稳定性

Canonical 宣布，通过其 Ubuntu Pro 与新的 Legacy 附加组件，将为旗下的 Kubernetes 发行版提供长达 15 年 的长期支持 (LTS)。这一举措旨在满足银行、电信等高度监管行业对基础设施超长稳定周期的严苛需求。

此前，Canonical 已在今年 2 月将支持周期延长至 12 年。此次进一步拓展至 15 年，意味着其 Kubernetes 发行版的支持将覆盖至 2040 年，直追大型机系统的维护标准。

具体方案与覆盖范围

此项超长周期支持通过将 Canonical Kubernetes LTS 与 Ubuntu Pro 以及新增的 Legacy 附加组件 相结合来实现。Legacy 组件为 Ubuntu LTS Linux 发行版本身提供了长达 15 年的扩展付费支持。

具体到 Kubernetes，从 1.32 版本开始，MicroK8s、Charmed Kubernetes 和 Canonical Kubernetes 都将获得此扩展支持。该支持包将覆盖 Canonical 所有支持的平台，包括裸金属服务器、主流公有云、MicroCloud、OpenStack 以及 VMware by Broadcom。

Canonical 将此描述为将其在 Ubuntu 上积累的“超过 10 年的定期安全补丁”经验移植到容器编排层。Kubernetes LTS 版本将与 Ubuntu LTS 的发布节奏对齐，每两年发布一次；而常规的 Canonical Kubernetes 版本则会跟随上游约四个月的发布节奏，并提供短期维护。

为何需要如此长的支持周期？

与红帽为 OpenShift 提供 3 年扩展更新支持 (EUS)，或微软 Azure Kubernetes Service (AKS) 提供 2 年、亚马逊 EKS 提供 26 个月支持相比，15 年的周期显得极为突出。

Canonical 指出，这主要是为了弥合快速迭代的云原生、SaaS 及 AI 开发团队与受严格监管的传统行业（如金融、医学影像、电信）之间的鸿沟。前者希望 Kubernetes 作为一个可频繁更新的抽象层，后者则要求其技术栈在 10 至 15 年内保持绝对稳定，同时又能持续获得关键安全补丁。

一个真实的案例是：当一家北欧银行被告知需要每三到四个月更新一次 Kubernetes 时，其反应是“这不可能！”。他们的实际升级流程需要提前六个月准备，每两年才能执行一次。这表明上游约 14 个月的支持窗口与许多企业的实际操作严重脱节。

因此，扩展的 Canonical Kubernetes LTS 被定位为一种解决方案，让企业能够在无需被迫进行持续、破坏性平台重构的前提下，保持其 容器 集群的安全与合规。

技术实现与生命周期管理

Canonical 的生命周期设计遵循一个模式：每个上游 Kubernetes 发布对应一个 Canonical Kubernetes 版本，并将每第六个上游发布指定为 LTS 版本。

对于这些 LTS 版本，客户首先可通过 Ubuntu Pro 获得至少 12 年的 Kubernetes 安全维护，之后可通过 Legacy 附加组件进一步延长，从而为特定部署提供总计长达 15 年的平台支持。

为了平衡“稳定性”与“灵活性”，Canonical 在每个新 LTS 版本发布后，会为旧版 LTS 提供一年的宽限期（期间保持全面支持），以便客户有充足时间规划升级。客户可以选择在 LTS 版本间跳跃升级，或通过中间版本进行过渡。

重要的是，Canonical 并非“重构”Kubernetes，而是对其上游的、符合云原生计算基金会（CNCF）标准的 Kubernetes 进行打包，并整合自身的工具链（如 snaps、charms 和 Cluster API）。这些产品可以以自管理平台形式提供，也可以作为由 Canonical 工程师运营的完全托管服务（例如为欧洲航天局提供的服务）。

此外，此项 LTS 支持还与 Canonical 新发布的启用 FIPS 的 Kubernetes 变体相结合，专门针对联邦政府及其他高合规性工作负载设计，满足其对经过 FIPS 验证的加密模块及 DISA-STIG 等强化指南的要求。

对行业的长期影响

Canonical 通过与 Nvidia、电信公司和 VMware 等合作伙伴协作，维护底层开源组件的一致性，将自身定位为保障从内核、用户空间到 Kubernetes 及 GPU 运算符的长期、一致支持的“组件供应链”。

尽管一个 15 年未经重大变更的技术栈可能使最终的迁移变得异常复杂，但对于电信网络设备等生命周期本身就很长的硬件平台而言，软件的长期稳定性是首要考量。Canonical 也指出，在许多场景下，硬件本身会在软件支持结束前就已达到生命周期终点。

值得注意的是，应合作伙伴要求，Legacy 附加组件的窗口期已从最初的 2 年扩展至 5 年。Canonical 暗示，对于战略客户，总支持寿命未来还可能进一步延长，15 年或许并非最终上限。

显然，Canonical 正押注于：一个能够稳定维护至 2030 年代末的 Kubernetes 发行版，将深刻吸引那些厌倦了“每三个月就要升级一次”的运维痛苦，并追求堪比传统基础设施寿命的容器平台的企业用户。