ArgoCD та GitOps у 2026 році: безперервне розгортання Kubernetes та питання для співбесід

ArgoCD утвердився як домінантний GitOps-інструмент для безперервного розгортання у Kubernetes. Версія 3.4, випущена у травні 2026 року, закріплює цю позицію на тлі того, що понад 64% підприємств визнають GitOps основним механізмом доставки програмного забезпечення. У цій статті розглядаються ключові концепції ArgoCD, практичні патерни конфігурації та питання, які найчастіше виникають на технічних співбесідах для ролей DevOps та platform engineering.

Як ArgoCD реалізує модель GitOps

ArgoCD функціонує як набір мікросервісів усередині Kubernetes-кластера: API-сервер, repo-сервер, контролер застосунків та Redis-кеш. Контролер відстежує Git-репозиторії та порівнює бажаний стан (маніфести у Git) з поточним станом кластера. Коли виявляється розбіжність, ArgoCD або сповіщає, або автоматично синхронізує залежно від налаштованої політики.

Такий pull-based механізм забезпечує суттєву перевагу у безпеці порівняно з традиційними push-розгортаннями через CI. Кластер самостійно отримує зміни з Git, а не відкриває вхідну точку доступу для CI-інструменту. Credentials кластера ніколи не виходять за його межі.

Першим кроком є встановлення ArgoCD та визначення ресурсу Application:

# argocd-application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-web-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/acme/my-web-app-config
    targetRevision: main
    path: overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true        # Remove resources deleted from Git
      selfHeal: true     # Revert manual changes in the cluster
    syncOptions:
      - CreateNamespace=true

Блок source вказує на Git-репозиторій із Kubernetes-маніфестами. Блок destination визначає цільовий кластер та namespace для розгортання. Активація automated.selfHeal: true гарантує, що будь-яка ручна зміна через kubectl буде перезаписана станом, задекларованим у Git, протягом кількох секунд.

Sync Waves та Hooks: впорядковане розгортання

Реальні deployment-процеси рідко обмежуються одним маніфестом. Міграції бази даних повинні завершитися до запуску подів застосунку. ConfigMaps та Secrets мають існувати до того, як Deployments на них посилатимуться. ArgoCD вирішує це завдання за допомогою sync waves та resource hooks.

Sync waves призначають числовий порядок ресурсам. Ресурси з нижчими номерами розгортаються першими, і ArgoCD очікує, поки кожна хвиля набуде стану healthy, перш ніж переходити до наступної:

# migration-job.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: db-migrate
  annotations:
    argocd.argoproj.io/sync-wave: "-1"   # Runs before wave 0
    argocd.argoproj.io/hook: PreSync      # Executes before main sync
    argocd.argoproj.io/hook-delete-policy: HookSucceeded
spec:
  template:
    spec:
      containers:
        - name: migrate
          image: acme/my-web-app:latest
          command: ["python", "manage.py", "migrate"]
      restartPolicy: Never

Hook PreSync запускає Job міграції перед тим, як ArgoCD застосує основні маніфести застосунку. Політика видалення HookSucceeded автоматично прибирає Job після успішного виконання. ArgoCD 3.3 також запровадив hooks PreDelete, що розв'язує давню проблему сирітських ресурсів при видаленні застосунків.

Управління кількома кластерами через ApplicationSets

Керування десятками кластерів з однієї інсталяції ArgoCD вимагає більшого, ніж копіювання маніфестів Application. ApplicationSets динамічно генерують ресурси Application на основі шаблонів та генераторів:

# applicationset-clusters.yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-web-app-all-clusters
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            env: production
  template:
    metadata:
      name: 'my-web-app-{{name}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/acme/my-web-app-config
        targetRevision: main
        path: 'overlays/{{metadata.labels.region}}'
      destination:
        server: '{{server}}'
        namespace: production
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

Генератор clusters ітерує по всіх зареєстрованих кластерах, що відповідають мітці env: production, та створює одну Application на кожен кластер. Плейсхолдери {{name}}, {{server}} та {{metadata.labels.region}} заповнюються з даних реєстрації кластера. Додавання нового production-кластера до ArgoCD автоматично ініціює розгортання застосунку на цей кластер.

