#kubernetes #kubernetes-secrets #kubernetes-custom-resources
#kubernetes #kubernetes-секреты #kubernetes-пользовательские ресурсы
Вопрос:
Я планирую создать специальное развертывание «deployer» на k8s (по одному «deployer» на кластер). Его роль заключалась бы в том, чтобы извлекать спецификации из центрального места, создавать манифесты k8s и применять их. Конечным результатом должно быть несколько развертываний, каждое в своем собственном пространстве имен с сервисом и входом, а также секрет, содержащий учетные данные БД.
Я не хочу напрямую передавать и управлять деталями БД. Вместо этого я думал о создании CustomResourceDefinition ‘dbservice’, который будет содержать имя службы БД среди остальных. Затем настройте оператор k8s, который будет:
- Возьмите (контролируйте) такой ресурс dbservice.
- Проверьте с помощью службы размещения БД, если такая служба уже существует. Если нет, он создаст его с некоторыми спецификациями из пользовательского ресурса.
- Получите имя хоста, пароль, пользователя, имя базы данных и порт и сохраните их в секрете, который будет использоваться развертыванием (envvar).
Таким образом:
- Каждое развертывание будет ожидать своего секрета БД и не будет запускаться до тех пор, пока секрет не будет существовать, что означает, что БД готова.
- Мне не пришлось бы управлять службами БД вручную.
- Мне не пришлось бы передавать пароли по проводам.
Что должно произойти, чтобы это сработало (согласно моему плану):
- У оператора должны быть разрешения для общения с поставщиком хостинга БД (вероятно, он получит доступ к другому хранящемуся секрету k8s с помощью ключа API).
- У оператора должны быть разрешения на создание секретов во всех пространствах имен.
Поскольку я довольно новичок в k8s и devops в целом, я хотел убедиться, что этот подход является разумным, а не антишаблоном.
Ответ №1:
Это абсолютно разумно, и отчасти это даже уже реализовано https://github.com/mumoshu/aws-secret-operator но он использует AWS secret manager в качестве серверной части вместо базы данных
UPD: другое аналогичное решение появилось только сегодня: https://godaddy.github.io/2019/04/16/kubernetes-external-secrets /
Ответ №2:
Hashicorp Vault может сделать нечто подобное для некоторых поставщиков БД — ознакомьтесь с документацией здесь . Существует также концепция service broker, которая может создавать для вас облачные ресурсы — см., например, Azure Service Broker. В целом, это звучит довольно круто, поэтому, если оба решения не работают для вас — продолжайте и создайте его!