Kubernetes：使用 CustomResourceDefinition + 运算符创建数据库访问机密
Kubernetes: using CustomResourceDefinition + operator to create DB access secrets
我计划在 k8s 上创建一个特殊的 'deployer' 部署（每个集群一个 'deployer'）。
它的作用是从一个中心位置提取规范，创建 k8s 清单并应用它们。
最终结果应该是多个部署，每个部署都在自己的命名空间中，带有服务和入口，以及包含数据库凭证的秘密。
我不想直接传输和管理数据库详细信息。相反，我正在考虑创建一个 CustomResourceDefinition 'dbservice'，其中将包含数据库服务名称。然后配置一个 k8s 运算符：
- 获取（监控）这样的'dbservice'资源。
- 检查数据库托管服务是否已经存在此类服务。如果不是，它将使用自定义资源中的一些规范创建它。
- 获取主机名、密码、用户、数据库名称和端口，并将它们存储在部署 (envvar) 将使用的秘密中。
这样：
- 每个部署都会等待它的数据库机密，并且在机密存在之前不会启动，这意味着数据库已准备就绪。
- 我不需要手动管理数据库服务。
- 我不必通过电线传输密码。
要实现这一点需要发生什么（根据我的计划）：
- 操作员需要具有与数据库托管提供商对话的权限（可能会使用 API 密钥访问另一个 k8s 存储的秘密）。
- 操作员需要拥有在所有命名空间中创建机密的权限。
由于我对 k8s 和 devops 总体上还很陌生，所以我想验证这种方法是否合理而不是反模式。
这绝对是理智的，甚至已经实现了一些 https://github.com/mumoshu/aws-secret-operator 但它使用 AWS secret manager 作为后端而不是 DB
UPD：另一个类似的解决方案就在今天出现：https://godaddy.github.io/2019/04/16/kubernetes-external-secrets/
Hashicorp Vault 可以为某些数据库提供商做类似的事情 - 查看文档 here. There is also the concept of service broker that can create cloud resources for you - see for example Azure Service Broker。总的来说，这听起来很棒，所以如果这两种解决方案都不适合您 - 继续构建吧！
我计划在 k8s 上创建一个特殊的 'deployer' 部署（每个集群一个 'deployer'）。 它的作用是从一个中心位置提取规范，创建 k8s 清单并应用它们。 最终结果应该是多个部署，每个部署都在自己的命名空间中，带有服务和入口，以及包含数据库凭证的秘密。
我不想直接传输和管理数据库详细信息。相反，我正在考虑创建一个 CustomResourceDefinition 'dbservice'，其中将包含数据库服务名称。然后配置一个 k8s 运算符：
- 获取（监控）这样的'dbservice'资源。
- 检查数据库托管服务是否已经存在此类服务。如果不是，它将使用自定义资源中的一些规范创建它。
- 获取主机名、密码、用户、数据库名称和端口，并将它们存储在部署 (envvar) 将使用的秘密中。
这样：
- 每个部署都会等待它的数据库机密，并且在机密存在之前不会启动，这意味着数据库已准备就绪。
- 我不需要手动管理数据库服务。
- 我不必通过电线传输密码。
要实现这一点需要发生什么（根据我的计划）：
- 操作员需要具有与数据库托管提供商对话的权限（可能会使用 API 密钥访问另一个 k8s 存储的秘密）。
- 操作员需要拥有在所有命名空间中创建机密的权限。
由于我对 k8s 和 devops 总体上还很陌生，所以我想验证这种方法是否合理而不是反模式。
这绝对是理智的，甚至已经实现了一些 https://github.com/mumoshu/aws-secret-operator 但它使用 AWS secret manager 作为后端而不是 DB
UPD：另一个类似的解决方案就在今天出现：https://godaddy.github.io/2019/04/16/kubernetes-external-secrets/
Hashicorp Vault 可以为某些数据库提供商做类似的事情 - 查看文档 here. There is also the concept of service broker that can create cloud resources for you - see for example Azure Service Broker。总的来说，这听起来很棒，所以如果这两种解决方案都不适合您 - 继续构建吧！