🔴 Advanced

GitOps Toolchain — Argo CD vs Flux

GitOps mení definíciu "ako sa veci dostanú do produkcie": Git repo je single source of truth, cluster sám seba opravuje smerom k tomu, čo je v Gite. Tento článok je orientovaný na voľbu nástroja, nie na vysvetlenie samotného konceptu (k tomu pozri GitOps). Pozrieme sa na dvoch zrelých kandidátov — Argo CD a Flux v2 — a kedy ktorý dáva zmysel.

Stručne: čo robia oba nástroje

Obidva nástroje žijú vnútri Kubernetes clusteru a porovnávajú želaný stav (manifesty v Gite) so skutočným stavom (objekty v API serveri). Keď nájdu drift, buď ho ohlásia, alebo ho automaticky zaplátajú podľa nastavenia. Tým sa CI pipeline zbavuje úlohy deploy-eru a stáva sa len generátorom artefaktov + commitov.

Argo CD — architektúra

Argo CD je centralizovaná aplikácia, ktorú nasadíš do clustera (alebo do management clustera, ak chceš multi-cluster topológiu).

Hlavné komponenty:

  • argocd-server — gRPC + HTTP API + web UI (the bit users actually see).
  • argocd-repo-server — stateless worker, ktorý generuje manifesty z Git repa (Kustomize / Helm / plain YAML / Jsonnet / vlastný plugin).
  • argocd-application-controller — porovnáva Application CR s reálnym stavom v cluster-i a aplikuje zmeny.
  • argocd-applicationset-controller — generuje Application CR z templates (matica clusterov × prostredí).
  • argocd-notifications-controller — Slack / Teams / e-mail / webhook na zmenu stavu Application.

Datový tok: git push → repo-server pulls → renders manifests → controller compares → API server.

Argo CD App-of-Apps pattern

Pre väčšie prostredia sa zaviedol vzor App-of-Apps: jeden root Application, ktorý ukazuje na priečinok plný ďalších Application CR-iek. Tým dokážeš spravovať aj stovky aplikácií ako jeden git tree. Modernejšia varianta je ApplicationSet s generátormi (list, cluster, git, matrix), ktorá nahrádza ručne písané "child" Application objekty.

Flux v2 — architektúra

Flux v2 je opačný extrém — namiesto monolitickej aplikácie je to sada controller-ov, každý s jednou zodpovednosťou. Nasadíš ich cez flux install alebo flux bootstrap a žijú v flux-system namespace.

  • source-controller — ťahá zdroje (GitRepository, OCIRepository, HelmRepository, Bucket) do internej cache.
  • kustomize-controller — aplikuje Kustomization CR (vie aj plain YAML, nemusíš mať kustomization.yaml).
  • helm-controller — HelmRelease CR, beží proti renderu z source-controller-u (žiadny helm install so štátom v helm binarke).
  • notification-controller — provider/alert CR-ky, prepojené s Slack / GitHub Checks / Webhook.
  • image-reflector-controller + image-automation-controller — voliteľný pár pre image automation: skenuje registry tag-y a vie automaticky commitnúť bump verzie späť do Gitu (ImageUpdateAutomation CR).

Flux používa GitOps Toolkit SDK, ktorý je verejné API — vlastné controller-y môžu konzumovať GitRepository rovnako ako oficiálne.

Feature porovnanie

Schopnosť Argo CD Flux v2
Multi-tenant UI ✅ vstavané ❌ (CLI / CR-ky, doplnkové UI Weave GitOps alebo Capacitor)
Helm support ✅ render-only (nepoužíva Tiller / Helm release storage) ✅ plný (vlastný HelmRelease, history v cluster-i)
Kustomize support ✅ ✅
Multi-cluster z jedného controllera ✅ (registrácia kubeconfig-ov) ❌ (každý cluster má vlastný Flux; orchestrácia cez fleet/carvel/Argo CD)
ApplicationSet (matrix generator) ✅ vstavané čiastočne — kombinácia Kustomization + image automation
Image auto-update (registry → git PR/commit) ❌ (treba externý nástroj, napr. Argo CD Image Updater) ✅ priamo cez image-automation-controller
Hook-y / sync waves ✅ sync waves + sync hooks ✅ dependsOn + post-build substitution
RBAC granularita per-project, per-app per-namespace, per-CR (Kubernetes RBAC + Flux SA)
Sealed / encrypted secrets externe — SOPS, Sealed Secrets, External Secrets rovnaké externé možnosti, integrovaný SOPS dešifrovanie v Kustomization.spec.decryption
Webhook trigger ✅ /api/webhook ✅ Receiver CR (Git / Helm / Generic / Bitbucket / Quay)
Notification provider argocd-notifications notification-controller (Slack, MS Teams, GitHub Checks, generic webhook, Telegram)

