Данная статья написана по итогу успешного прохождения курса Инфраструктурная платформа на основе Kubernetes С развитием методологии Gitops - имплементации непрерывной поставки при которой описание и изменение системы производятся декларативно с использованием системы контроля версий, а также являющейся естественным продолжением и развитием infrastracture as a code - появляются удобные инструменты для внедрения данного метода. В первую очередь хочется выделить  самые популярные инструменты непрерывной поставки по версии CNCF - ArgoCD и Flux. Оба приложения реализуют схожий функционал - синхронизацию git и кластера kubernetes. Если сравнивать два этих решения, то  заметно, что у Flux  есть ряд ограничений: Работа и управление одним Кластером; Один кластер - один репозиторий. В это плане ArgoCD является более мощным инструментом.Он позволяет подключать множество репозиториев, может управлять одним и более кластером: Напомню ключевые  особенности : Приложение имплементируется как контроллер в кластере, отслеживает изменения в git, сравнивая с текущим состоянием, и,  случае изменений в исходном коде, помечает приложение как рассинхронизированное , и автоматически применяет изменения(или в ручном  режиме, в зависимости от настройки); Имеется поддержка большого количества инструментов для применения в кластере (Kustomize, Helm, Ksonnet, Jsonnet, plain-YAML); Откат к любому возможному комиту, зафиксированному в системе контроля версий; Удобная визуализация. Во время внедрения и эксплуатации появился важный вопрос:  если мы осуществляем деплой микросервисов в кластер kubernetes, то очень важным моментом будет являться обновление образа в репозитории. Например мы разрабатываем приложение, настроили CI для сборки образа и дальнейшей его отправки в container registry, и хотим, чтобы оно как можно скорее оказалось в кластере, используя инструмент CD.Но ведь манифесты деплоя  у нас не изменились, при добавлении нового образа ArgoCD не увидит этого, а в переменной helm у нас хранится статичная версия образа. Да - конечно мы можем вручную изменить, сделать коммит и ArgoCD автоматически обновит состояние кластера, но как это автоматизировать ,используя текущий стэк? Вернемся к сравнению с flux:  при использовании этого инструмента мы работаем с helm оператором, интегрированным в кластер и его сущностями - helmrelease. Мы добавляем отслеживание container registry в манифест helmrelease для приложения по определенному паттерну, например используя общепринятое семантическое версионирование  semver  : Теперь  Flux отслеживает изменения тэга в container registry, и если появилась новая версия - сам вносит изменения в код! Таким образом мы запустили процесс  обновления приложения в кластере. Замечу в свою очередь, что такие изменения в git доставляют ряд неудобств - в случае коммита в переменные helm, необходимо не забывать сделать пул последних изменений, которые внес flux, иначе будет  merge конфликт . До недавнего времени у ArgoCD отсутствовала такая функциональная возможность, и при изменении образа приходилось делать коммит вручную, фиксируя новую версию образа в коде. Сейчас - появилось отдельное приложение - Argo CD Image Updater. Это специальная утилита, которая интегрируется в текущую установку ArgoCD и позволяет отслеживать изменения в используемом container registry, автоматически обновляя приложение.Из  основных возможностей хотелось бы отметить : Поддержка большого количества видов container registry (как публичных так и частных); Отслеживание обновлений, используя различные cтратегии версионирования; Параллельное обновление приложений. Также важно сказать об ограничениях : Приложение должно обязательно быть под управлением ArgoCD; Поддержка только Helm и Kustomize, причем, при использовании helm - image.tag должен быть обязательно шаблонизирован (вынесен в переменные). Согласно  документации - наиболее удобным и правильным будем являться установка в текущую инсталляцию ArgoCD, в тот же namespace(хотя и есть возможность установить в другой кластер). Установка осуществляется применением манифеста из репозитория проекта. Затем нам нужно сказать  какие  applications (сущности ArgoCD) необходимо отслеживать: для этого необходимо добавить аннотации с параметрами в зависимости от выбранной стратегии :    argocd-image-updater.argoproj.io/image-list: <image_spec_list> - указать адрес container registry ,например : argocd-image-updater.argoproj.io/image-list: frontend:~v0.0 Подобная стратегия позволить отслеживать изменения версий внутри минорного релиза v0.0 По умолчанию используется стратегия версионирования semver, но можно  сделать и другую используя аннотацию : argocd-image-updater.argoproj.io/<image_name>.update-strategy: <strategy> Стратегия Описание semver Обновление до версии согласно политике latest обновление до наиболее последней версии name Обновление до наиболее последней версии, отсортированной по имени в алфавитном порядке Следующим наиболее важным параметром, настраиваемым в виде аннотации к application является выбор политики обратной записи(как нам фиксировать изменения в коде в случае изменения образа) : Императивный метод -  используя ArgoCD api (не фиксирует); Декларативный метод - фиксирует изменения в гит;. Императивный метод фактически выполняет argocd app set --parameter, и он является персистентным только пока приложение не удалено из ArgoCD. Данный  метод удобен если приложения создаются через webui. Также он применяется по умолчанию. Если мы хотим использовать второй способ - то нам необходима аннотация: argocd-image-updater.argoproj.io/write-back-method: git В случае использования хранения в системе контроля версий, в нем создается манифест .argocd-source-<appName>.yaml, в котором будет обновляться версия тэга : Важно отметить что в отличие от flux, никакое другое приложение не использует этот файл, что минимизирует возможность merge конфликтов. Также для получения доступа в гит и внесения изменений argocd image updater использует авторизацию уже настроенную в ArgoCD, но при этом есть возможность прописать отдельные credentials. Настроенное приложение ArgoCD  для работы с argocd image updater будет выглядеть примерно так : Конечную целевую схему можно отобразить следующим образом : Таким образом и без того мощная утилита дополняется важным функционалом, благодаря чему все большее количество людей будет ее выбирать в качестве основного CD инструмента Argo CD Image Updater сейчас находится в стадии активной разработки - текущая версия 0.9.2 , и по заверениям разработчиков до версии 1.0. может быть ряд крупных изменений, влияющих на функционал. Используемая документация : Flux;  ArgoCD; Argocd image updater. Devops engineer at Wrike