如今，越来越多的应用部署在 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 上部署数据库？

现在，让我们深入了解一下如何使用 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 集群。

原文链接

创作场景

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