KLTS 正式发布

我们很高兴宣布 KLTS 开源项目正式上线了。KLTS 适用于企业用户,可以直接用于生产环境。在 Kubernetes 社区停止维护某个版本后,KLTS 将继续提供两到三年的维护,主要包括修补 CVE 漏洞和较为严重的 bug。

KLTS 从提出思路、代码整理、构建加速通道、建设网站,到最后发布上线,共用了 2 个多月时间。我们的目的是分享和交流,分享使人快乐,交流让人进步。

为什么会有 KLTS 这个开源项目呢?是因为 Kubernetes 官方社区仅维护最新的 3 - 4 个版本,而许多实际生产环境采用了以前的旧版本,如果贸然升级到新版本,容易引发生产故障。

我们就遇到过这样一个案例。

升级难题

2021 年 7 月份,某个银行客户将 Kubernetes 1.11 直接升级到 1.18,升级后进行业务系统压力测试时,生产环境出现严重故障。

该银行客户管理层和我们公司领导都非常重视,立即组织专家们加班加点复现问题,对两个跨省的大生产集群逐节点排查,反复进行三次尝试,终于找对了问题的方向,成功复现故障发生的临界点。

多番测试后,最终确定是新老集群节点迁移期间因更换 Master 节点导致新集群网络出现大规模故障,旧 Master 支持的某些功能在升级后没有得到很好地支持。

事后银行高管反馈说:“之所以需要升级旧系统,是因为 Kubernetes 1.11 的某个安全漏洞,但是万万没想到升级后会出现这种大范围的故障。”

内部反思

发生这样的问题,往往会影响实际的生产业务,引发一系列严重后果。所以这次事件之后,我们内部进行了详细的思考讨论。意识到生产环境中运行的许多旧版本 Kubernetes 并不能贸然升级到新版本,这很容易引发各种各样无法预料的问题,客户也可能因此陷于进退两难的境地。

为了提高客户满意度,我们这两年来持续维护 Kubernetes 1.10 起的各个版本,解决各种各样的故障问题。经常有同事深夜接到 on-call 售后服务电话,用冷水洗一把脸,就立即开始远程排查,再抬头时天都快亮了。

两年多的日夜奋战,我们修复了许多 bug,解决了数不清的故障。这次事件之后,大家意识到这些维护过的 Kubernetes 版本是很多企业求而不得的数字资产。

团队内部提出一个大胆的建议:“这些版本是否能分享到社区,让更多用户受益?而不仅仅是局限于咱公司范围的客户,这样也能为社区的发展略尽绵薄之力。”

正逢 Kubernetes Community Day (KCD) 大会如火如荼地展开,这一提议得到了团队成员的积极响应。

项目构建

说干就干,首先是从公司代码仓库上扒出历年修复的补丁,依托于 Github 的 CI,恢复测试,构建软件源 (YUM/DEB) 和镜像,建设网站,编写文档。

现已经在 CentOS7 经过了较为充分的测试。

正式发布

2021 年 11 月,金秋送爽,一切准备就绪,KLTS 正式对外发布。我们不求这个开源项目多么大红大紫,只求同事们几年来积累的经验能够为您带来一些帮助,让您少走弯路。

从 1.10 起所有内核都是久经金融政企生产验证的软件,您可以放心下载,经过测试验证后就能直接投入生产环境。

如您有任何意见或疑问,请立即联系我们。