K8s社区不维护的往期版本怎么办?

语言: CN / TW / HK

理想主义的花,

最终会盛开在浪漫主义的地里。

我们很高兴宣布 KLTS (http://klts.io/) 开源项目正式上线了。

KLTS 全称为 Kubernetes Long Term Support,主要使命是 为 Kubernetes 早期版本提供长期免费的维护支持

KLTS 从提出思路、数据源整理、网站建设,到最后发布上线,共用了 2 个多月时间。整个项目都是「DaoCloud 道客」的相关技术同事,自发组织,用工作之余的时间完成的。

在埋头干活的同时,不忘仰望星辰大海。理想主义的花,最终会盛开在浪漫主义的地里。

欢迎广大的开发者和我们一起共赴,这一程充满浪漫主义的,理想的实现之旅。在路上一起畅聊开源技术,共同探讨和解决相关的问题。

理想之花的由来:为什么会有 KLTS 这个开源项目呢?

01

浪漫之始

理想照进现实

在所有理想的想象中,新的肯定都是更好的。但是在现实中,往往不是这样。实际生产中,大多数企业往往会选择采用,早期的 Kubernetes 版本管控集群。

首先,升级频率高会带来变更风险,每次升级必须进行充分验证。特别是金融行业的平台层变更周期通常比较长,因为一旦升级后的新版本存在 bug,就需要被迫回滚或快速响应升级至更新的版本,这样会造成不必要的成本支出。

其次,Kubernetes 升级后部分功能的替代方案还没有完全生产就绪,在生产环境中常会出现不兼容的状况。

最后,Kubernetes 社区仅支持小版本 +1 升级,不支持跨版本升级,因为跨版本升级经常会出现一些不可控的因素,造成更大的生产问题。

所以大多数企业的选择是沿用早期版本,不会贸然升级。但 Kubernetes 社区只维护最新的 3 到 4 个版本,然而企业实际在使用的都是早于这些的版本。

在企业使用这些早期版本的时候,如何才能免受社区不定时发现的,CVE 漏洞和 bug 的袭扰呢?这就是 KLTS 的价值所在!KLTS 会 对Kubernetes 社区停止维护的早期版本,提供长达 3 年的免费维护支持,积极修复早期版本的 CVE 安全漏洞和重大 bug。

这就是 KLTS 想要为使用早期版本的企业,培植和呵护的理想之花。

02

守护遗失之地

保障生产稳定

在维护的范围中, KLTS 会优先修复中高级别的 CVE,其次会修复重大 Bug

这是因为,一些高优先级的 CVE 或严重 Bug ,在生产环境中会造成较大的安全隐患,CVE 安全问题是集群的生命线。因此,KLTS 会优先修复中高级别的 CVE,其次会修复重大 Bug,确保生产环境稳定运行。

当 Kubernetes 社区发现可能影响生产的 CVE 新漏洞或 bug,受到影响的可能不止社区正在维护的版本,还有之前已经停止维护,但是仍有企业使用的版本,KLTS 团队维护的正是这些社区放弃维护的版本。

以 2021 年 1 月发现的 CVE-2021-3121 安全漏洞为例,CVSS 危急分数高达 7.5。但截止 2021 年 9 月 Kubernetes 社区:  

  • 仅修复了 4 个版本:1.18、1.19、1.20、1.21

  • 宣称“所有早期版本均有这个安全漏洞,建议用户立即停止使用早期版本”

  • 因为之前的版本已经停止维护,拒绝修复早期版本漏洞的要求

KLTS 面对这一现状,自发修复了深受 CVE-2021-3121 安全漏洞影响的 ,其他 8 个早期版本:

v1.17.17、v1.16.15、v1.15.12、v1.14.10、v1.13.12、v1.12.10、v1.11.10、v1.10.13

03

三年之保

以号为证

在这三年维护期内,我们对从 1.10.13 起的每一个版本,每提供一次免费维护,每一个Kubernetes 版本号,都有一个相对应的 KLTS 提供的补丁版本号。企业可以通过这样的补丁号,可以找到对应的修复版本。

KLTS 维护的早期版本号,是从 1.10.13 起到 Kubernetes 社区最新停止维护的版本号。 例如,社区发布的最新 Kubernetes 版本为 x.y.n,其中 x 是大版本号,y 是小版本号,n 是补丁版本号 (补丁版本号代表社区维护过程中产生的补丁数,初始为 0),区别 KLTS 维护的版本和 Kubernetes 社区维护版,主要是以 y 的变化为准。

因此,根据社区版本维护声明,如果社区仅维护最近的三个版本,版本号即为 x.y、x.(y-1)、x.(y-2),而 KLTS 维护的则是从 1.10 起,到 x.(y-3) 的近十个早期版本,如下图所示。

对应每个维护的版本,KLTS 每维护一次,就会有一个对应的补丁号。

示例:Kubernetes 社区很早以前就停止维护的一个版本,版本号为 1.10.13,KLTS 在三年内提供的补丁版本,版本号通常在此基础上加上 lts1、lts2 … ltsn 表示。例如,1.10.13 第一个补丁版本号为 1.10.13 lts1,第二个补丁版本号为 1.10.13 lts2,第 n 个补丁版本号为 1.10.13 ltsn。

如上图所示,Kubernetes 社区对某个版本的维护周期通常是一年左右,而 KLTS 则是在接下来的三年内提供长期维护,直至代码无法兼容,才会将相应版本淘汰。

04

欢迎共同培育

结出硕果

辛勤的耕耘,最终收获的是盛开的美丽花朵。经过开发者精心的维护支持, KLTS 为这些使用早期版本的企业带来了最终的成果:

三年维护期: Kubernetes 社区对每个版本提供一年左右的维护,而 KLTS 接下来会为该版本提供长达三年的持续维护。

安全稳定: 小版本升级更安全,兼容性高;渐进式升级稳定性更好;从 1.10 起所有内核都是久经金融政企生产验证的软件,可以放心下载,经过测试验证后就能直接投入生产环境。

易于安装: 结合国内镜像加速,原生支持 Kubeadm,支持 CentOS、Ubuntu、openSUSE,还提供了一键安装脚本。

公开透明: 在 GitHub 托管的开源项目,全流程公开。

全链路规划: 后续会添加 Containerd 及其他组件的长期维护。

KLTS 的路线图正在制定之中,目前路线图计划短期实现信创支持,长期实现麒麟系统支持等多方位的重要能力。

在此,向广大的开发者,再次发出邀请,如果您觉得 KLTS 团队的付出有价值,让您值得信赖,欢迎任何开发者加入 KLTS 社区交流并贡献,期待您的任何意见、建议或解决方案。

加入 KLTS's Slack

http://join.slack.com/t/klts/shared_invite/zt-wutp4tk7-ITXZc8EUUiuxbM_5mh1qXA

  K 8 s