Plattformentscheidung

Argo CD oder Flux: Welches GitOps-Werkzeug zu deinem Team passt

Sollen Entwicklungsteams selbst ausrollen und dabei sehen, was im Cluster wirklich steht, führt kaum ein Weg an Argo CD vorbei. Betreibt dagegen ein kleines Plattformteam die Cluster und soll GitOps möglichst wenig eigene Angriffsfläche mitbringen, ist Flux die ruhigere Wahl. Beide sind bei der CNCF im Graduated-Status, beide lösen dasselbe Problem, und in größeren Häusern laufen sie oft nebeneinander.

6 Kapitel mit allen Befehlen

Passende Kurse ansehen Persönlich beraten lassen

Zwei IT-Entscheider vergleichen Plattformoptionen an einem großen Bildschirm

Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team

Worum es geht

Warum der Push aus der Pipeline irgendwann bricht

Am Anfang steht fast immer derselbe Aufbau: Die Pipeline baut ein Image, meldet sich am Cluster an und ruft am Ende ein <code>kubectl apply</code> auf. Das funktioniert, solange es einen Cluster, eine Umgebung und ein Team gibt. Danach fängt es an zu bröckeln. Das CI-System hält dauerhaft gültige Zugangsdaten für die Produktion, jeder Runner ist damit ein lohnendes Ziel, und niemand kann zuverlässig sagen, welche Version gerade läuft. Die Pipeline kennt nur den letzten Lauf, nicht den Zustand.

Dazu kommt die Abweichung, die sich im Betrieb ganz von selbst einstellt. Jemand skaliert nachts ein Deployment hoch, jemand anders setzt schnell ein Label, ein drittes Team schiebt einen Hotfix per Hand. Nichts davon steht in Git, und beim nächsten regulären Ausrollen verschwindet es kommentarlos oder bleibt als Leiche stehen. Wer im Fehlerfall fragt, was sich zwischen Freitag und Montag geändert hat, bekommt keine belastbare Antwort. Für ein Audit ist dieser Zustand nicht mehr darstellbar.

GitOps dreht die Richtung um. Der Sollzustand liegt vollständig und versioniert in einem Repository, ein Agent im Cluster zieht ihn und gleicht ihn laufend ab. Damit wandern die Cluster-Zugangsdaten aus dem CI-System heraus, Abweichungen werden sichtbar oder automatisch korrigiert, und ein Rollback ist ein Revert. Kostenlos ist der Umbau trotzdem nicht: Repository-Aufbau, Secrets und der Weg einer Änderung von der Testumgebung in die Produktion wollen entschieden werden, bevor der erste Controller läuft.

Miniatur-Szene: zwei Plattformen nebeneinander mit unterschiedlichen Cloud-Bausteinen, dazwischen eine Waage

Der GitOps-Kreislauf in sechs Schritten

01 Änderung als Merge Request im Konfigurations-Repository
02 Review und Merge, der Sollzustand ist damit versioniert
03 Agent im Cluster zieht den neuen Stand aktiv ab
04 Abgleich mit dem Ist-Zustand, Abweichungen werden korrigiert
05 Status zurück an Git, Meldung in Chat oder Ticket
06 Rollback ist ein Revert, kein gesonderter Prozess

Was du mitnimmst

Was die beiden Werkzeuge jeweils gut können

Argo CD und Flux sind sich in der Funktion näher, als die Diskussionen vermuten lassen. Die Unterschiede liegen im Bedienmodell, im Umgang mit Secrets und darin, wie viel Plattform du selbst bauen willst.

Argo CD: Oberfläche und Selbstbedienung

Argo CD bringt eine Weboberfläche mit, die den Ressourcenbaum jeder Anwendung samt Abweichungen und Sync-Historie zeigt. Genau das brauchst du, wenn Entwicklungsteams ohne Cluster-Zugriff sehen sollen, warum ihr Rollout hängt. Dazu kommen Anmeldung über den vorhandenen Identitätsanbieter, feingranulare Rechte über AppProjects und ein CLI, das dieselben Aktionen skriptbar macht.

Flux: Controller statt Anwendung

