DaoCloud 道客云原生开源项目 KLTS，全称为 Kubernetes Long Term Support，为 Kubernetes 早期版本提供长期免费的维护支持cherbim3年前发布890DaoCloud 道客的云原生开源项目 KLTS ，全称为 Kubernetes Long Term Support ，主要使命是为 Kubernetes 早期版本提供长期免费的维护支持。KLTS (官网： ) 开源项目已于 2021 年 11 月底正式上线了！KLTS 从提出思路、数据源整理、网站建设，到最后发布上线，共用了 2 个多月时间。整个项目都是「 DaoCloud 道客」的相关技术同事，自发组织，用工作之余的时间完成的。欢迎广大的开发者和我们一起畅聊开源技术，共同探讨和解决相关的问题。查看 KLTS 源码： KLTS 一键安装脚本：curl -sSL | shKLTS 开源项目 PDF 资料下载：前往交流群领取（群二维码这本文最后）为什么会有 KLTS 这个开源项目呢？实际生产中，大多数企业往往会选择采用，早期的 Kubernetes 版本管控集群。首先，升级频率高会带来变更风险，每次升级必须进行充分验证。特别是金融行业的平台层变更周期通常比较长，因为一旦升级后的新版本存在 bug ，就需要被迫回滚或快速响应升级至更新的版本，这样会造成不必要的成本支出。其次，Kubernetes 升级后部分功能的替代方案还没有完全生产就绪，在生产环境中常会出现不兼容的状况。最后，Kubernetes 社区仅支持小版本 +1 升级，不支持跨版本升级，因为跨版本升级经常会出现一些不可控的因素，造成更大的生产问题。所以大多数企业的选择是沿用早期版本，不会贸然升级。但 Kubernetes 社区只维护最新的 3 到 4 个版本，然而企业实际在使用的都是早于这些的版本。在企业使用这些早期版本的时候，如何才能免受社区不定时发现的，CVE 漏洞和 bug 的袭扰呢？这就是 KLTS 的价值所在！ KLTS 会对 Kubernetes 社区停止维护的早期版本，提供长达 3 年的免费维护支持，积极修复早期版本的 CVE 安全漏洞和重大 bug 。KLTS 会优先修复中高级别 CVE ，其次会修复重大 Bug在维护的范围中，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 。KLTS 维护的早期版本号，是从 1.10.13 起到 Kubernetes 社区最新停止维护的版本号在这三年维护期内，我们对从 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 则是在接下来的三年内提供长期维护，直至代码无法兼容，才会将相应版本淘汰。KLTS 为这些使用早期版本的企业带来的最终成果辛勤的耕耘，最终收获的是盛开的美丽花朵。经过开发者精心的维护支持，KLTS 为这些使用早期版本的企业带来了最终的成果：三年维护期：Kubernetes 社区对每个版本提供一年左右的维护，而 KLTS 接下来会为该版本提供长达三年的持续维护。安全稳定：小版本升级更安全，兼容性高；渐进式升级稳定性更好；从 1.10 起所有内核都是久经金融政企生产验证的软件，可以放心下载，经过测试验证后就能直接投入生产环境。易于安装：结合国内镜像加速，原生支持 Kubeadm ，支持 CentOS 、Ubuntu 、openSUSE ，还提供了一键安装脚本。公开透明：在 GitHub 托管的开源项目，全流程公开。全链路规划：后续会添加 Containerd 及其他组件的长期维护。KLTS 的路线图正在制定之中，目前路线图计划短期实现信创支持，长期实现麒麟系统支持等多方位的重要能力。在此，向广大的开发者，再次发出邀请，如果您觉得 KLTS 团队的付出有价值，让您值得信赖，欢迎任何开发者加入 KLTS 社区交流并贡献，期待您的任何意见、建议或解决方案。加入 KLTS’s Slack： 当然你也可以加入道客云原生交流群进行交流互动：
没有回复内容