В нескольких местах на сайте документации Kubernetes они рекомендуют хранить файлы конфигурации YAML в исходном элементе управления для упрощения отслеживания версий, отката и развертывания.
В настоящее время мы с моими коллегами пытаемся определить структуру нашего репозитория git.
- Мы решили, что, поскольку конфигурация может измениться без каких-либо изменений в коде приложения, мы хотели бы сохранить конфигурации в отдельном общем хранилище.
- Нам может понадобиться несколько версий некоторых компонентов, работающих бок о бок в заданной среде (кластере). Эти версии могут иметь разные конфигурации.
Похоже, что существует множество потенциальных изменений, и все они имеют недостатки. Каков приемлемый способ структурирования такого репозитория?
Ответ 1
Я думаю, что рулевое управление станет стандартным способом создания установщика приложений для кластеров кубернетов. Я попытаюсь создать свой собственный график, чтобы параметризовать развертывание моего приложения.
Ответ 2
Я полагаю, пока не установлен установленный стандарт. Я считаю, что шлейфы слишком сложны для начала, особенно с использованием еще одного неуправляемого компонента, работающего на кластере k8s. Это рабочий процесс, который мы следуем, который хорошо работает для настройки 15-ти микросервисов и 5 различных сред (devx2, staging, qa, prod).
Две ключевые идеи:
- Храните конфигурации кубернетов в том же исходном репо, что и другой инструмент сборки. Например: рядом с исходным кодом микросервиса, который имеет инструментарий для создания/освобождения этого конкретного микросервиса.
- Шаблон конфигурации кубернетов с чем-то вроде jinja и отрисовкой шаблонов в соответствии с таргетингом среды.
Инструментарий достаточно прост, чтобы понять, собрав несколько сценариев bash или интегрировавшись с Makefile и т.д.
EDIT: ответить на некоторые вопросы в комментарии
Репозиторий исходного кода приложения используется как единственный источник правды. Таким образом, это означает, что если все работает так, как следует, изменения никогда не должны перемещаться из кластера кубернетов в репозиторий.
Изменения непосредственно на сервере запрещены в нашем рабочем процессе. Если это когда-либо произойдет, мы должны вручную убедиться, что они снова вошли в репозиторий приложений.
Опять же, просто хочу отметить, что конфигурации, хранящиеся в исходном коде, фактически являются шаблонами и используют secretKeyRef довольно либерально. Это означает, что из инструментария CI появляются некоторые конфигурации, и они поступают из секретов, которые живут только в кластере (например, пароли базы данных, маркеры API и т.д.).
Ответ 3
На мой взгляд, Хельм относится к кубернетам, поскольку Docker-compose - к докеру
Нет причин опасаться руля, так как в нем самая основная функциональность, все, что он делает, похоже на kubectl apply -f templates.
Как только вы познакомитесь с рулем, вы можете начать использовать values.yaml и добавить значения в свои шаблоны kubernetes для максимальной гибкости.
values.yaml
name: my-name
внутри шаблонов /deployment.yaml
name: {{.Values.name }}
https://helm.sh/
Мой подход заключается в создании подкаталога helm в каждом проекте, так же, как я включаю файл docker-compose.yml.
в дополнение к этому вы также можете поддерживать репозиторий руля для всех ваших проектов, которые ссылаются на предварительно созданные изображения
Ответ 4
- очень очевидно, отдельный репо кода приложения от репозитория развертывания
- создать репозиторий развертывания для манифестов k8s на проект
- создать ветку для каждой среды, такой как dev, stage, prod и т.д.
- разверните в test/dev и после этого создайте запрос на этап
- наконец, если пришло время для развертывания в Prod, создайте запрос на получение Prod