Flux ist eine Sammlung kleiner Controller mit eigenen Custom Resources: Quelle, Kustomization, HelmRelease, Benachrichtigung, Image-Automatisierung. Es gibt keine zentrale Anwendung, die man absichern und hochverfügbar halten müsste, und keine eigene Rechteverwaltung, weil alles über Kubernetes-RBAC läuft. Das macht Flux zur naheliegenden Wahl für Plattformbestandteile und für Cluster, die niemand interaktiv bedient.

Secrets sind der eigentliche Unterschied

Flux entschlüsselt SOPS-Dateien direkt im Kustomize-Controller, ein Age-Schlüssel im Cluster genügt. Bei Argo CD brauchst du dafür einen zusätzlichen Baustein, meist den External Secrets Operator oder Sealed Secrets. Beides ist tragfähig, aber Flux ist hier ohne Zusatzteile einsatzbereit, und das entscheidet die Werkzeugfrage in kleinen Teams häufiger als jede Oberfläche.

Helm und Kustomize sauber verbinden

Beide Werkzeuge beherrschen Helm und Kustomize, gehen aber unterschiedlich vor. Flux behandelt ein HelmRelease als eigene Ressource mit Werten aus ConfigMaps oder Secrets. Argo CD rendert Charts standardmäßig zu reinem YAML und verwaltet das Ergebnis. Wer Helm-Hooks oder Chart-Tests nutzt, sollte diesen Unterschied vor der Entscheidung testen statt danach.

Rollback und Nachweisführung

In beiden Fällen ist der saubere Rückweg ein Revert im Repository, weil sonst der Agent die Änderung sofort wieder überschreibt. Argo CD kann zusätzlich gezielt auf eine frühere Sync-Version zurückspringen, was in der Störung Minuten spart. Für die Nachweisführung zählt die Git-Historie: Wer hat wann welche Änderung freigegeben, und wann hat der Cluster sie übernommen.

Beides zusammen ist kein Widerspruch

In größeren Plattformen ist die Kombination verbreitet: Flux rollt die Plattformbestandteile aus, also Ingress, Zertifikate, Monitoring und Richtlinien, während Argo CD die Anwendungen der Fachteams verwaltet und ihnen die Oberfläche gibt. Wichtig ist nur, dass für jede Ressource eindeutig ein Werkzeug zuständig ist, sonst korrigieren sich zwei Controller gegenseitig.

Tutorial

GitOps von der Werkzeugwahl bis zum ersten Rollback

Sollen Entwicklungsteams selbst ausrollen und dabei sehen, was im Cluster steht, führt der Weg zu Argo CD, betreibt ein kleines Plattformteam die Cluster, ist Flux die ruhigere Wahl. Entschieden wird das am Umgang mit Secrets und am Bedienmodell, nicht an der Funktionsliste. Die Kapitel arbeiten das der Reihe nach ab: prüfen, ob GitOps für euren Zuschnitt trägt, an harten Kriterien vergleichen, das Repository aufbauen, beide Werkzeuge einrichten und mit Secrets und geübtem Rollback abschließen.

Schritt 1: Klären, ob GitOps überhaupt das richtige Modell ist

GitOps löst ein Problem, das erst ab einer gewissen Größe weh tut. Bevor du Werkzeuge vergleichst, prüfe die Voraussetzungen im eigenen Haus.

Der Umbau lohnt sich, sobald mehr als ein Mensch am Cluster arbeitet und mehr als eine Umgebung existiert. Ab da zahlt sich die Richtungsumkehr aus: Der Cluster zieht seinen Sollzustand selbst, statt ihn von außen zugeschoben zu bekommen. Betreibt ihr genau einen Cluster mit einer Handvoll Deployments, ist der Aufwand größer als der Nutzen, dann reicht ein sauberes Deployment aus der bestehenden Pipeline. Ob Kubernetes für euren Fall überhaupt die richtige Grundlage ist, gehört ohnehin eine Ebene davor entschieden.

Was vor dem ersten Controller stehen muss

Ein eigenes Repository für die Konfiguration, getrennt vom Anwendungscode
Eine Namenskonvention für Umgebungen, Namespaces und Cluster, die ihr durchhaltet
Ein Weg für Secrets, der ohne Klartext in Git auskommt
Geklärte Zuständigkeit: Wer darf in die Produktionsverzeichnisse mergen?
Container-Images mit unveränderlichen Tags oder Digests statt latest

