Start/News/GitOps mit ArgoCD
PLATFORM · 11 Min. Lesezeit · Engineering-Notes

ARGOCD
IM PRODUKTIV­BETRIEB.
DREI PLATTFORMEN
PARALLEL.

Wir betreuen mittlerweile drei OpenShift-Plattformen verschiedener Kunden über ein zentrales ArgoCD-Setup. App-of-Apps Pattern, klare Mandantentrennung, alles deklarativ in Git. Lessons Learned aus 18 Monaten produktivem Betrieb.

GIT Source of Truth app-of-apps ARGOCD Sync · Pull · Diff Multi-Cluster Federation CLUSTER · KUNDE ACLUSTER · KUNDE BCLUSTER · KUNDE C App-of-Apps mit drei Kunden-Clustern. Eine ArgoCD-Instanz, deklarative Manifeste in Git, getrennte Namespaces pro Mandant.

Wenn Sie sich noch nicht mit GitOps beschäftigt haben: Die zentrale Idee ist simpel. Statt einen Cluster mit kubectl apply zu füttern, schreiben Sie alles, was er machen soll, in ein Git-Repo. Ein Agent im Cluster zieht die Manifeste, vergleicht mit dem Ist-Zustand, gleicht ab. Das war's. Klingt nach wenig — ist aber operativ ein Quantensprung.

01 UNSER SETUP

Wir betreiben eine zentrale ArgoCD-Instanz in unserem Datacenter Wien. Sie verwaltet drei OpenShift-Cluster bei drei verschiedenen Kunden — physisch und logisch getrennt, aber operativ aus einem Hub heraus. Das spart uns drei Sets von Operator-Updates, drei Sets von Backup-Konfigurationen, drei Sets von Audit-Loggern.

Die Mandantentrennung läuft über drei Mechanismen:

  • ArgoCD AppProject — definiert, welche Repos, welche Cluster und welche Namespaces ein Mandant sehen darf.
  • OpenShift Namespace Quotas — pro Mandant CPU, Memory, Storage gedeckelt.
  • Network Policies — Default Deny, explizite Erlaubnisse pro Service.

02 APP-OF-APPS

Das Pattern haben wir adoptiert, weil es die Hierarchie der Manifeste sauber widerspiegelt: ein Root-Application-Manifest pro Cluster, das wiederum Child-Applications anlegt, die dann die eigentlichen Workloads deployen. Klingt nach Über-Abstraktion, ist es aber nicht — denn jedes Level dieser Hierarchie ist ein klarer Eskalations- und Rollback-Punkt.

# Root-App pro Cluster
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: root-cluster-a
spec:
  source:
    repoURL: 'https://git.egw-int/cluster-a.git'
    path: 'apps'
  destination:
    server: 'https://kubernetes.default.svc'

03 WAS WIR GELERNT HABEN

  • Sealed Secrets über externes Secrets-Tooling — wir nutzen HashiCorp Vault für Secrets-Provisioning. Klartexte gehören nicht in Git.
  • Sync Waves sind unverzichtbar — wenn ein Operator vor seinen CRDs deployed wird, bricht alles.
  • Reconciliation-Intervall sollte auf 3 Minuten gesetzt sein, nicht den Default von 3 Sekunden. Sonst hämmern Sie die API.
  • Manueller Drift wird unweigerlich passieren. Auto-Sync und Self-Heal in Prod aktivieren — sonst läuft Ihre Source of Truth auseinander.

04 FAZIT

Nach 18 Monaten produktivem Betrieb: GitOps hat unsere Cluster-Operations leiser gemacht. Weniger 3-Uhr-Anrufe wegen "irgendwer hat irgendwas geändert". Mehr Zeit für die Themen, die wirklich Architektur-Arbeit erfordern.

Wenn Sie eine OpenShift- oder Kubernetes-Plattform betreiben oder bauen wollen, sprechen Sie mit uns — Kontakt-Seite oder telefonisch +43 (0)1 235 1277.