KubeBlocks 研发轶事之 addon 抽象

作者介绍
张云杨，前阿里云数据库产品负责人，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多平台发布