Kubernetes 目前遵循的是「N-2 支持政策」，这意味着仅 3 个最新的次要版本（N、N-1 和 N-2）会获得安全和错误修复，发布周期则为 15 周。
因此一个 Kubernetes 版本的支持周期通常是 14 个月（12 个月的支持期和 2 个月的升级周期）。如果我们将其与 Debian（许多组织都以其支持周期为基础的操作系统项目）进行比较，就会发现两者之间的直接区别。
![]()
![]()
可以看到，Kubernetes 作为基础设施项目，其迭代周期还是让许多公司无法跟上发布节奏。
而且手动升级 K8s 集群通常需要以下工作：
- 检查所有第三方扩展，例如网络和存储插件
- 升级 etcd（所有实例）
- 升级 kube-apiserver（所有控制平面主机）
- 升级 kube-controller-manager
- 升级 kube-scheduler
- 升级云控制器管理器 cloud controller manager（如果使用的话）
- 升级 kubectl
- 排空每个节点，并更换节点或升级节点，然后读取并监视以确保其继续工作
- 根据清单上的要求运行
kubectl convert
基于这些因素，有人提出：Kubernetes 是否需要提供长期支持版本 (LTS)？
原因如下：
第一，Kubernetes 是一个复杂的容器编排系统，由许多不同的组件和模块组成。这些组件和模块需要经过持续的维护和更新，以确保其安全性和稳定性。通过提供 LTS 版本，可以为用户提供一个稳定的基础，使他们能够在长期内使用 Kubernetes 而不必频繁升级。
其次，许多组织在使用 Kubernetes 时会构建复杂的应用程序和基础架构。这些应用程序和基础架构可能依赖于特定版本的 Kubernetes，并且可能需要进行大量的测试和验证才能在新版本上运行。通过提供 LTS 版本，可以确保这些组织能够在长期内维持其应用程序和基础架构的稳定性，而不必担心由于升级到新版本而导致的不兼容性和故障。
此外，许多组织可能面临着合规性和监管要求。这些要求可能要求他们使用特定版本的软件，并且在一段时间内保持该版本的支持。通过提供 LTS 版本，Kubernetes 可以满足这些合规性和监管要求，使组织能够在其环境中使用 Kubernetes 而不必担心违反规定。
最后，对于那些不具备大规模升级和迁移能力的组织来说，LTS 版本可以提供更长时间的支持和稳定性。这些组织可能没有足够的资源和时间来频繁升级和迁移他们的应用程序和基础架构。通过提供 LTS 版本，Kubernetes 可以帮助这些组织保持其系统的稳定性和可靠性，而不必承担频繁升级的风险和成本。
据了解，k8s 团队正在恢复之前解散的 LTS 工作组。
![]()
目前其邮件列表还没有任何内容：https://groups.google.com/a/kubernetes.io/g/wg-lts
