GitOps 2.0: ArgoCD vs Flux v2 для enterprise Kubernetes deployment

Привет! Я Евгений Семёнов, директор ITFresh. Знаете ли вы, что уже в 2026 году больше половины корпоративных команд – целых 64% – будут активно применять GitOps? А 81% из них, по нашим данным, подтвердят: надёжность их деплоев значительно выросла! GitOps 2.0 – это гораздо больше, чем обычный "git push для деплоя". Это полноценная платформа для сложной, но очень эффективной доставки приложений (progressive delivery), где правила прописаны как код (policy-as-code), и где можно управлять множеством кластеров одновременно (multi-cluster management). В своей работе я часто сталкиваюсь с выбором, поэтому сегодня я подробно разберу, чем же реально отличаются ArgoCD и Flux v2. Покажу на примере: как мы внедряли одно из этих решений в компании, которая работала сразу с пятнадцатью кластерами.

GitOps 2.0: эволюция от простого деплоя

Изначально, на заре своего появления, GitOps решал одну, но очень важную задачу: автоматически выкатывать код прямо из Git. И всё. Просто, правда? Но сейчас GitOps 2.0 шагнул далеко вперёд. Что же он предлагает?

• Progressive Delivery — canary, blue-green, feature flags integration
• Policy as Code — OPA Gatekeeper, Kyverno, security policies
• Multi-cluster Management — централизованное управление флотом кластеров
• Application Dependencies — управление зависимостями между сервисами
• Observability — metrics, events, audit logs для GitOps операций

ArgoCD vs Flux v2: архитектурные различия

Практический деплой ArgoCD для enterprise

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

# 1. Установка ArgoCD с HA и enterprise features
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/ha/install.yaml

# 2. Конфигурация для enterprise
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cmd-params-cm
  namespace: argocd