Schritt 2: An harten Kriterien vergleichen statt an Geschmack

Die folgenden Punkte entscheiden die Werkzeugfrage in der Praxis. Alles andere lässt sich später nachrüsten.

Argo CD und Flux nebeneinander

Kriterium	Argo CD	Flux
Bedienung	Weboberfläche mit Ressourcenbaum, dazu CLI	Ausschließlich CLI und Kubernetes-Ressourcen
Rechte	Eigene Rechteverwaltung über AppProjects, Anmeldung über SSO	Kubernetes-RBAC, Mandantentrennung über ServiceAccounts
Secrets	Zusatzbaustein nötig, meist External Secrets oder Sealed Secrets	SOPS ab Werk im Kustomize-Controller
Image-Aktualisierung	Separates Projekt Argo CD Image Updater	Eingebaut über Image-Reflector und Image-Automation
Betriebsaufwand	Eine zentrale Anwendung, die verfügbar bleiben muss	Mehrere kleine Controller, kein zentraler Dienst
Mehrere Cluster	Ein Argo CD verwaltet viele Cluster von außen	Je Cluster eine eigene Flux-Installation
Rollback	Sprung auf eine frühere Sync-Version per Befehl möglich	Revert im Repository, alternativ Anhalten der Kustomization
Einstieg für Fachteams	Niedrig, weil der Zustand sichtbar ist	Höher, weil alles über kubectl und Logs läuft

Als Faustregel: Je mehr Menschen ohne Cluster-Zugriff wissen müssen, was gerade ausgerollt wird, desto eher Argo CD. Je stärker die Plattform selbst deklarativ verwaltet wird und je kleiner das betreibende Team, desto eher Flux. Wenn ihr gerade erst einen goldenen Pfad aufbaut, ist die Kombination aus Flux für die Plattform und Argo CD für die Fachanwendungen ein gangbarer Zielzustand, aber kein guter Startpunkt.

Schritt 3: Das Konfigurations-Repository aufbauen

Der Aufbau des Repositories entscheidet später über Freigaben, Rechte und darüber, wie eine Änderung von der Testumgebung in die Produktion wandert.

Aufbau mit Kustomize-Overlays je Umgebung

cluster-config/
  base/
    shop-api/
      deployment.yaml
      service.yaml
      kustomization.yaml
  overlays/
    test/
      kustomization.yaml        # patcht Replikas, Ressourcen, Hostnamen
      image-tag.yaml
    prod/
      kustomization.yaml
      image-tag.yaml
  platform/
    ingress-nginx/
    cert-manager/
    kube-prometheus-stack/
  clusters/
    test/
    prod/

Der Ordner clusters/ enthält nur die Einstiegspunkte, also welche Verzeichnisse ein Cluster überhaupt anwendet. Damit lässt sich eine Umgebung stilllegen, ohne die Anwendungsdefinitionen anzufassen.

Eine Änderung läuft damit immer denselben Weg: Merge Request gegen overlays/test/, prüfen, dann derselbe Bildtag in overlays/prod/. Genau dieser zweite Merge Request ist die Freigabe, die euer Prüfer sehen will. Wer stattdessen einen Branch je Umgebung nutzt, bekommt Merge-Konflikte zwischen Umgebungen und verliert die klare Zuordnung von Freigabe zu Ausrollzeitpunkt.

Schritt 4: Flux einrichten und den ersten Abgleich fahren

Flux schreibt sich beim Bootstrap selbst in das Repository. Ab dann verwaltet sich der Controller über denselben Weg wie alles andere.

Flux in den Cluster bringen

flux check --pre

# Variante GitHub, legt Repo-Inhalt und Deploy Key selbst an
flux bootstrap github \
  --owner=meine-orga \
  --repository=cluster-config \
  --branch=main \
  --path=./clusters/prod \
  --personal=false

# Variante selbst gehostetes Git ueber SSH
flux bootstrap git \
  --url=ssh://git@gitlab.intern/plattform/cluster-config.git \
  --branch=main \
  --path=./clusters/prod \
  --private-key-file=/root/.ssh/flux_ed25519

Der Bootstrap committet die Flux-Manifeste unter dem angegebenen Pfad. Ab diesem Moment aktualisiert Flux sich selbst über Git, ein manuelles Upgrade per flux install ist nicht mehr nötig.

