#k8s, #gitops, #helm, #argocd

🖼️ Наведите порядок в ваших репозиториях с Kubernetes 🖼️ манифестами с GitOps подходом!

🤓 Про деплой собственных приложении я писал ранее на Хабре. Изначально это были просто YAML манифесты, затем я написал собственный Helm-чарт 🖼️, сейчас - перевожу всё в kustomize.

🤔 Но помимо сервисов, которые пишут разработчики, в кластер нужно деплоить сторонние приложения: базы данных, брокеры, системы мониторинга и логирования.

⚠️ В таком случае я всегда создавал репозитории, где по разным директориям были разбросаны yaml манифесты, bash скрипты для деплоя Helm-чартов и прочее. Спустя небольшое количество времени такой репозитории превращается в свалку, а когда нужно что-то изменить, то это приводит к сложностям.

Про GitOps я слышал достаточно часто: сначала в чатах, а затем на собеседованиях. Я думал, что в текущих масштабах такой подход не нужен - справлюсь своими руками. Но я все же решил попробовать и.... мне понравилось!

ArgoCD - это инструмент, позволяющий поддерживать состояние Kubernetes кластера в соответствии с содержимым Git-репозитория. Таким образом тулза сама отслеживает изменения в коде и применяет их в один или несколько кластеров.

ArgoCD поддерживает стандартные yaml манифесты, Helm-чарты и kustomize. Помимо этого, он позволяет создавать сущности Application, с помощью которых можно гибко управлять различными настройками.

✍️ Советую изначально использовать паттерн App-of-Apps. Таким образом, вы можете создать корневое приложение, которое будет само управлять другими "дочерними" приложениями. Плюс - вы получите красивые схемы в UI =)

😐 Я столкнулся с тем, что ресурсы уже были развернуты. Как действовать в таком случае?

Изначально советую выключить prune и selfHeal опции, чтобы избежать непоправимых последствии. prune: false не позволит ArgoCD удалять ресурсы куба, тогда как selfHeal: false автоматически приводить кластер в описанное состояние.

Если вы хотите отдать yaml манифесты ArgoCD, то ничего делать не нужно - ArgoCD после процесса синхронизации поймет, что ресурс с таким названием в таком неймспейсе развернут и трогать его не будет.

👍 С хелмом дела обстоят иначе. Я ставил все чарты командой helm install, тогда как ArgoCD использует helm template | kubectl apply -f -. Я не знал как поведет себя ArgoCD в таком случае, а у меня не было желания переустанавливать все чарты. Но оказалось всё просто: ArgoCD сам подхватил ресурсы релизов. Чтобы полностью вывести ресурсы из управления helm, необходимо удалить секреты, которые создаются для каждого релиза и имеют Type: helm.sh/release.v1.

Для паттерна App-For-Apps вы можете использовать настройки directory.recurse и directory.include. ArgoCD не предлагает вам определенную структуру папок, вы сами можете её организовать как вам удобно.

Я сделал приложения для каждого компонента кластера: как для Helm-чартов, так и для YAML манифестов. Все приложения описаны в файлах app.yaml, которые находятся в разных уровнях вложенности. Поэтому в directory.include я указал находить все подобные файлы и применять их:

  directory:
    recurse: true
    jsonnet: {}
    include: '**/app.yaml'

Для приложении, которые используют YAML-манифесты, я задавал в качестве источников пути до этих самых манифестов:

    - path: apps/kafka/cluster
      repoURL: https://github.com/AzamatKomaev/argocd-example.git
      targetRevision: HEAD
    - path: apps/kafka/topics
      repoURL: https://github.com/AzamatKomaev/argocd-example.git
      targetRevision: HEAD
    - path: apps/kafka/users
      repoURL: https://github.com/AzamatKomaev/argocd-example.git
      targetRevision: HEAD

🙂 Так, получалась следующая связь:
root-app -> kafka -> plain YAML manifests

#k8s, #gitops, #argocd

🖼️ Push vs Pull - методы деплоя

🎶 Самый классический и базовый способ - push. Вы пишите код, заливаете его в репозиторий, срабатывает пайплайн. В процессе собирается и загружается в реестр образ приложения и затем через docker run/kubectl apply/helm install происходит замена тега.

Я много писал про этот способ. helm 🖼️ или kustomize - ультрабаза. Но с относительно недавних времён я начал применять Pull модель для инфраструктурных приложении. Про это (и GitOps подход) я писал в другой статье. Это в разы удобнее того, что было до внедрения арго 🖼️: разбросанные по всему репозиторию конфиги и забытые обновления ресурсов.

Но если для относительно статичных приложении это ок, то что насчёт приложении, которые находятся в разработке и обновляются несколько раз в день? На этот случай у ArgoCD 🖼️ (у FluxCD есть собственное) есть расширение Argo CD Image Updater.

🧑‍🎓 Argo CD Image Updater позволяет автоматически обновлять тег образа у заданного ресурса. Это и есть Pull модель! Всё то же самое, как и при push, но после загрузки образа нам не нужно ничего самим обновлять. Единственное ограничение - ресурс должен находится под управлением Argo CD (Application) и использовать kustomize/helm.

⌨️ Чтобы добавить данную штуку, нужно добавить следующие аннотации для ресурса Application:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  annotations:
    argocd-image-updater.argoproj.io/image-list: ping=ghcr.io/azamatkomaev/argo-image-updater-demo
    argocd-image-updater.argoproj.io/ping.pull-secret: pullsecret:argocd/google-registry
    argocd-image-updater.argoproj.io/ping.update-strategy: newest-build

✍️ Тут я указал название образа, стратегию обновления (в моем случае самый последний загруженный образ в реестр), а так же данные для доступа к реестру. Каждые две минуты контроллер image updater-а будет анализировать приложения с необходимыми аннотациями и обновлять тег. А еще тут красивый GUI =)

Ссылка на репозиторий с примером: тык