KubeBlocks 研发轶事之 addon 抽象

发布时间:2024年01月22日

作者介绍
张云杨,前阿里云数据库产品负责人,2016-2019 年任阿里云数据库产品总监,负责 RDS、PolarDB、Redis、MongoDB 等核心产品。目前作者就职于云猿生数据,主要负责云原生数据控制面 KubeBlocks 和 Serverless MySQL 产品。欢迎云计算或数据库行业从业者加微信交流。

作者微信:realzyy

许多年之后,面对研发同事的口若悬河,我都将会想起,Tony 跟我解释什么是 addon 的那个遥远的上午。

Tony 是一个美籍华裔 Infra 工程师,常年混迹于 KubeCon 和 HackerNews,痴迷于新的产品技术、健身以及布道。在他的个人主页上,Tony 是这样描述自己的:长期主义者,喜欢仔细思考选择最优解,喜欢学习新东西,保持客观。如果没有后面的故事,恐怕我永远也无法注意到他描述自己的另外一段话:概括能力过于跳跃,handwriting disorder。

在北京出差的某个早上,Tony 的头像意外地闪烁起来。一般来说,产品经理不太会引起 Tony 的兴趣,虽然在同一个地区但是双方的上班时间存在时差,并不支持淋漓尽致的输出。毕竟,高端的喷子都要求极低的延迟。好奇的我没管住该死的手,让他关注到了飞书消息的“已读”状态。在简单寒暄两句后,Tony 兴奋地给出了一个文档链接,并要求评审。“Addon KubeBlocks 控制平面可选特性开关功能”,标题的 handwriting disorder 没难住我,我知道他想写的是“KubeBlocks Addon 定义以及功能提议”。但愿里面内容还行,我向产品之父苏杰祷告。

天气开始热起来了,我看他打了杯冰美式,问到:“什么是 addon?”

Tony 不客气地问:“你是不是没看我的文档?”

“那个文档没写明白”,我心里这样想,但是嘴上很怂:“我没看懂。对于一个数据库控制平面而言,可选特性的意义是变化的。比如说新的引擎版本,或者更细粒度的备份功能,或者更丰富的监控指标,对用户而言都是特性上面的变化。如果 addon 的定义是可选特性,那哪些特性是必选的,哪些又是可选的呢?”

“比如,负载均衡、监控系统、存储接口都是可选的,它们都是 addon。”

“如果我在阿里云上面运行 KubeBlocks,ACK 提供的存储接口是必选的,那它就不是 addon。而在亚马逊上面运行 KubeBlocks,EKS 提供的存储接口是可选的,那它又是 addon。按照定义,存储接口到底是不是 addon?”

Tony 放下了咖啡杯。从 Motivation、Goals、Non Goals,到用户故事、使用场景,再到开发和测试计划,那个下午我获得了很多,但是好像也失去了很多。

“不行,我一定要搞明白 addon 是什么。”

这么多聪明的人里面,肯定有谁能解释清楚。我不由自主地瞥了一眼巧克力。我们的 CTO,有着黝黑的皮肤和宜人的性格,就像巧克力一样丝滑且有智慧。

“简单来说,addon 是工作负载(Kubernetes Workload)的一种抽象”,巧克力解释道:“本质是包含 ClusterDefinition、ClusterVersion、Script 和 ConfigMap 等资源的 Helm Chart,比如 KubeBlocks 接入的 OceanBase 就是一种 addon。”

虽然有点像抬杠,但是我脱口而出:“那什么又是抽象呢?”

“在软件工程领域,抽象是指从问题或系统中提取主要特征和行为。通过抽象可以提高重用性和可拓展性,提升理解和研究问题的效率。”

“不愧是精通 ChatGPT 的男人”,我硬着头皮继续问道:“那 addon 作为一种抽象,它解决了什么问题?”

“当你只开发一种数据库服务的时候,每个功能都是独特的;当你开发了一百种数据库服务的时候,99% 的功能都是重复的。addon 作为一种抽象,就是找出了这 99% 的功能,以便研发团队集中力量提高它们的质量。这样大家都能过上幸福的生活。”

巧克力已经回到座位上了。我还在回味这个饼是甜的还是咸的,感觉吃到了但是又有点饿。

我下定决心去打扰珊博。珊博是坡县国立大学数据库科班出身,获得了学术大佬的真传。Tony 的文档让人形神俱灭,而珊博的文档旁征博引,有种饱腹感。我读了她的 Addon Tutorials 系列,4 万字抄一遍刚好水一篇硕士毕业论文。别看我,我没有。