clusters/prod/apps.yaml

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: apps
  namespace: flux-system
spec:
  interval: 1m
  url: ssh://git@gitlab.intern/plattform/cluster-config.git
  ref:
    branch: main
  secretRef:
    name: flux-system
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: apps-prod
  namespace: flux-system
spec:
  interval: 10m
  retryInterval: 2m
  timeout: 5m
  path: ./overlays/prod
  prune: true
  wait: true
  sourceRef:
    kind: GitRepository
    name: apps

wait: true lässt Flux warten, bis die Ressourcen bereit sind, statt den Abgleich sofort als erfolgreich zu melden. Ohne diese Einstellung sieht ein fehlgeschlagenes Rollout in der Statusabfrage grün aus.

Status prüfen und gezielt eingreifen

flux get kustomizations --watch
flux get sources git

# Sofort abgleichen, ohne auf das Intervall zu warten
flux reconcile kustomization apps-prod --with-source

# Waehrend einer Stoerung den Abgleich anhalten
flux suspend kustomization apps-prod
flux resume  kustomization apps-prod

flux logs --level=error --all-namespaces

flux suspend ist das Werkzeug für den Störfall: Der Controller hört auf, Handänderungen zurückzudrehen, bis ihr wieder freigebt. Notier dir, dass ein angehaltener Abgleich nach der Störung auch wieder aufgehoben werden muss.

Schritt 5: Argo CD einrichten, mit Projekt und Rechten

Argo CD ist eine zusätzliche Anwendung im Cluster. Sie braucht eine Anmeldung, eine Rechtegrenze je Team und eine feste Version.

Installation und erster Zugang

kubectl create namespace argocd

# Version bewusst festnageln statt stable zu verwenden
kubectl apply -n argocd \
  -f https://raw.githubusercontent.com/argoproj/argo-cd/v3.0.6/manifests/install.yaml

kubectl -n argocd rollout status deploy/argocd-server

# Startpasswort des lokalen Admins auslesen
argocd admin initial-password -n argocd

argocd login argocd.intern.example --sso
argocd app list

Nach der Anmeldung über den Identitätsanbieter gehört der lokale Admin-Zugang deaktiviert. Solange er aktiv ist, hängt der Vollzugriff auf alle Cluster an einem einzigen Passwort im Namespace argocd.

Projektgrenze und Anwendung

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: shop
  namespace: argocd
spec:
  sourceRepos:
    - ssh://git@gitlab.intern/plattform/cluster-config.git
  destinations:
    - server: https://kubernetes.default.svc
      namespace: shop-*
  clusterResourceWhitelist: []      # keine clusterweiten Objekte fuer dieses Team
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: shop-prod
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: shop
  source:
    repoURL: ssh://git@gitlab.intern/plattform/cluster-config.git
    targetRevision: main
    path: overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: shop-prod
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Das AppProject ist die eigentliche Sicherheitsgrenze. Ohne clusterResourceWhitelist kann ein Team über sein eigenes Repository ClusterRoles anlegen und sich damit selbst Rechte geben.

selfHeal: true ist mächtig und unbequem zugleich. Der Controller dreht jede Handänderung im Cluster innerhalb von Sekunden zurück, auch die in der Nacht um drei. Das ist genau der gewünschte Effekt, aber es kollidiert mit allem, was Ressourcen zur Laufzeit verändert, etwa einem HorizontalPodAutoscaler auf dem Feld replicas. Nimm solche Felder mit ignoreDifferences aus dem Abgleich heraus, statt die Selbstheilung abzuschalten.

Schritt 6: Secrets aus Git heraushalten, Rollback üben

Der Sollzustand liegt vollständig in Git, Passwörter dürfen es nicht. Und ein Rollback, den niemand geübt hat, ist keiner.

SOPS mit age für Flux

age-keygen -o age.agekey                # public key merken

kubectl -n flux-system create secret generic sops-age \
  --from-file=age.agekey=age.agekey

sops --encrypt \
  --age age1qz9k8x2v0h7m4t6r3s5w1n8p2d4f6g8j0l2q4y6u8i0o2a4b6c8 \
  --encrypted-regex '^(data|stringData)$' \
  --in-place overlays/prod/db-credentials.yaml

git add overlays/prod/db-credentials.yaml
git commit -m 'DB-Zugang rotiert'

