Лучшая стратегия CD для развертываний Kubernetes

Наш текущий этап развертывания CI работает следующим образом:

Постройте контейнеры.
Пометьте изображения как "latest" и < commit hash >.
Вставить изображения в репозиторий.
Вызвать обновление на соответствующих RC (ы).

Это отлично работает для развертываний на базе RC, но теперь, когда объект Deployment становится более стабильным и базовой функцией, мы хотим воспользоваться этой абстракцией над нашими текущими схемами развертывания и этапами разработки.

У меня возникают проблемы с поиском разумного способа автоматизации обновления Deployment с помощью рабочего процесса CI. То, что я экспериментировал, - это разделение репо git и выполнение чего-то вроде:

[App Build] Создайте контейнеры.
[App Build] Отметьте изображения как "latest" и < commit hash >.
[App Build] Нажмите изображения в репозиторий.
[App Build] Вызывает сборку приложения Deployment repo, проходящего через текущий хеш фиксации.
[Развертывание сборки] Интерполируйте токены манифеста манифеста (в настоящее время только переданный хэш хеширования, например image: app-%%COMMIT_HASH%%)
[Deployment Build] Применить обновленный манифест к соответствующим ресурсам Deployment.

Конечно, хотя есть лучший способ справиться с этим. Было бы здорово, если бы Deployment отслеживал хэш-изменения изображения "последнего" тега... может быть, он уже делает? Я не имел успеха в этом. Любые мысли или идеи о том, как лучше обрабатывать развертывание Deployment, будут оценены:)

Ответ 1

Изменены только мониторы Deployment для шаблона модуля (.spec.template). Если имя изображения не изменилось, Deployment не будет выполнять обновление. Вы можете активировать скользящее обновление (с помощью Deployment s), изменив шаблон модуля, например, назовите его хэшем commit. Кроме того, вам нужно установить .spec.template.spec.containers.imagePullPolicy в Always (он установлен на Always по умолчанию, если указан тег :latest и не может быть обновлен), иначе изображение будет повторно использовано.

Ответ 2

Мы практикуем то, что мы называем GitOps какое-то время.

У нас есть оператор согласования, который соединяет кластер с конфигурационным репозиторием и гарантирует, что все ресурсы Kubernetes (включая CRD) находит в этом репозитории, применяются к кластеру. Он допускает развертывание ad-hoc, но любые специальные изменения для того, что определено в git, будут отменены в следующем цикле согласования. Оператор также может просматривать любой реестр изображений для новых тегов, обновлять атрибуты image типов объектов Deployment, DaemonSet и StatefulSet. Сначала он вносит изменения в git, затем применяет его к кластеру.

Итак, что вам нужно сделать в CI:

Постройте контейнеры.
Пометьте изображения как <commit_hash>.
Вставить изображения в репозиторий.

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

Для обзора на высоком уровне см.:

Отказ от ответственности: я являюсь сотрудником Kubernetes и сотрудником Weaveworks. Мы строим инструменты с открытым исходным кодом и коммерческие инструменты, которые помогают людям быстрее добраться до производства Кубернете.