KubeCon社区专家提出：在K8s上运行数据库将成为未来

访谈介绍

在4月的KubeCon Europe 2023盛会上，DoKC的主席Melissa Logan采访了VMWare的XingYing、Percona的Sergey、和Ongres的Alvaro（三位均为DoK Operator SIG成员）。在访谈中，Alvaro表示 “未来在Kubernetes上运行数据库将成为默认选择” 。

开始之前，先说说DoKC（Data on Kubernetes Community）这个组织。DoKC成立于2019年底，组织者看到越来越多的有状态负载运行在K8s上，很多数据库相关的Operator也取得了成功，大家意识到需要分享在K8s上构建和操作以数据为中心应用程序的最佳实践。DoKC应运而生。

经过4年的发展，这个组织也越来越庞大，知名度也越来越高。Red Hat、Google、Rancher Labs等知名企业都在DoKC中发挥着重要的作用，分享数据工作负载领域的专业知识和经验。从2021年开始，他们就在KubeCon + CloudNativeCon大会上组织了一个叫做DoKC Day的活动。一些知名公司，如Percona、Datastax、Altinity等，都曾在DoKC Day上参与过主题演讲或讨论。

在K8s上运行数据库是一个新的趋势

本次访谈的三位专家表示，在Day-2运维方面，虽然数据库Operator已经有了很好的表现，但也面临着一些挑战。很多终端用户都吐槽Operator存在交互操作性不足、与现有工具集成不畅以及质量参差不齐的问题。实际上，这些槽点都源于一个根本问题：缺乏统一标准，导致用户不知道如何去评估Operator的好坏。

根据2022年的调查数据，很多组织都使用了至少20个Operator，而且希望这些 Operator能以极高的水准工作。 以Operator框架能力模型（级别 I-V）作为参考，这些组织希望数据库Operator的成熟度能达到 IV-V 级别。

除此之外，安全性和易用性在讨论中也是绝对的焦点。与会专家们热烈讨论了数据库 Operator提供的安全功能，及其如何应对安全漏洞。与其他无状态服务的Operator相比，数据库Operator的安全保障要分两个维度，首先是K8s维度的安全体系，然后是数据库维度的安全保障。在安全性和易用性之间找到平衡，确实让专家们也感到头疼。

尽管挑战很大，专家们还是看到了一个明显的趋势——用户渴望在K8s上运行数据库。 现在遇到的问题，很多都可以通过自动化进一步解决。

数据库相关 Operator 走向整合与成熟

公有云的灵活性和可扩展性，让企业能够更加敏捷地响应市场需求，却导致了供应商锁定的问题。云厂商的全托管数据库服务在功能和API上存在着差异，更无法与本地的开发环境统一。想要不修改代码的情况下，在任何地方以相同方式运行依赖数据库的应用是一件很困难的事。如何通过K8s解决这个问题，并将数据库Operator更好地集成到DevOps流程中，还有很大研究空间。

另外，大部分公司都不会只用一个数据库，稍微大点的公司就是全家桶。而现在大部分的数据库Operator都是针对单个引擎的。咱上面的调查提到过，跑得快的公司已经用20多个Operator了，再加上数据库这么多引擎的，MySQL、PG、Redis、MongoDB，得，又来五六七八个。谁家的神仙工程师，受得了这种折腾？

因此，关于未来，专家认为这些问题都应该在K8s的数据库Operator中解决。三位嘉宾提出了以下观点：

1. 数据库相关 Operator 走向整合： 由于目前存在众多不同引擎的Operator，用户很难判断哪个是好的或坏的。未来一年可能会看到数据库Operator市场的整合，一些较为成熟和广泛采用的Operator将逐渐脱颖而出。
2. 面向标准化的进展： 虽然数据库的多样性会给标准化带来一定挑战，但由于Operator的碎片化趋势，有必要尝试制定一些标准化的框架和接口，以实现更加统一和相似的用户体验。可能会出现类似K8s存储接口（CSI）的Operator插件框架，通过定义共同的 API 接口，各个Operator可以实现这些共同接口，使用户获得相似的体验。
3. Controller与CRD解耦： 访谈中提到Controller和CRD的组合构成了Operator模式，但目前存在一对一的关系。未来一年可能会出现更多关于将CRD与Controller解耦的讨论。通过标准化和共享CRD，不同Operator可以在实现上有所差异，但用户可以更轻松地在不同Operator之间切换或使用不同Operator的解决方案。
4. 数据库Operator的成熟度提升并得到更广泛应用： 预计未来一年数据库Operator将更加成熟，并得到更广泛的采用。数据库Operator的成熟度提升将使其能够胜任更多的任务，并提供超出用户预期的功能。数据库Operator有望成为云原生技术中的主要运行方式，使用户能够在不同的环境中运行数据库，实现多云、混合云，并避免云厂商的锁定。

关于这些对未来的展望，各位看官同意吗？

总的来说

尽管Operator质量不一并且缺乏功能列表和评估标准，专家们仍然认为在K8s运行有状态负载是一个大的趋势，人家说了，“K8s上运行数据库不仅仅是可行的选择，更应该是默认的选择。”
为了更好支持有状态负载，小猿姐呼唤市面上出现更加可靠安全并统一的数据库Operator。

哦，对了

小猿姐还找到了DoK Operator SIG正在进行的三个项目，欢迎大家参与：

• 与CNCF Storage TAG合作起草的《Database on Kubernetes白皮书》，目前还处于可评审状态，感兴趣的小伙伴可以贡献自己的建议～
• Operator的功能矩阵（OFM），这是一个标准化和厂商中立的功能比较矩阵，目前主要关注数据库Operator。目前正在讨论中，欢迎贡献意见。
• Operator安全性和强化指南（Operator Security and Hardening Guide），旨在定义数据库Operator的安全问题和解决这些问题的最佳实践。

参考

DoK访谈视频链接：Kubernetes Database Operators Landscape

访谈视频中文逐字稿