视频
Helm 工具和 Helm 图表的介绍
了解更多信息
速度的未来即将来到您所在城市的活动。
加入我们在 Redis 发布会
分享
数据库供应商需要在云原生社区中更加活跃 - 特别是为了解决与 Kubernetes 和有状态应用程序相关的扩展问题。
容器化和 Kubernetes 继续彻底改变云原生应用程序的开发和部署，主要是因为这些技术提供了增强的可扩展性、可移植性和灵活性。但是，将数据库集成到这些环境中会带来一系列新的挑战。
我想说这些挑战正在克服。但是，在上周参加了在阿姆斯特丹举行的 KubeCon + CloudNativeCon Europe 2023 之后，我不得不承认，我们距离解决这些问题还有很长的路要走。
数据库/容器问题归结为关于 数据持久性和存储 的问题。容器是短暂的。它们很容易创建、销毁和替换。虽然这对 无状态应用程序 很有利，但它对依赖于数据库的有状态应用程序提出了重大挑战，这些应用程序反过来需要持久性存储来维护数据完整性。
的确，Kubernetes 提供了 持久卷 (PV) 和持久卷声明 (PVC) 来为有状态应用程序提供 持久性存储 解决方案。PV 和 PVC 允许数据库即使在运行数据库的容器被替换或销毁的情况下也能保留其数据。
但这还不够。这个问题还没有解决。
“我认为这是目前需要解决的最重要的问题之一，”Veritas 高级杰出工程师 Petter Sveum 在 KubeCon 小组讨论中表示。“市场上有许多不同的解决方案，但数据库规模仍然是一个真正的问题。”
“您有更大的工作负载被驱动到 Kubernetes 中，跨越多个命名空间，甚至跨越多个站点，拥有数 TB 的卷，”Sveum 指出。“解决它需要在传统架构中高度重视细节。那么为什么 Kubernetes 会有所不同呢？”
相反，Sveum 遇到了几个非常惊讶的团队。他们说，‘哦，我 10 TB 的卷无法在我预期的时限内进行快照！’他们没有意识到‘它并不快，对吧？它需要几分钟、几小时。’”
思科工程副总裁 Guillaume Savage de Saint Marc 同意 Sveum 的评估。“在云原生环境中处理需要来自有状态和无服务器服务的组合资源的边缘计算很尴尬。”
数据库和 云原生 计算方面已经取得了进展。但华为首席开源联络官 Xudong Ren 表示，最重要的是，“没有成熟的解决方案。”
每个人都同意 DBMS 供应商需要在 Kubernetes 上做更多的事情。
“我们仍然依赖于传统的基础设施组件，而不是投资将其移植到 Kubernetes，”Sveum 说。在他看来，DBMS 仍然存在于虚拟机 (VM) 和服务器中，并且根据需要从 Kubernetes 编排的容器中调用。他断言，我们需要在 DBMS、容器和 Kubernetes 之间进行更多更好的集成。
这并没有阻止公司在容器中运行数据库。根据 Data on Kubernetes (DoK) 社区，许多组织已经通过 Kubernetes 运算符 运行数据服务 - 使用自定义资源来管理应用程序及其组件的软件扩展。理想情况下，运算符将现实世界运维团队的知识和专业知识封装起来，并将其编码到软件中。
注意“自定义”这个不祥的词。在 Kubernetes 上使用数据的最大问题是缺乏与现有工具的集成。如 DoK 报告 所述，“在 Kubernetes 上运行数据的最佳实践仍然很少。”
DoK 主任兼 Constantia 首席执行官 Melisa Logan 在 KubeCon DoK 小组中总结道。“为了处理 Kubernetes 上数据工作负载的第 2 天运维，组织严重依赖于运算符。但它们带来了若干挑战，包括缺乏与现有工具的集成；缺乏与其堆栈其余部分的互操作性；质量参差不齐；以及缺乏标准化。”
然而，根据 2022 年 Data on Kubernetes 报告，大多数人使用至少 20 个运算符。“对于那些评估其选项的人来说，选择进一步增加了挑战；运算符的数量不断增加，Operator Hub 目前列出了 270 多个，”Logan 说。“如果没有运算符标准，最终用户如何才能评估每个运算符，以了解它是否满足他们的需求？”显然，还需要做很多工作。
现在，如果只有更多的人在 Kubernetes 和数据库方面都合格！这是 Kubernetes 用户经常听到的抱怨，不仅仅来自那些使用数据库的人。Kubernetes 专业人员不够用，更不用说那些熟悉 Kubernetes 的 DBA 了。
正如 Sveum 所说，“我们确实缺乏了解系统和基础设施的人才，他们如何真正执行以及如何利用自动化平台以及 Kubernetes 等堆栈。”
我们需要能够成为开发团队与提出宏伟请求并期望平台交付的团队之间的桥梁的人。
这并不是说 Kubecon 没有数据库新闻。有一些公告。例如，思科推出了一项新的开源项目，VMClarity，用于在云原生环境中保护 VM。VM 当然可以托管容器和 DBMS。
或者，一些数据库新闻的实施范围很窄。例如，Fermyon Technologies 通过其 Fermyon Cloud Key Value Store 添加了本地有状态存储能力。有了它，用户可以将非关系型数据持久化到键值中，这些键值可以通过 WebAssembly 框架 Spin 为无服务器应用程序提供服务。开发人员可以对 Redis、PostgreSQL 或 MySQL 等 DBMS 进行看似普通的 API 调用。当然，这只在 Fermyon 生态系统中有效，但这仍然是向前迈出的一步。
总而言之，我从 KubeCon 中得到的信息是，DBMS 和 Kubernetes 方面还有更多工作要做 - 还要做很多工作。是的，您今天可以使用有状态工作负载和云原生计算来做一些有用的事情。但这需要自定义编程，这种编程的可扩展性不强。弥合这一差距需要云原生和 DBMS 行业和社区付出更多努力。
正如我们在 在 Kubernetes 上运行 Redis 中解释的那样，Redis 处于利用容器生态系统的数据库公司的最前沿。
