K8s社区不维护的往期版本怎么办?
“
理想主义的花,
最终会盛开在浪漫主义的地里。
我们很高兴宣布 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 学 习 交 流 群 , 与 大 佬 共 卷 !
扫 码 加 我 微 信 , 进 群 和 大 佬 们 零 距 离
- GitLab 15.0来了!新增容器扫描功能
- 2022 年 7 大软件开发趋势:DevSecOps...
- 27 年 IE 终落幕,再见 IE!
- 云原生思想
- IT专业人士和DevOps对低代码说不
- 反掩码和通配符,傻傻分不清?
- Google SRE团队的关键人物分享:10多年ML系统SRE运维经验
- 几个简单易懂的 OSPF 实验
- 20个云计算术语和定义
- 爽到爆!阿里腾讯都在用的API管理神器:Apifox
- 提升Linux技能的13个必杀技!
- 过年时,把舅舅家 WiFi 搞好了
- Google开源App Engine标准Java Runtime
- 53 张图详解防火墙的 55 个知识点
- K8s社区不维护的往期版本怎么办?
- 微服务故障排除方面的最佳实践
- Colima:Docker Desktop for Mac 的免费替代品,轻松管理容器和 K8s(支持 M1 芯片)
- K8s集群如何保证高可用?来自B站、大疆、网易的最佳实践
- 图解三层交换机:局域网都用它来组网
- 调查报告显示:大数据使用 Kubernetes得到广泛采用,但监控和调优是两大难题!