ARGOCD
IM PRODUKTIVBETRIEB.
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.
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, ändert den Betrieb aber grundlegend: der gewünschte Zustand steht im Repo, nicht im Kopf einzelner Leute.
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; 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
- Secrets nicht in Git: wir provisionieren Secrets über HashiCorp Vault. Klartexte gehören nicht ins Repo.
- Sync Waves sind unverzichtbar: wenn ein Operator vor seinen CRDs deployed wird, schlägt das Apply fehl.
- Reconciliation-Intervall: der Default von drei Minuten passt für die meisten Workloads. Wer schneller reagieren muss, nutzt Git-Webhooks statt das Polling-Intervall zu verkürzen, sonst belasten Sie API und Repo unnötig.
- 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.