0

我计划在 k8s 上创建一个特殊的“部署者”部署（每个集群一个“部署者”）。它的作用是从一个中心位置提取规范，创建 k8s 清单并应用它们。最终结果应该是多个部署，每个部署都在它自己的命名空间中，带有服务和入口，以及包含数据库凭据的秘密。

我不想直接传输和管理数据库详细信息。相反，我正在考虑创建一个 CustomResourceDefinition 'dbservice'，其中包含一个 DB 服务名称。然后配置一个 k8s 操作符，它将：

  1. 获取（监控）这样的“dbservice”资源。
  2. 如果此类服务已经存在，请与数据库托管服务联系。如果不是，它将使用自定义资源中的一些规范创建它。
  3. 获取主机名、密码、用户、数据库名称和端口，并将它们存储在部署 (envvar) 将使用的密钥中。

那样：

  1. 每个部署都会等待它的数据库密码，并且在密码存在之前不会启动，这意味着数据库已准备好。
  2. 我不必手动管理数据库服务。
  3. 我不必通过电线传输密码。

为此需要发生什么（根据我的计划）：

  1. 操作员需要有权限与数据库托管提供商交谈（可能会使用 API 密钥访问另一个 k8s 存储的秘密）。
  2. 操作员需要具有在所有命名空间中创建机密的权限。

由于我对 k8s 和 devops 还很陌生，所以我想验证这种方法是否合理而不是反模式。

4

2 回答 2

3

这绝对是理智的，它甚至已经实现了https://github.com/mumoshu/aws-secret-operator但它使用 AWS 秘密管理器作为后端而不是数据库

UPD：今天出现了另一个类似的解决方案：https ://godaddy.github.io/2019/04/16/kubernetes-external-secrets/

于 2019-04-16T16:08:42.167 回答
1

Hashicorp Vault 可以为一些数据库提供者做类似的事情——查看这里的文档。还有可以为您创建云资源的服务代理的概念——例如Azure 服务代理。总的来说，这听起来非常棒，所以如果这两种解决方案都不适合您 - 继续构建它！

于 2019-04-16T16:21:56.957 回答