Nur die Werte unter data und stringData werden verschlüsselt, Name und Namespace bleiben lesbar. Das ist Absicht: Der Merge Request bleibt prüfbar, ohne dass jemand die Geheimnisse sieht.

Entschlüsselung in der Kustomization aktivieren

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: apps-prod
  namespace: flux-system
spec:
  interval: 10m
  path: ./overlays/prod
  prune: true
  sourceRef:
    kind: GitRepository
    name: apps
  decryption:
    provider: sops
    secretRef:
      name: sops-age

Bei Argo CD gibt es dieses Feld nicht. Dort führt der übliche Weg über den External Secrets Operator, der die Werte zur Laufzeit aus Azure Key Vault, AWS Secrets Manager oder Vault zieht. In Git steht dann nur noch der Verweis auf den Namen des Geheimnisses.

Rollback in beiden Welten

# Argo CD: schnell zurueck auf eine frueher erfolgreiche Version
argocd app history shop-prod
argocd app rollback shop-prod 42
argocd app set shop-prod --sync-policy none     # sonst zieht selfHeal sofort nach

# Der saubere Weg in beiden Welten: Revert im Repository
git revert --no-edit 9f3c1ab
git push origin main
flux reconcile kustomization apps-prod --with-source

Ein argocd app rollback ohne das Abschalten der automatischen Synchronisierung hält nur Sekunden, danach setzt der Controller wieder den Stand aus Git. Deshalb ist der Revert der eigentliche Rollback und der Befehl nur die Überbrückung.

Vor dem ersten Produktivcluster abhaken

Zugriff auf das Konfigurations-Repository auf Merge Requests mit Freigabe beschränkenWer direkt auf den Hauptzweig schreiben darf, rollt an jeder Freigabe vorbei aus. Das Repository ist ab jetzt der Produktionszugang.
Für jede Ressourcenart genau ein Werkzeug als zuständig festlegenVerwalten Flux und Argo CD dieselbe Ressource, korrigieren sie sich gegenseitig im Sekundentakt und erzeugen dabei API-Last und endlose Ereignisprotokolle.
Benachrichtigung bei fehlgeschlagenem Abgleich in Chat oder Ticketsystem legenOhne Meldung bleibt ein gescheiterter Rollout wochenlang unbemerkt, weil in Git ja alles richtig aussieht.
Wiederherstellung des Clusters aus dem Repository einmal vollständig durchspielenErst dieser Test zeigt, was nicht in Git steht: CRDs, Zertifikate, persistente Daten und von Hand angelegte Namespaces.
Ablauf für den Notfall schriftlich festhalten, inklusive Anhalten und WiederaufnehmenIn der Störung sucht sonst jemand unter Zeitdruck die richtige Reihenfolge, und ein halb angehaltener Abgleich verlängert den Ausfall.

Passende Kurse

Kurse zu GitOps mit Argo CD und Flux bei cmt

Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.

IaC mit KI: Terraform & GitOps sauber skalieren 3 Tage Präsenz nächster Termin 26.10.2026 Zum Kurs Platform Engineering: Goldener Pfad Grundkurs 2 Tage Präsenz nächster Termin 03.09.2026 Zum Kurs Kubernetes Grundkurs 3 Tage Präsenz oder Live-Online nächster Termin 03.08.2026 Garantietermin Zum Kurs Helm Schulung und Customization Training für Kubernetes 2 Tage Präsenz nächster Termin 19.11.2026 Zum Kurs Continuous Integration und Delivery mit GitLab 3 Tage Präsenz oder Live-Online nächster Termin 10.08.2026 Garantietermin Zum Kurs Crossplane Schulung: Kubernetes Control Plane 3 Tage Präsenz nächster Termin 21.09.2026 Zum Kurs

Unverbindlich beraten lassen Alle Cloud-Native-Kurse ansehen

Wissen prüfen

Teste dich und finde deinen Weg

Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.

Wissenstest Kubernetes Grundlagen Quiz Teste dein Wissen zu Pods, Deployments, Services, ConfigMaps, kubectl und der Cluster-Architektur. Quiz starten Wissenstest Git Grundlagen Quiz Teste dein Wissen zu Branching, Merging, Remote Repositories, Stash und Git-Workflows. Quiz starten

