mysql - Kubernetes 多数据库实例或 HA 单实例

Question

我有一个运行多个应用程序(服务)的 Kubernetes 环境。现在我对如何设置 MySQL 数据库实例有点困惑。

根据不同的来源，每个微服务都应该有自己的数据库。我应该在运行多个数据库的 HA 模式下创建单个 MySQL statefulset，还是应该为每个运行一个数据库的每个应用程序(服务)部署一个单独的 MySQL 实例。

我的第一个想法是第一个选项，因此 HA 应该用在什么地方？想听听一些对此的不同看法。

Answer 1

有点主观的问题，但这是我们的设置。希望这能帮助您建立案例。我敢肯定有人会有不同的意见，这也可能同样有效:

我们部署了大约 70 个微服务，每个微服务都有自己的数据库(“架构”)和自己的 JDBC URL(通过服务定义)。每个微服务都有自己的端点和凭证，我们不会在微服务之间共享。因此，实际上，就模式而言，我们一直保持设计在微服务之间完全独立。

但是，在部署方面，我们选择使用单个数据库实例来托管所有数据库(或“模式”)。虽然从技术上讲，我们可以将每个数据库部署在其自己的数据库实例上，但出于以下几个主要原因，我们选择不这样做:

1. 成本开销:为每个微服务运行单独的数据库实例会增加很多“固定”成本。如果您只是将数据库作为 MySQL Docker 容器启动(我们使用单独的数据库服务，例如 RDS 或 Google Cloud SQL)，这可能与您没有直接关系。但是，即使在将 MySQL 作为 Docker 容器的情况下，如果您运行 70 个单独的容器，每个微服务一个，您最终可能会付出不小的成本。
2. 管理开销:鉴于数据库通常非常复杂(磁盘空间、IIOP、备份/存档、清除、升级和其他管理事件)，具有单独的数据库实例 - 或 Docker 容器实例 - - 可能会给您的管理或运营团队带来重大损失，尤其是当您拥有大量微服务时
3. 安全性:当涉及到安全性时，数据库通常也很重要，因为“真相”通常存在于数据库中。撇开加密、TLS 配置和凭证强度不谈(因为无论您的部署模型如何，它们都应该是最重要的)，如果您的数据库实例太多，安全考虑、审查、审计和日志记录将带来重大挑战。
4. 易于开发:在宏伟的计划中相对不那么重要，但仍然很重要。除非您正在考虑提出一种不同的开发模型(从而打破“dev-prod 奇偶校验”)，否则您的开发人员可能很难确定用于调试的数据库端点，即使他们只需要一次性信息-一会儿。

因此，我的建议是使用单个数据库实例(Docker 或其他方式)，但要保持数据库/模式完全独立，并且除“所有者”微服务之外的任何微服务都无法访问。

如果您将 MySQL 部署为 Docker 容器，请使用 StatefulSet 进行持久化。定义一个外部 pvc 这样您就可以始终保留数据，无论您的 pod 甚至集群发生什么情况。当然，如果你运行“主动-主动”，你将需要确保节点之间的集群，但我们确实以“主动-被动”模式运行它，所以我们将 replica 计数保持为 1假设我们只在测试环境中使用 MySQL Docker 容器替代方案，以节省不需要的外部 DBaaS 服务的成本。