Рекомендации по хранению конфигурации kubernetes в системе управления версиями

в нескольких местах на сайте документации Kubernetes рекомендуется хранить файлы конфигурации YAML в системе управления версиями для простого отслеживания версий, отката и развертывания.

мои коллеги и я в настоящее время находимся в процессе принятия решения о структуре нашего репозитория git.

  • мы решили, что поскольку конфигурация может меняться без изменения кода приложения, которые мы хотели бы сохранить конфигурации в отдельный, общий репозиторий.
  • нам может понадобиться несколько версий некоторых компонентов, работающих бок о бок в данной среде (кластере). Эти версии могут иметь различные конфигурации.

есть много возможных вариаций, и все они имеют недостатки. Каков общепринятый способ структурирования такого хранилища?

10
configuration git kubernetes

3 ответов

думаю, что руля станет стандартизированным способом создания установщика приложений для кластеров kubernetes. Я постараюсь создать свой собственный диаграммы для параметризации развертываний приложений.

1

Я считаю, что еще нет установленного стандарта. Я нахожу диаграммы Хелма слишком сложными для начала, особенно с другим неуправляемым компонентом, работающим в кластере k8s. Это рабочий процесс, который мы следуем, который работает довольно хорошо для настройки 15ish микросервисов и 5 различных сред (devx2, staging, qa, prod).

2 ключевые идеи:

  1. магазин kubernetes конфигураций в одном РЕПО источник другие инструменты сборки. Например: бок о бок исходный код микрослужб, который имеет инструментарий для создания/освобождения, что особое конструирование.
  2. Template конфигурация kubernetes с чем-то вроде jinja и визуализирует шаблоны в соответствии с средой, на которую вы нацелены.

инструмент достаточно прост, чтобы выяснить, собрав несколько сценариев bash или интегрируясь с Makefile и т. д.

EDIT: чтобы ответить на некоторые вопросы в комментарий

репозиторий исходного кода приложения используется как единственный источник истины. Это означает, что если все работает так, как должно, изменения никогда не следует перемещать из кластера kubernetes в репозиторий.

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

опять же, просто хочу отметить, что конфигурации, хранящиеся в источнике код на самом деле шаблоны и использовать secretKeyRef довольно обильно. Это означает, что некоторые конфигурации поступают из инструментов CI по мере их визуализации, а некоторые поступают из секретов, которые живут только в кластере (например, пароли базы данных, маркеры API и т. д.).

6

в мой шлем мнение kubernetes как docker-compose является в Docker

нет причин бояться руля, так как в нем самая основная функциональность, все, что он делает, похоже на kubectl apply -f templates.

как только вы познакомитесь с helm, вы можете начать использовать values.yaml и добавление значений в шаблоны kubernetes для максимальной гибкости.

значения.и YAML

name: my-name

внутри шаблоны/развертывание.и YAML

name: {{ .Values.name }}

https://helm.sh/

мой подход заключается в создании подкаталога helm в каждом проекте так же, как я включаю docker-compose.файл yml.

в дополнение к этому, вы также можете поддерживать репозиторий helm для всех ваших проектов, которые ссылаются на изображения, которые предварительно построены

1