Как автоматизировать развертывание YAML в Kubernetes, не полагаясь на: последние?

Question

У меня есть репозиторий с YAML для развертывания в Kubernetes. Конвейеры запускаются для каждого коммита, который создает и помещает изображение в наш репозиторий с версией коммита (например, my_project:bm4a83). Затем я обновляю образ развертывания

kubectl set image deployment/my_deployment my_deployment=my_project:bm4a83.

Это работает, но я также хочу сохранить остальную часть спецификации развертывания YAML в управлении версиями.

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

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

Какой разумный рабочий процесс для управления этим? Я что-то упустил полностью?

Answer 1

но я также хочу сохранить остальную часть спецификации YAML развертывания в управлении версиями.

Да, вы хотите это сделать. Положить все под контроль версий - хорошая практика для создания неизменной инфраструктуры.

Если вы хотите, чтобы у развертывания был отдельный фрагмент метаданных (по любой причине аудита / отслеживания изменений), почему вы не можете просто использовать блок Kubernetes metadata?

metadata:
  name: my_deployment
  commit: bm4a83

Затем вы вводите такую ​​информацию через Jinja, Ruby ERB, Go Templates и т. Д.

Answer 2

Какой разумный рабочий процесс для управления этим? Я что-то упустил полностью?

Некоторые ответы зависят от того, какой риск вы пытаетесь снизить с помощью любого имеющегося процесса. Если это «кластер был уничтожен ураганом, и мне нужно восстановить мои дескрипторы», тогда Heptio Ark является хорошим решением для этого. Если риски более «ориентированы на человека», то ИМХО вам придется пройти очень осторожную грань между блокировкой всех вещей и нанесением вреда очень гибким, расширяющим возможности инструментам, которые kubernetes предоставляет команде. Конкретный пример того, как эта модель работает против вашей модели: что происходит, когда разработчик редактирует развертывание, но не (помнит | знает) обновить дескриптор в репозитории? Так вы отменяете права на редактирование? Использовать некоторую логику сравнения, чтобы обнаружить измененную конфигурацию в кластере?

Говорить с тем, что вы сказали в частности : крайне неоптимальной идеей является изменение дескриптора только для изменения размера (Deployment|ReplicationController|StatefulSet). Отдельно, хорошо построенный конвейер CI также должен понимать, что если артефакт buildable не изменен и не выйдет из строя (либо на ранней стадии, либо даже не на запуск сборки, если инструмент CI настолько умен).

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

$ grep "image: " the-deployment.yml
    image: example.com/something:#CI_PIPELINE_IID#
$ sed -i'' -e "s/#CI_PIPELINE_IID#/${CI_PIPELINE_IID}/" the-deployment.yml
$ kubectl apply -f the-deployment.yml

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