ArgoCD vs Flux: вибір GitOps-інструменту

Порівняння ArgoCD та Flux залишається однією з найпоширеніших тем на співбесідах для DevOps-інженерів. Обидва проєкти мають статус CNCF Graduated та реалізують патерн GitOps, проте суттєво відрізняються архітектурою та компромісами:

| Характеристика | ArgoCD 3.4 | Flux 2.8 | |---------|-----------|----------| | Архітектура | Централізований сервер з UI | Розподілені контролери на кожен кластер | | Веб-інтерфейс | Вбудований, якісний dashboard | Немає вбудованого UI (сторонні рішення) | | Підтримка Helm | Рендеринг шаблонів на стороні сервера | Нативна інтеграція з Helm SDK | | Multi-cluster | Hub-and-spoke з однієї інсталяції | Незалежне встановлення на кожен кластер | | RBAC | На рівні застосунків з SSO | Лише Kubernetes-нативний RBAC | | Автоматизація образів | Окремий компонент Image Updater | Вбудований image reflector/automation | | Поступове розгортання | Інтеграція з Argo Rollouts | Інтеграція з Flagger | | Споживання ресурсів | Вище (API server, repo server, Redis) | Нижче (лише потрібні контролери) |

ArgoCD підходить командам, які цінують централізовану видимість, веб-dashboard та гранулярний RBAC на рівні застосунків. Flux орієнтований на команди, що працюють в edge-середовищах або з обмеженими ресурсами, а також на тих, хто активно використовує нативні можливості життєвого циклу Helm. Деякі організації використовують обидва інструменти: ArgoCD для розгортання застосунків, де UI додає цінність, та Flux для інфраструктурних компонентів, де важливі розподілена робота та повна сумісність з Helm.

Структура репозиторію для production GitOps

Типова помилка при впровадженні GitOps полягає у зберіганні Kubernetes-маніфестів разом із вихідним кодом застосунку. Відокремлення конфігураційного репозиторію від репозиторію застосунку забезпечує чистішу Git-історію, незалежні цикли ревю та простіші тригери CI:

# Recommended repository structure
my-web-app-config/
  base/
    deployment.yaml
    service.yaml
    kustomization.yaml
  overlays/
    staging/
      kustomization.yaml       # Patches for staging
      replica-count.yaml
    production/
      kustomization.yaml       # Patches for production
      replica-count.yaml
      hpa.yaml

Директорія base містить спільні маніфести. Кожен overlay застосовує патчі, специфічні для конкретного середовища, через Kustomize. CI-конвеєр збирає та публікує контейнерний образ, потім оновлює тег образу в конфігураційному репозиторії. ArgoCD виявляє коміт і синхронізує нову версію з кластером.

Нововведення ArgoCD 3.4

ArgoCD 3.4, випущений у травні 2026 року, спрямований на операції Day 2 та містить функціональність, яка регулярно виникає на співбесідах для senior DevOps-інженерів.

Призупинення reconciliation кластера дозволяє операторам заморозити синхронізацію ArgoCD під час production-інциденту. Це запобігає тому, щоб ArgoCD відкотив екстрені виправлення, застосовані безпосередньо до кластера, поки команда розв'язує проблему:

# Pause reconciliation on a specific cluster
apiVersion: v1
kind: Secret
metadata:
  name: prod-cluster
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
  annotations:
    argocd.argoproj.io/pause-reconciliation: "true"
stringData:
  server: https://prod-cluster.example.com
  config: |
    { "tlsClientConfig": { "insecure": false } }

Helm value globs замінюють багатослівні масиви valueFiles шаблонами, зменшуючи merge-конфлікти у командах, які підтримують велику кількість файлів значень для різних середовищ:

# Before ArgoCD 3.4
source:
  helm:
    valueFiles:
      - values.yaml
      - values-production.yaml
      - values-production-eu.yaml
      - values-production-eu-secrets.yaml

# With ArgoCD 3.4 value globs
source:
  helm:
    valueFiles:
      - values.yaml
      - values-production*.yaml

Типові питання для співбесід з ArgoCD