“如果开发者在 KubeBlocks 上面没有找到想要的数据库引擎,他们可以选择自己动手做一个 addon,part time 参与的话 10 个工作日内可以完成”,珊博推了推眼镜:“addon 的制作分为三步。一是设计数据库集群的部署拓扑结构,二是设计数据库集群的参数模版,三是增加 addon yaml 配置文件。具体来说,……”

我仿佛看见了大象缓缓走进冰箱,赶紧示意珊博暂停:“addon 好像是 KubeBlocks 0.5 就已经具备的功能,为什么这两天发布的 0.8 里面感觉它有点若隐若现?”

“这是个好问题”,珊博又推了推眼镜:“KubeBlocks 0.8 把 addon 代码拆了出来,这样就能支持两边按不同节奏来发布了。比如说,KubeBlocks 的发布节奏是 1.5 个月一个大版本,如果用户想要接入一个新的数据库,他随时都可以写个新的 addon 并发布出来,再也不需要等 KubeBlocks 更新版本了。当然,还有其它的好处,比如说……”

吃不了抽象的苦,就要吃具象的苦,不争气的口水从眼角流下来。

Addon:一种高效、开放的拓展机制

上面这几个虚拟的小故事,是真真正正发生在 KubeBlocks 的研发过程中的。过程没有那么魔幻现实主义,但是讨论的激烈程度远胜于文章,毕竟研发同学们的奇思妙想只有经过深入的拷问,才可能真正变成产品的特性。规划赶不上变化的事情比比皆是,但也还是要在这不确定性中寻求确定性,正如在虚无缥缈的抽象理念中寻求具象的事实般重要。

所以,addon 到底是什么?我们最终达成了一个共识:

addon 是一种高效的拓展机制。通过 KubeBlocks Addon,开发者可以在 10 个工作日内添加一种新的数据库引擎到 KubeBlocks 中,并获得该数据库引擎特有的基础管理功能,包括但不限于生命周期管理、数据备份恢复、指标和日志采集等。

同时,addon 也是一种开放的拓展机制,是 KubeBlocks 与其它数据控制面软件的重要区别。我们尝试通过 addon 机制,定义数据控制面的接入标准,降低 Kubernetes 支持新数据库引擎的难度,加速数据库容器化的进程,并以此为基础推动云原生平台的应用深度与广度。这件事很难,但是做成了很有意义。

在具体实现上,addon 体现为存储在 Git 仓库里面的 helm chart 安装包,里面包含了支持一个数据库引擎所需要的拓扑信息、配置信息和操作脚本。KubeBlocks 官方社区提供的所有 addon helm chart 源码都可以在 https://github.com/apecloud/kubeblocks-addons 找到,安装包则全部放在 https://github.com/apecloud/helm-charts 的发布里面。开发者也可以根据需要,编写新的 helm chart 或者改写存量的 helm chart,提升 KubeBlocks 管理的数据库引擎种类和体验。

KubeBlocks 0.8 将存量数据库引擎的 helm chart 从 KubeBlocks repo 分离出来,并采取了 Apache v2 的授权模式,预期可以带来如下收益:

  • 数据库引擎种类和版本迭代,与 KubeBlocks 自身版本的迭代解绑。开发者不需要关注 KubeBlocks 的发版周期,随时可以接入新的数据库引擎或者版本,也方便终端用户在存量 KubeBlocks 集群上测试新的数据库引擎/版本。
  • 数据库引擎的定义实现了多版本,降低了 addon 升级可能造成的故障风险。数据库引擎的定义是一种“元数据”,对元数据的“更新”操作实际上会影响所有存量数据库集群。KubeBlocks 0.8 将元数据的“更新”操作变成了“新增”操作,让升级过程变得更加可控。

通过 addon 机制,KubeBlocks 社区已经支持了几十种数据库引擎,其中不乏一些优秀的国产数据库,比如 OceanBase、PolarDB-X、OpenGauss。如果您是数据库厂商,正在头疼如何满足客户提出的“云原生”诉求,可以尝试使用 KubeBlocks 快速解决这个问题。如果发现不能满足需求的地方,欢迎您联系我们提供帮助。

开源合作:https://github.com/apecloud/kubeblocks

商业合作:marcom@apecloud.com

本文由mdnice多平台发布

文章来源:https://blog.csdn.net/baidu_41642080/article/details/135755269
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。