Pozn.: Tabuľka je platná pre Argo CD 2.13+ a Flux 2.4+. Featurey pribúdajú rýchlo — vždy si over v príslušnom release-note.

Kedy si vybrať Argo CD

Argo CD sa najlepšie cíti v prostredí, kde:

  • chceš UI pre tímy, ktoré neradi otvárajú PR-ku len aby videli, čo sa deje;
  • riadiš veľa clusterov z jedného miesta (centrálny Argo CD + viacero cluster kubeconfig-ov);
  • máš organizačnú maticu prostredia × tenanti a ApplicationSet ti ušetrí stovky riadkov YAML;
  • chceš enforce-nuté manuálne sync (Argo CD vie zostať v OutOfSync a čakať, kým ho niekto klikne).

Typický signál: "PM-ka sa pýta, ktorá verzia je v staging-u — chcem aby si to vedela pozrieť sama".

Kedy si vybrať Flux

Flux je doma tam, kde:

  • CRD-first prístup ti vyhovuje (HelmRelease, Kustomization, ImageUpdateAutomation ako YAML, žiadne click-ops);
  • chceš automatický image bump bez externého Updater-a;
  • platform team je menší, každý cluster spravuje sám seba;
  • preferuješ GitOps Toolkit ako základ pre vlastné controllery (Flagger, Capsule, Karmada všetky stavajú na ňom);
  • chceš integrovaný SOPS dešifrovaní v Kustomization.

Typický signál: "chcem aby tag latest v ECR automaticky znamenal nový deploy, bez toho aby som tam medzi tým robil PR rukou".

Migration patterns

Z monolitického CI/CD push (Jenkins → kubectl apply) → GitOps

  1. Zafrízuj manuálne kubectl apply — najprv to musí prestať fungovať mimo Gitu, inak budeš večne riešiť drift.
  2. Reverse-engineer aktuálny stav do manifestov. kubectl get -o yaml + odstránenie status:, creationTimestamp, resourceVersion, kontrolery cleanupy. Použiteľný nástroj: konfigure alebo kubectl-neat.
  3. Importuj postupne — najprv jeden namespace, daj ho pod Argo CD / Flux, sleduj drift.
  4. Až keď je drift = 0, prepni sync na automated: { prune: true, selfHeal: true }.

Z Argo CD → Flux v2 (alebo opačne)

  • Začni paralelným nasadením druhého controllera v test cluster-i.
  • Preformuluj manifesty na Kustomize, ak ešte nie sú — obidva nástroje to vedia.
  • V starom nástroji nastav prune: false, v novom prune: false — počas tranzície bude oboje "vedieť" o objektoch, ale nezasahovať agresívne.
  • Postupne odoberaj jeden namespace zo starého a pridávaj do nového.
  • Po overení odstráň prvého a zapni prune: true na druhom.

Anti-pattern: "big-bang" prepnutie cez weekend. Vždy budeš mať jeden objekt, ktorý zabudol kto, a nový controller ho rozhodí.

Observability

Otázka Argo CD Flux v2
Synced / OutOfSync prehľad UI /applications flux get all -A + Capacitor / Weave GitOps
Drift detail UI diff viewer (živý) flux diff kustomization <name>
Audit trail argocd app history, k8s events Git history (zo source-controller-u) + k8s events
Prometheus metriky argocd-server, argocd-app-controller exportéry každý controller exportuje gotk_* metriky
Notifikácie argocd-notifications (Trigger + Template CR) notification-controller (Alert + Provider CR)

Pre obidva platí: CR-ky sú objekty v API serveri, takže ich Prometheus + alertmanager vie čítať cez kube-state-metrics ako každý iný resource.

Zhrnutie

Žiadny z týchto nástrojov nie je "lepší" v absolútnom zmysle — ide o trade-offy. Argo CD vyhráva, keď chceš central UI a multi-cluster z jedného miesta. Flux vyhráva, keď chceš čisto CRD-driven prístup a integrovanú image automatizáciu. Ak nemáš silný dôvod ani na jednu stranu, začni Fluxom (menší overhead, lepšie zapadá do platform teamu), a prejdi na Argo CD keď začneš mať väčšie organizačné požiadavky na UI a multi-tenant view.

Ďalšie zdroje