Наведені питання регулярно зустрічаються на співбесідах для DevOps-інженерів та platform-інженерів. Вони перевіряють розуміння принципів GitOps, а не лише синтаксис ArgoCD. Для ширшої підготовки з Kubernetes модуль Kubernetes advanced охоплює планування, контексти безпеки та кастомні контролери.

"Поясніть різницю між автоматичною та ручною синхронізацією в ArgoCD."

Автоматична синхронізація застосовує зміни до кластера одразу після того, як ArgoCD виявляє розбіжність між Git та поточним станом. Ручна синхронізація вимагає явного підтвердження через UI, CLI або API. Автоматична синхронізація з selfHeal: true безперервно виправляє дрейф конфігурації, що є стандартом для production-середовищ, де критична консистентність конфігурації. Ручна синхронізація підходить для staging-середовищ, де команди бажають перевіряти зміни перед їх застосуванням.

"Що відбувається, коли ArgoCD виявляє дрейф між Git та кластером?"

ArgoCD порівнює бажаний стан (маніфести Git, відрендерені через Helm, Kustomize або чистий YAML) з поточним станом кластера. Якщо автоматична синхронізація активована з selfHeal, ArgoCD негайно повертає кластер до стану, задекларованого у Git. Якщо selfHeal вимкнено, ArgoCD позначає застосунок як OutOfSync та очікує ручного втручання. Diff ресурсів залишається доступним в UI, показуючи, які саме поля розійшлися.

"Як організувати міграції бази даних у GitOps-процесі?"

Міграції бази даних запускаються як PreSync hook Jobs із від'ємним номером sync wave. Job міграції виконується до того, як ArgoCD розгорне нову версію застосунку. Якщо міграція завершується помилкою, синхронізація припиняється, і попередня версія застосунку продовжує працювати. Політика видалення HookSucceeded очищує успішно виконані Jobs міграцій. Для сценаріїв відкату скрипти міграцій повинні проєктуватися як ідемпотентні операції.

"Порівняйте ArgoCD та Flux для multi-cluster production-інфраструктури."

ArgoCD керує кількома кластерами з єдиної площини управління, забезпечуючи централізовану видимість через dashboard та уніфікований RBAC по всіх кластерах. Flux працює незалежно у кожному кластері, зменшуючи радіус ураження, оскільки збій площини управління впливає лише на один кластер. При масштабі понад 100 кластерів централізована модель ArgoCD вимагає надійного management-кластера, тоді як розподілений підхід Flux усуває цю єдину точку відмови. Вибір залежить від пріоритетів команди: операційна простота (ArgoCD) чи ізоляція відмов (Flux). Модуль безпеки CI/CD pipeline охоплює суміжні питання щодо захисту конвеєрів розгортання.

"Що таке ApplicationSet і коли його застосовувати?"

ApplicationSet — це контролер, що генерує ресурси Application ArgoCD на основі шаблонів. Він використовує генератори (cluster, Git directory, list, matrix, merge) для створення множини Applications з однієї дефініції. Типові сценарії застосування включають розгортання одного застосунку на всі production-кластери, генерацію окремих Applications для кожного орендаря у multi-tenant SaaS-платформі, або створення Applications для кожної директорії у monorepo.

Висновки

• ArgoCD 3.4 (травень 2026) додає призупинення reconciliation та Helm value globs, що відповідає потребам Day 2 операцій для production Kubernetes-кластерів
• Pull-based модель GitOps усуває необхідність відкривати credentials кластера для CI-інструментів, зберігаючи секрети в межах кластера
• Sync waves та hooks вирішують проблему порядку розгортання: міграції до подів застосунку, ConfigMaps до Deployments, очищення після видалення
• ApplicationSets автоматизують multi-cluster розгортання, генеруючи ресурси Application на основі міток кластерів, Git-директорій або довільних списків
• Відокремлення конфігураційного репозиторію від репозиторію застосунку забезпечує чистішу Git-історію, незалежні цикли ревю та простіші тригери CI
• ArgoCD підходить для централізованого multi-cluster управління завдяки dashboard та RBAC; Flux оптимальний для розподілених середовищ з обмеженими ресурсами або високою залежністю від Helm
• Підготовка до GitOps-співбесід має охоплювати виявлення дрейфу, стратегії синхронізації, сценарії відмов та конкретні production-приклади, а не заучені визначення