Categories
程式開發

Kubernetes 上是否运行数据库,取决于哪些因素?


如今,越来越多的应用部署在 Kubernetes 上的容器中,因此 Kubernetes 也被称为「云端的 Linux」。尽管在应用层(application layer)的容器化有了大量增长,但数据层(data layer)在容器化方面得到的关注并不多。这很正常,因为容器化工作流本来就需要足够的弹性,才能应对重启、扩展、虚拟化和其他限制。所以处理数据库的可持久化、对应用程序其他层的高可用性和数据库的冗余等方面,有非常具体的要求。这就使得数据库在分布式环境中运行起来很有挑战性。

然而,数据层得到更多关注,是因为很多开发者想要像处理 应用层技术栈一样,处理数据层基础架构。运维人员希望使用的同样的工具来运维数据库和应用程序,而且数据层和应用层能达到相同的收益:跨不同环境的快速启动和可重复自动完成。在这篇文章中,我们将探讨什么时候,以及哪些类型的数据库可以在 Kubernetes 上有效运行。

在深入探讨 Kubernetes 上运行数据库的注意事项之前,我们先简单回顾一下 Google Cloud 平台(GCP)上运行数据库都有哪些选项,以及这些数据库的最佳用法。

  • 完全托管的数据库。包括 Cloud Spanner、Cloud Bigtable 和 Cloud SQL 等。这些都是低运维成本的选则,因为 Google Cloud 会承担很多日常维护的工作,如备份、补丁和扩展等。开发者或运维人员无需人为干预,只要创建一个数据库,构建自己的 APP,然后交给 Google Cloud 进行扩展。这也意味着你可能无法使用到自己想要的数据库版本、扩展或某种类型的数据库。

  • 在虚拟机上自行操作的数据库。也可称为「全运维选项」,构建数据库、扩展数据库、管理可靠性、配置备份等通通需要自行设定。这虽然工程量巨大,但所有的功能和数据库类型的选择都在自己的掌握之中。

  • 在 Kubernetes 上运行的数据库。在Kubernetes上运行数据库更接近于全运维选项,但是可以从 Kubernetes 提供的自动化功能中,享受一些好处,以支持数据库应用程序的运行。话虽如此,但需要记住的是,Pods(数据库应用容器)是瞬时性的,所以数据库应用重启或故障切换的可能性较大。此外,由于容器化后增加了抽象功能,一些数据库管理任务,如备份、缩放、调优等,都是不一样的。

在 Kubernetes 上运行数据库的技巧

如果选择走 Kubernetes 路线,你需要思考运行哪些数据库,以及当通盘考虑前文讲到权衡时数据库运行状况。由于Pods至关重要,因此发生故障转移事件的可能性,比传统部署或完全托管的数据库要高。如果这个数据库内置支持分片(sharding)、故障选举(failover election)和复制等设计(例如 ElasticSearch、Cassandra 或 MongoDB),那么在 Kubernetes 上运行会更简单。一些开源项目提供自定义资源和控制器,来帮助管理容器化的数据库。

接下来,考虑数据库在 应用 和业务的上下游中起到的作用。存储更多临时的和缓存层的数据库更适合 Kubernetes。这种类型的数据层通常在应用中更有弹性,整体体验更好。

最后,确保你了解数据库中可用的复制模式。异步传输模式可能会出现数据丢失,因为数据库事务(transaction)可能会被提交到主要数据库,而不会提交到次要数据库。因此,一定要明确是否会产生数据丢失,以及在自己的应用程序中,有多少数据丢失是可以接受的。

在评估了以上这些方面后,你最终会得到一个类似于这样的决策树。
Kubernetes 上是否运行数据库,取决于哪些因素? 1

如何在 Kubernetes 上部署数据库?

现在,让我们深入了解一下如何使用 StatefulSets 在 Kubernetes 上部署数据库。借助StatefulSet,你的数据可以存储在 Persistent Volume 上,将数据库应用程序与持久化存储解耦,因此当重新创建一个pod(如数据库应用程序)时,所有的数据依然存在。此外,当在 StatefulSet 中重新创建一个 pod 时,它将保持相同的名称,所以你会有一个一致的端点来连接。持久数据和一致的命名是 StatefulSets 最大的两个特点。你可以查看 Kubernetes 文档了解更多细节。

如果你要运行一个不完全适合 Kubernetes 承载的数据库类型(如 MySQL 或PostgreSQL),可以考虑使用 Kubernetes Operators或包含其他改进特性的数据库项目,使得数据库适合容器化环境运行。Operator 会帮助你启动这些数据库,并执行数据库维护任务,如备份和复制。特别是对于 MySQL 来说,可以参考 Oracle MySQL Operator 和 Crunchy Data for PostgreSQL。

Operator 借助自定义资源和控制器,通过 Kubernetes API 来暴露 特定操作。例如,使用 Crunchy Data 执行备份,只需执行 pgo backup [cluster_name] 即可。要添加一个 Postgres 副本,使用 pgo scale cluster [cluster_name]。

还有一些其他项目你可能会感兴趣,比如 PostgreSQL 的 Patroni。这些项目进一步用到了 Operator。它们围绕着各自的数据库构建了许多工具,从而可以在 Kubernetes 内部进行操作。可能包括的补充功能是,如分片、主从选举,以及故障转移功能,这些功能都是在 Kubernetes 中成功部署 MySQL 或 PostgreSQL 所需的。。

虽然在Kubernetes中运行数据库获得了越来越多的关注,但它远不是一门精确的科学。在这个领域还有很多工作要做,随着技术和工具的发展,在 Kubernetes 中运行数据库将成为常态。

如果你准备好了,可以访问 GCP Marketplace,它提供了易于部署的 SaaS、虚拟机和容器化数据库解决方案和 Operators,可以在任何地方部署到 GCP 或 Kubernetes 集群。

原文链接