data:
  # Включить RBAC и SSO
  server.rbac.policy: |
    p, role:admin, applications, *, */*, allow
    p, role:developer, applications, get, */*, allow
    p, role:developer, applications, sync, */dev/*, allow
    g, argocd-admin, role:admin
  # OIDC с Keycloak
  oidc.config: |
    name: Keycloak
    issuer: https://keycloak.company.com/auth/realms/argocd
    clientId: argocd
    clientSecret: $oidc.keycloak.clientSecret
    requestedScopes: ["openid", "profile", "email", "groups"]

Application Sets для multi-cluster

С ApplicationSet вы без проблем развернёте и будете контролировать приложения сразу на куче кластеров.

# ApplicationSet для деплоя во все environments
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: microservices
  namespace: argocd
spec:
  generators:
  - clusters:
      selector:
        matchLabels:
          environment: production
  - git:
      repoURL: https://github.com/company/k8s-manifests
      revision: HEAD
      directories:
      - path: apps/*
  template:
    metadata:
      name: '{{path.basename}}-{{cluster.name}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/company/k8s-manifests
        targetRevision: HEAD
        path: '{{path}}'
        helm:
          valueFiles:
          - values-{{cluster.metadata.labels.environment}}.yaml
      destination:
        server: '{{cluster.server}}'
        namespace: '{{path.basename}}'
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

Развертывание Flux v2 для enterprise

А вот Flux v2 – это уже для тех, кто не боится командной строки и чья команда по-настоящему ценит работу через CLI. Ещё он идеален, когда производительность стоит во главе угла.

# 1. Bootstrap Flux в кластер
flux bootstrap github \
  --owner=company-org \
  --repository=k8s-fleet-config \
  --branch=main \
  --path=./clusters/production \
  --personal=false \
  --token-auth

# 2. Конфигурация multi-tenancy
# GitRepository для каждой команды
apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: GitRepository
metadata:
  name: team-backend
  namespace: team-backend
spec:
  interval: 30s
  ref:
    branch: main
  url: https://github.com/company/team-backend-config
---
# Kustomization для team deployments
apiVersion: kustomize.toolkit.fluxcd.io/v1beta1
kind: Kustomization
metadata:
  name: team-backend-apps
  namespace: team-backend
spec:
  interval: 5m
  path: "./production"
  prune: true
  sourceRef:
    kind: GitRepository
    name: team-backend

Progressive Delivery с Flagger

Flux легко подружится с Flagger, если вам нужны canary-деплои. Удобно.

# Canary deployment configuration
apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: api-service
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-service
  progressDeadlineSeconds: 60
  service:
    port: 80
    targetPort: 8080
  analysis:
    interval: 30s
    threshold: 5
    maxWeight: 50
    stepWeight: 5
    metrics:
    - name: request-success-rate
      thresholdRange:
        min: 99
      interval: 1m
    - name: request-duration
      thresholdRange:
        max: 500
      interval: 1m

Security в GitOps 2.0

Корпоративный GitOps – это не шутки. Здесь без многоуровневой системы безопасности никуда. Вы ведь не хотите сюрпризов?

• Git Security — signed commits, branch protection, secret scanning
• RBAC — role-based доступ к кластерам и приложениям
• Policy as Code — OPA Gatekeeper для runtime policies
• Image Security — container scanning, image signing с Cosign
• Secret Management — External Secrets Operator, sealed secrets

Интеграция с Policy as Code

# OPA Gatekeeper constraint для GitOps
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: requiredgitopsannotations
spec:
  crd:
    spec:
      names:
        kind: RequiredGitOpsAnnotations
      validation:
        properties:
          annotations:
            type: array
            items:
              type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package requiredgitopsannotations
        violation[{"msg": msg}] {
          required := input.parameters.annotations
          provided := input.review.object.metadata.annotations
          missing := required[_]
          not provided[missing]
          msg := sprintf("Missing required annotation: %v", [missing])
        }

Мониторинг GitOps операций

Какие же метрики стоит отслеживать, чтобы GitOps-процессы были полностью под вашим контролем и абсолютно прозрачны?

Выбор между ArgoCD и Flux v2

Выбирайте ArgoCD если:

• Когда операторы и разработчики требуют действительно 'богатый' пользовательский интерфейс.
• Вам необходимы надёжный RBAC и мульти-тенанси 'из коробки'.
• Особое значение вы придаёте готовой экосистеме, такой как Argo Workflows, Rollouts, Events.
• Если ваша команда любит централизованный подход к управлению.

Выбирайте Flux v2 если:

• Когда производительность и эффективное использование ресурсов – это прямо-таки жизненно важно.
• Разрабатываем систему? Тогда модульная архитектура — наш основной принцип. Мы прекрасно понимаем: это не просто модное слово. Ведь кто захочет возиться с монолитом, когда нужно быстро что-то поменять или масштабировать? Именно поэтому каждый компонент, каждый 'individual controller', должен работать автономно. Это позволяет легко управлять, тестировать и обновлять его отдельно от остальных частей системы. Такая структура значительно упрощает весь процесс развития проекта и его поддержку.
• Нам нужна не просто интеграция, а по-настоящему тесная! Для ITFresh это означает, что все части системы должны работать как единый организм, без малейших сбоев на стыках. Особенно это критично, когда речь заходит о внедрении новых функций или обновлений. Мы всегда делаем ставку на progressive delivery — это снижает риски и позволяет развертывать изменения постепенно, под полным контролем. А если говорить конкретнее, то активно используем Flagger для безопасного 'выкатывания' наших релизов. С ним никаких неприятных сюрпризов.
• Команда предпочитает CLI-first подход

Миграция между GitOps платформами

# Миграция ArgoCD → Flux
# 1. Export existing ArgoCD apps
argocd app list -o yaml > argocd-apps-backup.yaml

# 2. Convert to Flux Kustomizations
#!/bin/bash
for app in $(argocd app list -o name); do
  argocd app get $app -o yaml | \
  yq eval '.spec | {
    "apiVersion": "kustomize.toolkit.fluxcd.io/v1beta1",
    "kind": "Kustomization",
    "metadata": {"name": .metadata.name, "namespace": "flux-system"},
    "spec": {
      "interval": "5m",
      "path": .source.path,
      "prune": true,
      "sourceRef": {"kind": "GitRepository", "name": "main"}
    }
  }' > flux-$app.yaml
done

Можно ли использовать ArgoCD и Flux v2 одновременно?

Технически возможно, но не рекомендуется. Возникают конфликты при управлении одними ресурсами. Лучше четко разделить зоны ответственности или выбрать одну платформу для consistency.

Как обеспечить disaster recovery для GitOps?

Backup Git repositories + кластер state. ArgoCD: backup через argocd-util, restore apps из Git. Flux: bootstrap из Git автоматически восстанавливает состояние. Критично иметь infrastructure-as-code для самих кластеров.

Производительность при 1000+ приложений?

ArgoCD начинает struggles при 500+ apps, нужен sharding. Flux v2 лучше масштабируется благодаря distributed controllers. Для very large scale рассматривайте multiple ArgoCD instances или Fleet (Rancher).

Заключение

Итак, очевидно, что GitOps 2.0 к 2026 году станет де-факто стандартом для развёртывания Kubernetes в крупных компаниях. Выбираете между ArgoCD и Flux v2? Если вашей команде нужен классный интерфейс и централизованное управление, то смело берите ArgoCD. Если же важна максимальная производительность, да и команда предпочитает работать через CLI, тогда Flux v2 будет предпочтительнее. Оба решения, поверьте, уже давно зрелые и готовы к продакшену. В конечном итоге, всё сводится к культуре вашей команды и вашим конкретным требованиям. Что вам ближе?