Конфигурация Kubernetes: на репо кода против на репозитории руля - PullRequest
Новая
       6

Конфигурация Kubernetes: на репо кода против на репозитории руля

0 голосов
/ 17 октября 2018

Helm рекламируется как «способ управления развертыванием приложений на k8s».

У нас есть микросервисы с отображением репо кода 1: 1 и возможностью развертывания, и я бы нашел егоГораздо удобнее иметь карту конфигурации k8s вместе с кодом, чтобы они развивались вместе, например, при добавлении новой переменной среды для флага функции.

Однако вместо этого мы поддерживаем единственные схемы управления рулем git repo,это необходимо периодически обновлять синхронно с кодом.

Какова лучшая практика:

  • Когда использовать схемы рулевого управления?Применимо ли это при наличии отображения кода репо 1-к-1 и возможности его развертывания?Или, главным образом, для координации развертывания составных приложений?
  • Вы успешно использовали график управления для каждого репо (вместо одного репо для всех графиков)?
  • При использовании карты конфигурации vanilla k8s для настройкиразвертывание из репозитория git, с какими проблемами вы столкнулись?Т.е. когда вы начинаете нуждаться в шлеме?

Надеюсь, он не слишком общий или неубедительный, но с удовольствием отредактировал, чтобы сделать его более конкретным.

1 Ответ

0 голосов
/ 29 октября 2018

Мы сталкивались с некоторыми из этих вопросов в облачном проекте Activiti , поэтому я могу ответить, основываясь на моем опыте:

1 Когда использовать диаграммы руля?Применимо ли это при наличии отображения кода репо 1-к-1 и возможности его развертывания?Или главным образом для координации развертывания составных приложений?

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

2 Вы успешно использовали диаграмму руляза репо (вместо одного репо для всех графиков)?

Мы сделали , для некоторых целей , и это значение по умолчанию, если вы работаете с Jenkins-X , который дает вам самоуверенный кластер kubernetes, настроенный для определенного способа выполнения CI / CD.Он включает в себя chartmuseum в этом кластере, и когда вы создаете приложение в Jenkins-X, используя его конвейер по умолчанию, тогда диаграмма публикуется во внутреннем mapmuseum.

Однако мы имеем также использовал один репо .Это естественный путь, если вы размещаете свои диаграммы в репозитории github pages , поскольку это упрощает создание пакетов диаграмм и их публикацию, если источник находится в том же месте, где они находятся.организовано.Однако я не думаю, что это необходимо - если вы настроили для этого свой CI, вы сможете добавить упакованные диаграммы в каталог docs и переиндексировать репо .Это будет означать, что ваш CI для каждого проекта должен будет совершать коммиты в проект helm repo.

3 Если вы используете карту конфигурации vanilla k8s для настройки развертывания из git-репо, какие у вас проблемы?сталкивался?Т.е. когда вы начинаете нуждаться в helm?

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

...