Как скопировать строку из приложения поставщика в одном модуле Kubernetes в приложение поставщика в другом модуле?

Question

У меня есть набор предоставленных поставщиком контейнеров, которые работают вместе для предоставления услуги, назовем их A, B и C - кластер Kubernetes запускает один из каждого в отдельных модулях.

• Контейнер A - это контейнер внешнего интерфейса Nginx, который в основном перенаправляет содержимое в контейнер B. Веб-интерфейс позволяет зарегистрировать учетную запись, которая на самом деле является вызовом API, перенаправленным в контейнер B.
• Контейнер B является внутренним сервером - он имеет собственную базу данных в памяти и хранит там учетные записи. Когда создается учетная запись, токен безопасности также создается и сохраняется. (Пользователи могут получить этот токен через вызовы API через A.)
• Контейнер C является мостом для некоторых вещей за пределами кластера. Но важно, что вы настраиваете его с помощью переменной среды, содержащей действительный токен безопасности от учетной записи пользователя, хранящейся в контейнере B. C использует этот токен для связи с B через A.

В идеале я хотел бы развернуть все это в одном go - это означает, что мне как-то нужно создать учетную запись в контейнере B (вызвав A), а затем передать это значение в переменную окружения для C.

Некоторые мысли:

• Я не могу использовать контейнер инициализации для SQL вставки нового пользователя, поскольку база данных не отображается.
• Я могу построить контейнеры поверх контейнеров поставщика для редактирования конфигурации / скриптов и т. Д. c, но замена двоичных файлов, вероятно, выходит за рамки.
• Я могу примерно Скрипт API-интерфейса сервера от A до B. Однако это сложно, так как он использует токены XSRF, которые сохраняются между запросами, и т.д. c. Любые предложения относительно самых простых инструментов / библиотек, которые можно использовать для достижения этой цели, приветствуются.
• Если я выполню сценарий создания этой учетной записи, мне потребуется вставить этот токен в Deployment for container C - я мог бы использовать ConfigMap, но тогда мне нужно будет вызвать Kube API для изменения ConfigMap изнутри кластера, и это не кажется мне хорошей идеей.

Для меня единственная жизнеспособная Решение состоит в том, чтобы поместить initContainer в C, который будет запрашивать токен безопасности у B (через A), а затем записать его на общий том. Затем я построил бы поверх контейнера C для чтения из общего тома, установил внутреннюю переменную среды для контейнера и запустил процесс поставщика. Но тогда я должен управлять секретом для учетной записи пользователя.

Есть ли какие-либо улучшения в этом подходе или что-то совершенно другое, что я не учел?

Answer 1

Выполнение операций API изнутри контейнера не является антипаттерном. Блокируйте запуск вашего процесса на C до тех пор, пока initContainer не запустится и не обновит Secret, содержащий токен. Не используйте ConfigMap для секретов; для этих целей существует объект Secret, и вы можете вставить Secret в PodSpec - как env vars, или как монтирование тома - так же, как вы извлекаете ConfigMap (с небольшим изменением синтаксиса).

Единственная проблема, с которой я могу столкнуться - это то, что вы будете иметь дело с несколькими репликами, поэтому вы можете захотеть рандомизировать часть имени Secret. Создайте его в initContainer, передайте случайное имя в файловой системе, поскольку Pods совместно использует файловую систему, затем используйте его в главном контейнере и удалите Secret после настройки env var или mount. Secrets и ConfigMaps могут исчезнуть после запуска Pod, не влияя на их присутствие внутри Pod.

Возможно, вам также понадобится способ очистки учетных записей пользователей, так как вы ' по сути, создаем нового пользователя каждый раз, когда реплика запускается и у нее не будет возможности удалить ее. Для этого может быть CronJob - перечислите учетные записи пользователей, соответствующие вашему соглашению об именах, затем перезапустите развертывание и удалите учетные записи в списке, который вы выбрали до перезапуска. Таким образом, вы не будете вытягивать ковер из активных реплик.