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