GitOps und Progressive Delivery — Sicheres Deployment 2026

Kubectl apply in Produktion? Bitte nicht. 2026 ist GitOps der De-facto-Standard für Kubernetes-Deployment. Und Progressive-Delivery-Strategien stellen sicher, dass selbst ein fehlerhaftes Release die Produktion nicht lahmlegt. Wie funktioniert das Ganze in der Praxis?

Was ist GitOps und warum es gewonnen hat¶

GitOps ist ein Betriebsmodell, bei dem Git die Single Source of Truth für Infrastruktur und Anwendungskonfiguration ist. Der deklarative Zustand in Git wird automatisch mit der Zielumgebung synchronisiert. Keine imperativen Befehle, keine manuellen Eingriffe.

2026 haben über 70 % der Organisationen, die Kubernetes betreiben, GitOps eingeführt. Der Grund ist klar — Audit Trail, Rollback mit einem einzigen git revert und Eliminierung von „wer hat was wo geändert.”

Argo CD vs Flux — Tool-Auswahl¶

• Argo CD: Reichhaltige UI, anwendungszentriertes Modell, starke Dependency-Graph-Visualisierung. CNCF Graduated.
• Flux v2: Controller-basierte Architektur, modular. Besser für Plattform-Teams. Native OCI-Artefakt-Unterstützung.

In der Praxis: Argo CD für Anwendungsteams, Flux für Plattform-Teams. Beide funktionieren hervorragend.

Repository-Strategie¶

• Monorepo: Alles in einem Repository. Einfacher für kleine Teams.
• Getrenntes Config-Repo: Anwendungscode in einem Repo, Kubernetes-Manifeste in einem anderen. Häufigstes Enterprise-Pattern.
• Repo pro Umgebung: Separate Repositories für Dev, Staging, Produktion. Maximale Isolation.

Unsere Empfehlung: Getrenntes Config-Repo mit Kustomize-Overlays für umgebungsspezifische Konfigurationen.

Progressive Delivery — Jenseits von Blue-Green¶

GitOps stellt sicher, dass Deployment reproduzierbar und auditierbar ist. Progressive Delivery stellt sicher, dass es sicher ist:

• Blue-Green Deployment: Zwei identische Umgebungen. Traffic wird auf einmal umgeschaltet. Schnelles Rollback, aber doppelte Ressourcen erforderlich.
• Canary Deployment: Die neue Version erhält schrittweise steigenden Traffic-Anteil (1 % → 5 % → 25 % → 100 %). Metriken entscheiden über Fortfahren oder Rollback.
• A/B Testing: Verschiedene Versionen für verschiedene Nutzersegmente.
• Feature Flags: Code wird deployt, aber das Feature ist hinter einem Flag versteckt. Schrittweiser Rollout ohne neues Deployment.

Canary in der Praxis mit Argo Rollouts¶

Argo Rollouts ist ein Kubernetes-Controller, der die Standard-Deployment-Ressource ersetzt und Progressive-Delivery-Strategien hinzufügt:

• Schritt 1: Neue Version mit 5 % Traffic. Automatische Metrikanalyse (Erfolgsrate, Latenz, Fehlerrate) für 5 Minuten.
• Schritt 2: Wenn Metriken bestehen, Traffic auf 25 % erhöhen.
• Schritt 3: 50 % Traffic. Hier ist ein Human Approval Gate für kritische Services angebracht.
• Schritt 4: 100 % Traffic. Canary wird zur neuen stabilen Version.

Schlüssel: Automatische Metrikanalyse entscheidet über Promotion oder Rollback. Integration mit Prometheus, Datadog, New Relic. Wenn die Fehlerrate den Schwellenwert überschreitet, erfolgt automatisches Rollback — ohne menschliches Eingreifen.

Service Mesh und Traffic Management¶

• Istio: Vollständigste Lösung. VirtualService für Traffic Splitting. Aber: hohe Komplexität.
• Linkerd: Leichtgewichtige Alternative. Rust-basierter Proxy, niedrige Latenz.
• Gateway API + NGINX/Envoy: Ohne vollständiges Service Mesh. Einfachster Weg für Canary.

Feature Flags — Deployment ≠ Release¶

Deployment von Release zu trennen ist ein Game Changer:

• Trunk-based Development: Alles geht in main, unfertige Features sind hinter einem Flag.
• Schrittweiser Rollout: Feature für 1 % der Nutzer aktivieren, Impact messen, schrittweise erweitern.
• Kill Switch: Ein problematisches Feature sofort deaktivieren, ohne neues Deployment.
• Targeting: Feature für ein bestimmtes Kundensegment, Region oder Umgebung.

Tools: LaunchDarkly (Enterprise), Unleash (Open-Source, Self-Hosted), OpenFeature (herstellerneutraler SDK-Standard). Für tschechische Unternehmen empfehlen wir oft Unleash — Self-Hosted, DSGVO-freundlich, ausreichend robust.

Observability-gestütztes Deployment¶

Progressive Delivery ohne Observability ist wie Fahren mit verbundenen Augen:

• Golden Signals: Latenz, Traffic, Fehlerrate, Sättigung — für jeden Service.
• SLO-basierte Promotion: Canary fährt nur fort, wenn SLOs eingehalten werden.
• Deployment-Marker: Annotationen in Grafana/Datadog zeigen, wann ein Deployment stattfand.
• Automatisches Rollback: Wenn die SLO-Burn-Rate das Limit überschreitet, rollt Argo Rollouts automatisch zurück.

Deployen Sie oft, deployen Sie sicher¶

GitOps + Progressive Delivery = öfter deployen mit geringerem Risiko. Automatische Synchronisation aus Git eliminiert Konfigurationsdrift. Canary und Feature Flags stellen sicher, dass ein fehlerhaftes Release minimale Nutzer betrifft.

Unser Tipp: Starten Sie GitOps für Non-Production-Umgebungen. Wenn das Team sich an den Workflow gewöhnt hat, erweitern Sie auf Production mit Canary Deployment. Fügen Sie Feature Flags hinzu, wo Sie Releases von Deploy-Zyklen trennen müssen.