在 GKE 上规划数据库部署

本页面介绍在 GKE 的容器中运行数据库的最佳做法。您可以使用 Deployment 创建一组 Kubernetes 管理的容器化数据库实例。然后，您将创建一个 Service 来提供独立于任何特定 Pod 的数据库访问权限。即使 Pod 已移至其他节点，Service 也会保持不变。

为了访问数据库实例中的数据，您创建一个 PersistentVolumeClaim (PVC) 资源，并将其提供给您的工作负载。

数据库依靠本地磁盘进行持久保存。在 Kubernetes 集群中以 Service 形式运行并且其数据库文件在 PersistentVolumeClaim 中的数据库与集群的生命周期绑定。如果集群遭到删除，则数据库也会一并被删除。

如果要构建或部署在 GKE 中运行的有状态应用，请考虑对数据库实例使用以下部署选项之一：

  • 全代管式数据库：代管式数据库（例如 Cloud SQL 或 Cloud Spanner）可提供减少的运维开销，并且针对 Google Cloud 基础架构进行了优化。与直接在 Kubernetes 中部署的数据库相比，代管式数据库需要的维护和运营工作量更少。
  • Kubernetes 应用：您可以在 GKE 集群上部署和运行数据库实例（例如 MySQL 或 PostgreSQL）。

在 GKE 上部署数据库的注意事项

考虑到您的业务目标和限制条件，上述每种方案各有利弊。请使用下表确定在 GKE 上的部署数据库是否适合您。

考虑因素 说明
数据库独立性 PersistentVolumeClaim 的生命周期与对应的 GKE 集群相关联。如果您不希望数据库生命周期依赖于特定的 GKE 集群，请考虑将数据库作为代管式数据库或虚拟机实例分开。
使用 GKE 进行扩缩

纵向扩缩：您可以将 Pod 请求配置为自动扩缩。但是，当 Pod 通过纵向 Pod 自动扩缩进行纵向扩容时，您必须确保数据库应用可以应对中断。

横向扩缩：您的数据库可以通过添加副本来横向扩缩读取或写入。数据库是否支持横向扩缩取决于它是具有单 Writer 架构还是多 Writer 架构。如需使用横向扩缩，除了在副本数量方面纵向扩容之外，您可能还需要更新数据库配置。
GKE 开销

在 Autopilot 集群上，您无需为资源预留付费，只需为资源请求付费。

在标准集群上，GKE 会预留资源用于其自身操作。标准集群上的数据库无法自动扩缩，因此小型 Pod 的开销可能较高。
数据库实例数 在 Kubernetes 环境中，每个数据库实例都在自己的 Pod 中运行，并且有自己的 PersistentVolumeClaim。如果您拥有大量实例，则必须运行和管理大量 Pod、节点和卷声明。您可能希望改用代管式数据库。
GKE 中的数据库备份

PersistentVolumeClaim 的范围限定为 GKE 集群。此范围界定意味着当删除 GKE 集群时即会删除卷声明。集群中的所有数据库文件也会一并删除。为了防止数据库文件意外丢失，建议您复制或定期备份文件。

您可以使用 Backup for GKE 定期截取应用配置和卷数据的快照。Backup for GKE 会处理卷备份的调度、管理备份生命周期以及将备份恢复到集群。
Kubernetes 特有的恢复行为 Pod 在 Kubernetes 中发生故障时，系统会重新创建 Pod。从数据库实例的角度来说，这意味着在重新创建 Pod 时，系统会重新创建未持久保存在数据库中或 Pod 外的稳定存储空间中的任何配置。
数据库架构 如果您的数据库配置为使用主动-被动架构，则必须确保仅将一个副本配置为主实例。许多关系型数据库都有主动-被动故障切换选项，在主数据库发生故障时，可以将辅助数据库提升为主数据库。
数据库迁移 如果您计划将现有数据库系统迁移到 GKE，请参阅数据库迁移：概念和原则（第 1 部分）和数据库迁移：概念和原则（第 2 部分）。
用户重新训练 如果您从自行管理或提供商管理的部署改为使用 Kubernetes 数据库部署，则需要重新训练数据库管理员在新环境中操作，就像在当前环境中一样可靠。应用开发者可能还需要了解二者之间在程度上的差异。

上表讨论了数据库部署的一些注意事项。但是，该表并未包含所有可能的注意事项。您还需要考虑灾难恢复、连接池和监控。

后续步骤