Gut zu wissen

Häufige Fragen zu GitOps mit Argo CD und Flux

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt

Kann ich Argo CD und Flux gleichzeitig betreiben?

Ja, und in größeren Plattformen ist das sogar verbreitet. Üblich ist die Aufteilung nach Zuständigkeit: Flux rollt die Plattformbestandteile aus, also Ingress-Controller, Zertifikatsverwaltung, Monitoring und Richtlinien, während Argo CD die Anwendungen der Fachteams verwaltet und ihnen die Oberfläche für den Ist-Zustand gibt. Die einzige harte Regel lautet, dass für jede einzelne Ressource genau ein Werkzeug zuständig sein muss. Verwalten beide dasselbe Deployment, überschreiben sie sich gegenseitig im Sekundentakt und erzeugen dabei erhebliche Last auf dem API-Server.

Wie kommen Passwörter in den Cluster, wenn alles in Git steht?

Es gibt drei etablierte Wege. SOPS verschlüsselt die Werte in der YAML-Datei, Flux entschlüsselt sie im Cluster mit einem Age-Schlüssel, und der Merge Request bleibt trotzdem lesbar. Sealed Secrets funktioniert ähnlich mit einem clusterseitigen Schlüsselpaar. Der External Secrets Operator geht einen anderen Weg und holt die Werte zur Laufzeit aus Azure Key Vault, AWS Secrets Manager oder Vault, in Git steht dann nur der Verweis. Für Argo CD ist der External Secrets Operator die gängigste Wahl, für Flux SOPS, weil es dort ohne Zusatzteile funktioniert.

Was passiert, wenn jemand von Hand am Cluster arbeitet?

Das hängt an einer Einstellung. Mit aktiver Selbstheilung dreht der Controller die Änderung innerhalb weniger Sekunden bis Minuten zurück, ohne Selbstheilung wird sie als Abweichung angezeigt und bleibt bestehen. Für die Produktion ist die Selbstheilung die richtige Wahl, weil sie den Zustand ehrlich hält. Für den Störfall braucht ihr dann aber einen definierten Weg, den Abgleich kurzzeitig anzuhalten, in Flux über das Anhalten der Kustomization, in Argo CD über das Abschalten der automatischen Synchronisierung.

Wie sieht ein Rollback im Prüfungsfall aus?

Der belastbare Rollback ist ein Revert des betreffenden Commits im Konfigurations-Repository, gefolgt von einem erzwungenen Abgleich. Damit ist der Rückweg dokumentiert wie jede andere Änderung, mit Zeitstempel, Urheber und Freigabe. Die Sprungfunktion von Argo CD auf eine frühere Sync-Version ist schneller, hält aber nur, wenn ihr gleichzeitig die automatische Synchronisierung abschaltet, sonst setzt der Controller den Stand aus Git wieder durch. Für ein Audit zählt am Ende die Git-Historie, nicht der Befehl.

Brauche ich für GitOps zwingend Helm oder reicht Kustomize?

Kustomize reicht für eigene Anwendungen fast immer und ist deutlich leichter zu lesen, weil es ohne Templatesprache auskommt. Helm brauchst du dort, wo ihr fremde Software installiert, denn Ingress-Controller, Datenbankoperatoren und Monitoring-Stacks werden praktisch nur als Chart ausgeliefert. Die verbreitete Aufteilung lautet deshalb: Fremdsoftware als Helm-Release, eigene Anwendungen als Kustomize-Basis mit Overlays je Umgebung. Beide Werkzeuge beherrschen beides, gehen bei Helm-Hooks und Chart-Tests aber unterschiedlich vor, das gehört vor der Entscheidung getestet.

Quellen

Zuletzt geprüft am 28. Juli 2026.

Echte Stimmen aus unseren IT-Kursen

“

Sehr kompetenter Dozent der gut auf alle Fragen eingegangen ist.

Rückmeldung aus dem Kurs „Kubernetes Grundkurs“

“

Der Trainer konnte die Inhalte sehr gut vermitteln. Ich habe dabei viel gelernt.

Rückmeldung aus dem Kurs „Monitoring mit Prometheus und Grafana - Grundkurs“

Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Cloud-Programm den passenden Kurs oder Lernpfad zu finden.

0800 71 20000 E-Mail

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.