Kubernetes CI/CD: moderne DevOps-Pipelines

GitOps, ArgoCD, Tekton und Sicherheit: der vollständige Leitfaden

Klassische CI/CD-Pipelines, Jenkins auf VMs, Deployment-Skripte über SSH, manuelle Konfiguration, erzeugen drei chronische Fehlbilder, Configuration Drift zwischen Umgebungen (Produktion weicht ohne Nachvollziehbarkeit von Staging ab), kein verlässliches Rollback (Zurückgehen verlangt manuellen Eingriff und Zustandsdiagnose) und begrenzte Skalierung (einen Jenkins-Runner hinzuzufügen heisst, eine VM bereitzustellen, das Netz zu konfigurieren und Abhängigkeiten zu installieren). Die CI/CD-Modernisierung gehört zu den am häufigsten genannten Gründen von Plattformteams für den Wechsel zu Kubernetes, neben Infrastrukturersparnis und Hochverfügbarkeit.

Kubernetes für CI/CD verändert den Ansatz grundlegend: Pipelines werden zu deklarativen Kubernetes-Ressourcen (CRDs), die Isolation greift auf Pod- statt auf VM-Ebene, und automatische horizontale Skalierung ersetzt manuelles Provisionieren. Cloud-native Werkzeuge, Tekton für CI, ArgoCD für CD, Kaniko für Builds ohne Privilegien, setzen das GitOps-Muster um, in dem Git die einzige Quelle der Wahrheit ist. Dieser Beitrag beschreibt die drei Säulen von Kubernetes-CI/CD (native Werkzeuge, GitOps, Sicherheit), zeigt Strategien zur schrittweisen Migration von Legacy-Pipelines und schlägt ein in Multi-Tenant-Produktion validiertes Vorgehen vor.

Was von Hikube kommt und was aus dem Ökosystem. Hikube liefert den CNCF-konformen Cluster, die Image-Registry und das VPC; Argo CD, Flux, Kyverno und die hier genannten Pipeline-Werkzeuge sind Ökosystem-Komponenten, die Sie selbst in Ihrem Cluster installieren und betreiben. Die Wahl liegt bei Ihnen, und keines davon ist eine Katalogfunktion. Verwalteter Umfang: Managed Kubernetes, Registry, Container Registry.

Die drei Hauptvorteile von Kubernetes für CI/CD

Die Migration von CI/CD auf Kubernetes bringt drei strukturelle Vorteile, welche die anfänglich höhere Komplexität deutlich aufwiegen.

1. Isolation und Reproduzierbarkeit: von der VM zum Pod

Klassische Jenkins-Pipelines laufen auf gemeinsam genutzten VM-Agenten, auf denen sich Abhängigkeiten (Java, Node.js, Python) über die Projekte hinweg ansammeln. Eine Pipeline, die Node 18 braucht, kann scheitern, weil der Agent zuvor einen Build mit Node 16 ausgeführt und unverträgliche globale Pakete installiert hat. Die Behebung verlangt SSH-Zugriff auf den Agenten, manuelles Aufräumen und einen Neustart, 15 bis 30 Minuten Unterbruch je Vorfall.

Kubernetes isoliert jeden Build in einem eigenen Pod mit einem bestimmten Container-Image. Die Java-Pipeline läuft in maven:3.8-openjdk-17, die Node-Pipeline in node:18-alpine, ohne Risiko gegenseitiger Verunreinigung. Der Pod endet nach dem Build und hinterlässt eine saubere Umgebung für den nächsten. Diese Isolation beseitigt die Fehlerklasse «läuft auf meinem Rechner» konstruktionsbedingt: Ein Build kann keinen Zustand mehr vom vorherigen erben.

Vergleich CI/CD: VM gegen Kubernetes-Pod

Jenkins-VM-Agent:

• Einrichtungszeit, 2-5 Minuten (Boot plus Agentenverbindung)
• Isolation, schwach (Abhängigkeiten zwischen Builds geteilt)
• Skalierung, manuell (neue VMs bereitstellen)
• Cleanup, verlangt periodische Wartung
• Kosten im Leerlauf, 24/7 bei permanenten Agenten

Kubernetes-CI-Pod:

• Einrichtungszeit, 10-30 Sekunden (Image-Pull plus Pod-Scheduling)
• Isolation, stark (eigener Pod je Build, automatisches Cleanup)
• Skalierung, automatisch
• Cleanup, beendeter Pod heisst sofort freigegebene Ressourcen
• Kosten im Leerlauf, null

Reproduzierbarkeit folgt unmittelbar aus der Isolation, Ein Build, der heute das Image app:v1.2.3 erzeugt, erzeugt morgen genau dasselbe Image, weil er im selben Container mit denselben eingefrorenen Abhängigkeiten läuft. Legacy-VM-Pipelines leiden unter zeitlichem Drift: Systemupdates, Sicherheitspatches und Werkzeuginstallationen verändern die Umgebung nach und nach und machen Builds nicht reproduzierbar.

2. Elastische Skalierung: Spitzen ohne Mehrkosten auffangen

Eine Jenkins-Pipeline mit 10 festen VM-Agenten, die etwa 30 % der Zeit tatsächlich Builds ausführen, bezahlt dennoch alle zehn rund um die Uhr. Spitzen (am Sprintende gemergte Feature-Branches mit 50 gleichzeitigen Builds) übersteigen die Kapazität, und Builds stauen sich 15 bis 45 Minuten. Die klassische Antwort: 20 permanente Agenten bereitstellen und die Kosten verdoppeln, um gelegentliche Spitzen aufzufangen.

Kubernetes-Pods entstehen und verschwinden elastisch mit der Last. Ein Cluster mit Horizontal Pod Autoscaler (HPA) hält 3 CI-Pods als Grundlast, skaliert bei Spitzen in 90 Sekunden auf 25 Pods und nach 10 Minuten Inaktivität zurück auf 3. Die Kosten spiegeln den realen Verbrauch: 3 Pods × 22 Stunden/Tag plus 25 Pods × 2 Stunden/Tag ≈ 116 Pod-Stunden/Tag gegenüber 240 VM-Stunden/Tag (10 VMs × 24 h), also 52 % Ersparnis.

Tekton, ein cloud-natives CI-Framework, nutzt diese Fähigkeiten nativ. Jeder PipelineRun erzeugt kurzlebige Pods für seine Tasks, die nach der Ausführung automatisch enden. Der Gewinn stammt aus dem Wegfall dauerhaft ungenutzter Ressourcen: Eine auf die Spitze dimensionierte Agentenflotte wird rund um die Uhr zum Spitzenwert bezahlt, ein Pod-Pool nach tatsächlich geleisteter Arbeit. Wie gross er ausfällt, hängt von Ihrem Verhältnis Spitze zu Mittel ab, rechnen Sie es an Ihren eigenen Werten.

3. GitOps: Git als einzige Quelle der Wahrheit

Klassische Pipelines arbeiten imperativ, Ein Skript führt kubectl apply -f deployment.yaml aus, ohne Gewähr, dass der Clusterzustand danach dem Git-Manifest entspricht. Manuelle Änderungen (kubectl edit deployment für dringende Hotfixes) erzeugen unsichtbaren Drift: Der Cluster weicht von Git ab, und niemand weiss genau, welche Version in Produktion läuft.

GitOps kehrt das Modell um, Git speichert den Sollzustand (Kubernetes-Manifeste), und ein Agent (ArgoCD, Flux) gleicht den Cluster fortlaufend darauf ab. Jede manuelle Änderung am Cluster wird erkannt und automatisch rückgängig gemacht (Self-Healing). Laut der CNCF-Umfrage zu Argo CD vom 24. Juli 2025 laufen knapp 60 % der von den Befragten verwalteten Kubernetes-Cluster auf Argo CD, bei einem Net Promoter Score von 79 und 97 % Produktionsnutzung gegenüber 93 % im Jahr 2023. Die Umfrage erfasst Produktionsnutzende und nennt keine Stichprobengrösse: Es ist ein Cluster-Anteil bei den Befragten, kein Marktanteil.

Die messbaren Vorteile: vollständige Nachvollziehbarkeit (jede Produktionsänderung ist ein Git-Commit mit Autor, Zeitstempel und Review), triviales Rollback (Git-Commit zurücknehmen, ArgoCD gleicht automatisch ab), vereinfachtes Disaster Recovery (den ganzen Cluster aus dem Git-Repo neu erstellen). Die MTTR sinkt zwangsläufig, sobald das Zurückrollen ein git revert auf einen bereits beschriebenen Zustand ist statt eines manuellen Wiederaufbaus: Wie stark, hängt vom Ausgangspunkt ab.

Referenzarchitektur: Tekton plus ArgoCD

Die moderne Kubernetes-CI/CD-Architektur trennt die Zuständigkeiten strikt, Tekton übernimmt CI (Build, Test, Image-Veröffentlichung), ArgoCD übernimmt CD (Deployment, Manifest-Abgleich). Diese Trennung folgt dem GitOps-Prinzip: CI deployt nie direkt, sondern committet nur Änderungen ins Git-Repo.

Tekton, cloud-natives CI

Tekton, ein Projekt der CNCF Continuous Delivery Foundation, setzt CI über Kubernetes-CRDs um. Die Kernbegriffe: Task (ein wiederverwendbarer atomarer Schritt, git clone, maven build, docker push), Pipeline (eine Folge verketteter Tasks), PipelineRun (eine konkrete Ausführungsinstanz einer Pipeline), Workspace (Speicher, den die Tasks einer Pipeline teilen).

Minimales Tekton-Pipeline-Beispiel:

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: build-and-push
spec:
  params:
    - name: git-url
      type: string
    - name: image-name
      type: string
  workspaces:
    - name: source-code
  tasks:
    - name: clone
      taskRef:
        name: git-clone          # Task aus dem Tekton-Katalog, Version 0.9
      params:
        - name: url
          value: "$(params.git-url)"
      workspaces:
        - name: output
          workspace: source-code
    - name: build-image
      taskRef:
        name: kaniko             # Build ohne Privilegien, Katalog 0.6
      runAfter:
        - clone
      params:
        - name: IMAGE
          value: "$(params.image-name)"
      workspaces:
        - name: source
          workspace: source-code

Versionen und Voraussetzungen. Das Manifest nutzt die API tekton.dev/v1, verfügbar seit Tekton Pipelines v0.44 und getragen von der 1.x-Reihe, seit August 2026 in v1.15 LTS. Beide taskRef verweisen auf Katalog-Tasks, die vor jedem Lauf im Cluster installiert sein müssen: git-clone 0.9 (Pflichtparameter url, Workspace output) und kaniko 0.6 (Pflichtparameter IMAGE, Workspace source). Installation: tkn hub install task git-clone und tkn hub install task kaniko. Nötig sind zudem ein PipelineRun, der den Workspace source-code bereitstellt, etwa über ein volumeClaimTemplate, und ein Registry-Secret für den Push. Erwartetes Ergebnis: Der PipelineRun erreicht Succeeded und das Image liegt unter $(params.image-name). Dieses Manifest wurde syntaktisch und strukturell geprüft (deklarierte Parameter, Task-Referenzen, Workspace-Bindungen); auf einem Cluster ausgeführt wurde es nicht.

Tekton Hub liefert über 300 wiederverwendbare Tasks, Git-Operationen, sprachspezifische Builds (Maven, Gradle, npm), Container-Builds (Kaniko, Buildah), Security-Scans (Trivy, SonarQube), Benachrichtigungen (Slack, E-Mail). Organisationen erstellen eigene Tasks für besondere Abläufe und teilen sie über einen internen Tekton Hub.

Kaniko verdient besondere Beachtung: ein Werkzeug, das Docker-Images ohne Docker-Daemon und ohne Root-Rechte baut. Klassisch verlangt der Bau eines Images einen Docker-Daemon mit Socket-Zugriff (/var/run/docker.sock), was Sicherheitsrisiken bringt. Kaniko baut Images direkt aus dem Dockerfile in einem nicht privilegierten Container, ideal für sichere Kubernetes-Pipelines.

ArgoCD: GitOps-CD-Automatisierung

ArgoCD, ein graduiertes CNCF-Projekt, setzt GitOps für Kubernetes um. Es läuft als Controller im Cluster, fragt die konfigurierten Git-Repos periodisch ab (standardmässig alle 3 Minuten), vergleicht den Sollzustand (Git-Manifeste) mit dem Istzustand (Clusterressourcen) und gleicht die Unterschiede ab.

Die ArgoCD-Architektur umfasst: Application (ein CRD, das Quell-Repo, Pfad, Zielcluster und Sync-Policy definiert), AppProject (eine logische Gruppierung von Applications mit RBAC und Quoten), ApplicationSet (automatische Erzeugung mehrerer Applications aus Templates). Das Web-Interface bietet ein Echtzeit-Dashboard mit: Sync-Status je Application (Synced, OutOfSync, Unknown), Health Status (Healthy, Progressing, Degraded, Suspended) und der Historie der Abgleiche mit den zugehörigen Git-Commits.

1. Vollständiger GitOps-Ablauf mit Tekton und ArgoCD:
   1. Entwickler pusht Code → GitHub
   2. GitHub-Webhook → löst den Tekton EventListener aus
   3. Tekton-Pipeline:
      • Quellcode-Repository klonen
      • Tests ausführen (JUnit, pytest)
      • Image bauen (Kaniko)
      • Image pushen → Container-Registry (Tag, git-sha)
      • Image-Tag im Git-Manifest-Repository aktualisieren
      • Manifest-Repository committen und pushen
   4. ArgoCD erkennt den neuen Commit im Manifest-Repository
   5. ArgoCD gleicht ab:
      • Vergleicht Git-Manifeste mit dem Clusterzustand
      • Wendet die Änderungen an (Rolling-Update-Deployment)
      • Überwacht den Zustand der Replicas (Replicas ready)
   6. Anwendung ausgerollt, ArgoCD-Status, Synced und Healthy

Die Trennung von Quellcode-Repository und Manifest-Repository ist eine wesentliche gute Praxis. Das Manifest-Repo enthält nur Kubernetes-YAML (Deployments, Services, ConfigMaps) mit präzisen Image-Referenzen (app:sha-abc123 statt app:latest). Diese Trennung erlaubt unabhängiges Rollback, feinere Zugriffskontrolle und bessere Auditierbarkeit.

Integration mit GitLab CI und GitHub Actions

Organisationen mit bestehenden GitLab-CI- oder GitHub-Actions-Pipelines können Kubernetes für CI/CD schrittweise einführen, ohne die Workflows vollständig neu zu schreiben. Die hybride Strategie: GitLab oder GitHub übernimmt die Orchestrierung (Trigger, Bedingungen, Freigaben), Tekton läuft als Backend für Kubernetes-native Tasks.

GitLab CI kann einen Tekton-PipelineRun über kubectl create -f pipelinerun.yaml auslösen, mit tkn pipelinerun logs --follow auf den Abschluss warten und den Exit-Status auslesen. GitHub Actions bietet eine offizielle Action tektoncd/actions, welche die Integration vereinfacht. Beispiel: ein GitHub-Actions-Workflow, der Tekton für den Build und danach ArgoCD für das Deployment auslöst, ohne die GitHub-Oberfläche zu verlassen.

CI/CD-Sicherheit in Kubernetes, fünf Säulen

Die CI/CD-Sicherheit in Kubernetes verlangt einen mehrschichtigen Ansatz über Images, Secrets, RBAC, Network Policies und Admission Control.

1. Sichere Images und Schwachstellen-Scans

Jedes in den Pipelines genutzte Container-Image (Base Images, Anwendungs-Images) muss vor dem Deployment einen Schwachstellen-Scan durchlaufen. Trivy, ein quelloffener CNCF-Scanner, erkennt CVEs (Common Vulnerabilities and Exposures) in Images, Dateisystemen und Git-Repos. Trivy als Tekton-Task einzubinden stoppt die Pipeline, sobald kritische CVEs auftauchen.

Offizielle Base Images (alpine, debian-slim) erhalten regelmässig Sicherheitspatches, doch die Anwendungen müssen neu gebaut werden, um davon zu profitieren. Die Strategie automatisierter Rebuilds: Renovate Bot oder Dependabot erzeugen automatisch Pull Requests, wenn neue Base-Image-Versionen erscheinen, und lösen CI-Pipelines aus, welche die Verträglichkeit vor dem Merge prüfen.

2. Secret-Verwaltung: Vault, Sealed Secrets, External Secrets

Secrets (Passwörter, API-Schlüssel, Zertifikate) im Klartext in Git-Manifesten abzulegen verletzt die GitOps-Prinzipien und die gute Sicherheitspraxis. Drei Ansätze setzen sich durch: HashiCorp Vault (ein externer Tresor, der Secrets zur Laufzeit in die Pods einspeist), Bitnami Sealed Secrets (verschlüsselte Secrets, die sich in Git committen lassen und clusterseitig entschlüsselt werden), External Secrets Operator (Abgleich von Secrets aus AWS Secrets Manager, Azure Key Vault und weiteren).

Der External Secrets Operator (ESO), ein CNCF-Incubating-Projekt, vereinheitlicht die Anbindung an über 20 Secret-Backends. ESO gleicht externe Secrets in native Kubernetes-Secrets ab, sodass Anwendungen sie über Volumes oder Umgebungsvariablen nutzen können, ohne Codeänderung. Der Ablauf: Secrets liegen im AWS Secrets Manager, der ESO-SecretStore zeigt auf AWS, ein ExternalSecret definiert die Zuordnung AWS-Secret zu K8s-Secret, und ESO gleicht automatisch mit konfigurierbarer Refresh-Periode ab (standardmässig 1 Stunde).

3. Striktes RBAC: Zugriff nach Rolle begrenzen

Die ServiceAccounts von Tekton und ArgoCD sollen minimale Rechte haben (Prinzip der geringsten Privilegien). Eine Tekton-Task, die Images baut, braucht get/list pods (um Build-Pods zu überwachen) und create secrets (für Registry-Credentials), aber NICHT delete deployments oder create clusterroles.

Das ArgoCD-RBAC unterscheidet: Project Admin (Applications in einem Projekt anlegen und löschen), Project Developer (Applications abgleichen, aber nicht löschen), Read-Only (Status einsehen). Multi-Tenant-Organisationen legen AppProjects je Team an, mit RBAC zur Trennung: Team A darf nur Applications in den Namespaces team-a-* abgleichen, Team B ist auf team-b-* beschränkt.

4. Network Policies: die Pipelines isolieren

Tekton-Pods im Namespace tekton-pipelines brauchen keinen Zugriff auf sämtliche Namespaces des Clusters. Network Policies schränken den Verkehr ein: Pipelines erreichen die Container-Registry (Egress auf Port 443 zu registry.company.com) und den Git-Server (Port 22 SSH), bleiben aber von den Produktions-Namespaces abgeschnitten.

Eine Standardregel «deny all», Aller Verkehr ist blockiert, ausser den ausdrücklich erlaubten Flüssen. Dieser Zero-Trust-Ansatz verhindert, dass eine kompromittierte Pipeline (etwa über eine bösartige Abhängigkeit im Build) auf Produktionsdienste übergreift.

5. Policy Enforcement: OPA Gatekeeper, Kyverno

Kubernetes-Admission-Controller prüfen Ressourcen vor der Erstellung. Open Policy Agent (OPA) Gatekeeper und Kyverno setzen Policy-as-Code um und blockieren gefährliche Konfigurationen: Pods, die privileged, true anfordern, Container als Root (runAsUser, 0), Images ohne präzise Tags (image, app:latest statt app:v1.2.3).

Beispiel einer Kyverno-Policy, die unsignierte Images blockiert, die Image-Signatur über cosign/sigstore prüfen und jeden PipelineRun ablehnen, der nicht überprüfbare Images referenziert. Diese Policy zwingt die Teams, ihre Images nach dem Build zu signieren (über cosign sign), was Herkunft und Integrität sichert.

Die fünf Fehler, welche Kubernetes-Pipelines gefährden

1. Docker-in-Docker (DinD) ungehärtet weiterverwenden

Symptom: das Docker-in-Docker-Muster nutzen (ein Container mit Docker-Daemon), um Images in Kubernetes-Pipelines zu bauen, indem der Docker-Socket /var/run/docker.sock vom Host-Knoten eingebunden wird.

Auswirkung: Zugriff auf den Docker-Socket bedeutet faktisch Root-Zugriff auf den Host-Knoten. Wer eine Pipeline kompromittiert, kann über den Docker-Socket aus dem Container ausbrechen, privilegierte Container starten und den ganzen Knoten kontrollieren. CVE-2019-5736 (runc escape) zeigt die Tragweite. Der Mechanismus ist direkt: Ein Build, der den Docker-Socket erreicht, verfügt über die Rechte des Daemons auf dem Knoten, was einen Weg zur lateralen Bewegung im Cluster öffnet. Kubernetes-Sicherheitsaudits empfehlen, den Docker-Socket nie unvertrauten Lasten zugänglich zu machen.

Lösung: Kaniko oder Buildah für Builds ohne Docker-Daemon einsetzen. Kaniko baut Images in einem gewöhnlichen, nicht privilegierten Container ohne Host-Zugriff. Buildah ist vergleichbar und wird von Red Hat gepflegt. Zur Migration: die Task docker build durch die Kaniko-Task aus Tekton Hub ersetzen (gcr.io/kaniko-project/executor), das Dockerfile muss nicht geändert werden. Die Builds vor der Produktion in Staging testen. Fortgeschrittene Alternative: Google Cloud Build oder AWS CodeBuild (verwaltete Dienste, die den Betrieb der Build-Infrastruktur abnehmen).

2. Secrets direkt in Git-Manifesten ablegen

Symptom: Secrets (Datenbankpasswörter, API-Schlüssel) im Klartext in Kubernetes-Manifeste committen und auf ein privates Repo als Schutz vertrauen.

Auswirkung, Die Git-Historie legt die Secrets dauerhaft offen, auch nach dem Löschen (ausser bei destruktivem Rewrite). Entwickelnde mit Repo-Zugriff können Produktions-Secrets abziehen. Unbeabsichtigte Lecks (Repo öffentlich gestellt, gestohlenes Notebook mit lokalem Klon, Bildschirmfreigabe bei einer Demo) legen kritische Credentials offen. Ein Leck kann lange unbemerkt bleiben, und die anschliessende Rotation verlangt Abstimmung über mehrere Teams. Wir publizieren weder eine mittlere Entdeckungszeit noch Vorfallkosten: Die kursierenden Zahlen sind untereinander nicht vergleichbar, und Ihre hängen von Ihrer Secret-Fläche ab.

Lösung: nie Secrets im Klartext committen. Den External Secrets Operator (ESO) einsetzen: Secrets in AWS Secrets Manager, Azure Key Vault oder HashiCorp Vault ablegen und nach Kubernetes abgleichen. Ablauf: Secret im Backend anlegen, ExternalSecret definieren, ESO erzeugt das Kubernetes-Secret automatisch. Alternative: Sealed Secrets (Verschlüsselung clientseitig, Entschlüsselung clusterseitig). Zur Migration: die Git-Historie prüfen (Werkzeug, truffleHog), alle offengelegten Secrets rotieren und ESO schrittweise einführen.

3. Resource Requests und Limits auf CI-Pods ignorieren

Symptom: Tekton-PipelineRuns ausrollen, ohne resources.requests und resources.limits für CPU und Speicher zu definieren, sodass Pods Clusterressourcen ohne Schranke beanspruchen.

Auswirkung, Ein Maven-Build, der ohne Limit 8 GB RAM zieht, kann auf dem Knoten ein OOM (Out of Memory) auslösen und andere Lasten beeinträchtigen. Umgekehrt können CPU-intensive Builds die CPU monopolisieren und die Anwendungsleistung verschlechtern. Fehlen die Requests, kann der Scheduler die Pods nicht sinnvoll platzieren. Ergebnis: Produktionsvorfälle, verursacht von CI-Pipelines, der Noisy-Neighbour-Effekt.

Lösung: Requests und Limits auf Tekton-Tasks grundsätzlich definieren. Faustregel: Requests entsprechen dem typischen Bedarf (CPU 500m, Speicher 1Gi für Standard-Builds), Limits sind die Sicherheitsgrenze (CPU 2, Speicher höchstens 4Gi). LimitRanges nutzen, um Standardwerte zu setzen. Die realen Metriken überwachen (Prometheus container_cpu_usage_seconds_total, container_memory_working_set_bytes) und Requests und Limits am beobachteten P95 ausrichten. Für stark schwankende Builds (Maven mit grossen Projekten) Tasks mit Ressourcenstufen anlegen: small (1 CPU/2Gi), medium (2 CPU/4Gi), large (4 CPU/8Gi).

4. Nur manuelle ArgoCD-Synchronisation

Symptom: ArgoCD mit syncPolicy.automated, null konfigurieren (deaktiviert) und für jede Manifest-Änderung einen manuellen Abgleich über UI oder CLI verlangen.

Auswirkung: Das GitOps-Versprechen (Git als Quelle der Wahrheit, automatischer Abgleich) wird nicht eingelöst. Git-Commits bleiben unausgerollt, bis ein Mensch eingreift, und es entsteht Drift zwischen Git und Cluster. Dringende Korrekturen verlangen dann manuelles Eingreifen (etwa ausserhalb der Arbeitszeiten), was Deployments stark verlangsamt. Auch Rollbacks leiden: Ein Git-Revert wird gemacht, das Deployment greift aber erst beim nächsten manuellen Auslösen. Ohne automatischen Abgleich wird die Deployment-Verzögerung die der nächsten menschlichen Intervention, nicht die der Pipeline.

Lösung: Auto-Sync mit Self-Heal für nicht produktive Anwendungen aktivieren, syncPolicy, automated, prune, true selfHeal, true. Prune entfernt Ressourcen, die aus dem Git-Repo gelöscht wurden, und Self-Heal korrigiert clusterseitigen Drift automatisch. Für die Produktion: zuerst Auto-Sync ohne Prune aktivieren (Validierungsphase), Prune nach einigen Wochen nachziehen. Deployment-Fenster (Sync Windows) und Benachrichtigungen (Slack, E-Mail) ergänzen, um die Änderungen zu rahmen. Die ArgoCD-Metrik argocd_app_sync_total überwachen und alarmieren, wenn eine Application länger als 15 Minuten OutOfSync bleibt.

5. Disaster Recovery und Manifest-Backups vernachlässigen

Symptom: sich für das Disaster Recovery allein auf das Git-Manifest-Repository verlassen, ohne die ArgoCD-Metadaten (Applications, AppProjects, RBAC, Konfiguration) zu sichern und ohne die Wiederherstellung zu testen.

Auswirkung, Geht der Cluster verloren (schwerer Vorfall, Ransomware, etcd-Verlust), müssen die Applications in ArgoCD von Hand neu erstellt werden. Bei Dutzenden Anwendungen dauert das mehrere Stunden, mit hohem Fehlerrisiko (falscher Namespace, fehlende Credentials, Konfigurationsfehler). Der Verlust der Zugriffskonfiguration (RBAC, SSO) bremst die Wiederherstellung zusätzlich. Unvorbereitete Organisationen sehen reale RTO von 12 bis 24 Stunden gegenüber einem Ziel von 2 bis 4 Stunden.

Lösung: automatisierte ArgoCD-Backups über einen CronJob argocd-backup einrichten, der die Ressourcen in externen Speicher exportiert (S3, Azure Blob und weitere). Mit argocd admin export ein vollständiges Backup erzeugen. Die Wiederherstellung regelmässig testen (etwa vierteljährlich) auf einem Testcluster. Ein Disaster-Recovery-Runbook mit Schritten, Befehlen und nötigen Zugängen dokumentieren. Fortgeschrittene Alternative: ApplicationSet mit einem Git-Generator, der die Applications automatisch aus Git neu erstellt.

Schrittweise Migration, von Jenkins zu Tekton plus ArgoCD

Eine Migration im Big-Bang-Modus (alle Pipelines gleichzeitig neu schreiben) scheitert meist an der Überlastung der Teams und am Geschäftsrisiko. Ein schrittweises Vorgehen über 12 bis 16 Wochen senkt das Risiko und zeigt rasch Wirkung.

Phase 1 (Wochen 1-3): Infrastruktur und Pilot

• Tekton installieren (Tekton Pipelines plus Triggers) über Helm
• ArgoCD über die offiziellen Manifeste installieren
• Eine Image-Registry konfigurieren (internes Harbor oder Cloud-Registry)
• Eine Pilotanwendung wählen (einfacher Microservice, geringe Kritikalität)
• Eine Tekton-Pipeline erstellen, clone → build → test → push image
• Eine ArgoCD-Application anlegen, die aus Git ausrollt
• Den ganzen Ablauf validieren, Commit → Build → automatisches Deployment

Phase 2 (Wochen 4-8), schrittweise Ausweitung

• 5 bis 10 Anwendungen pro Woche migrieren
• Eine Bibliothek wiederverwendbarer Tekton-Tasks aufbauen
• Die Struktur der Git-Repositories vereinheitlichen
• Die Teams schulen (Workshops plus Dokumentation)
• Monitoring einführen (Grafana, Pipeline-Metriken)

Phase 3 (Wochen 9-12), Sicherheit und Governance

• External Secrets Operator ausrollen
• Bestehende Secrets migrieren
• Policies umsetzen (Kyverno, OPA)
• ArgoCD-RBAC je Team konfigurieren
• Auto-Sync und Self-Heal aktivieren
• ArgoCD-Backups einrichten

Phase 4 (Wochen 13-16), Optimierung und Ausserbetriebnahme von Jenkins

• Die Metriken auswerten (Lead Time, MTTR, Deployment-Frequenz)
• Die Pipelines optimieren
• Die verbleibenden kritischen Anwendungen migrieren
• Jenkins schrittweise abschalten
• Die guten Praktiken dokumentieren

Migrationsszenario, ein B2B-SaaS mit 35 Microservices

Was Sie hier lesen. Das ist kein Kunde und kein von uns instrumentierter Test: Es ist ein Szenario, das einen realistischen Migrationsablauf und dessen Grössenordnungen zeigt. Dauern, Personalaufwand und Kosten sind gesetzte, untereinander stimmige Annahmen, keine Messungen. Die Gewinne am Ende des Abschnitts folgen daraus rechnerisch. Wenn Sie einem Gremium Zahlen vorlegen müssen, wenden Sie dieselbe Methode auf Ihre eigenen Werte an: aktuelle Lead Time, CI/CD-Rechnung, Rollback-Fehlerquote.

Ein illustratives Szenario, kein Kunde: ein Schweizer B2B-SaaS mit 35 Microservices (Java, Node.js, Python), 25 Entwickelnden, Jenkins auf EC2 mit 12 permanenten Agenten, CI/CD-Infrastrukturkosten 8500 CHF/Monat, Lead Time 4 bis 6 Stunden.

Erkannte Probleme:

• Configuration Drift zwischen Produktion und Staging (nicht versionierte manuelle Hotfixes)
• Aufwendige Rollbacks (eigene Skripte je Service, in 20 % der Fälle fehlerhaft)
• Überlastete Jenkins-Agenten bei Spitzen (Merges von Feature-Branches am Freitagnachmittag)
• Verstreute Secrets (Jenkins Credentials, AWS Secrets Manager, hartkodierte Konfigurationen)

Durchgeführte Migration (14 Wochen, 1 Platform Engineer plus 0,5 DevOps):

Wochen 1-3: Aufbau eines eigenen EKS-Clusters für CI/CD, Tekton Pipelines 1.15 LTS, Argo CD 3.5. Pilot: der «notification-service» (Node.js, geringe Kritikalität). Tekton-Pipeline: clone → npm test → Kaniko-Build → Trivy-Scan → Push nach ECR. Eine ArgoCD-Application gleicht die Manifeste aus dem Repository k8s-manifests ab. Validierung: 8 erfolgreiche Testdeployments, Lead Time 12 min (statt 45 min mit Jenkins).

Wochen 4-8: 20 Services migriert (4-5 pro Woche). Aufbau einer Task-Bibliothek: maven-build-test, node-build-test, python-build-test, trivy-scan, slack-notify. Teamschulung: drei Workshops zu 2 Stunden, Confluence-Dokumentation (40 Seiten). Migrationsvorfälle: 3 (fehlende Umgebungskonfigurationen, je in unter 2 Stunden behoben).

Wochen 9-12: External Secrets Operator plus AWS Secrets Manager (180 Secrets in drei Wochen rotiert). Kyverno-Policies: privilegierte Pods blockiert, signierte Images verlangt (cosign), Resource Limits erzwungen. ArgoCD-RBAC: 5 AppProjects (Backend, Frontend, Data, Infra, Shared) mit Rechten je Team.

Wochen 13-14: die verbleibenden 15 Services migriert (davon 3 kritische). ArgoCD-Auto-Sync auf allen Nicht-Produktionsumgebungen aktiviert, nach zwei Wochen Beobachtung auch in der Produktion. 10 von 12 Jenkins-Agenten ausser Betrieb genommen (2 für komplexe Legacy-Pipelines behalten).

Ergebnisse des Szenarios nach sechs Monaten:

ROI, berechnet und nicht beobachtet. Die Beträge unten sind eine Beispielrechnung auf den Annahmen dieses Szenarios, kein bei einem Kunden gemessenes Ergebnis, rechnen Sie mit Ihren eigenen Zahlen nach, bevor Sie es einem Gremium vorlegen. Infrastrukturersparnis 4300 CHF/Monat × 12 = 51 600 CHF/Jahr. Weniger Vorfälle (MTTR -82 %, Drift -100 %) ergeben einen geschätzten Produktivitätsgewinn von 2 FTE/Jahr ≈ 180 000 CHF. Migrationsaufwand: 14 Wochen × 1,5 FTE ≈ 45 000 CHF. ROI in weniger als drei Monaten erreicht.

Zusammengefasst: drei Kernpunkte

Kubernetes macht CI/CD von zustandsbehaftet zu kurzlebig, von imperativ zu deklarativ

Jenkins-Pipelines auf VMs erzeugen drei Fehlbilder, Configuration Drift (Umgebungen weichen ohne Nachvollziehbarkeit ab), manuelle Skalierung (Agenten bereitstellen, um Spitzen aufzufangen), fehlende Reproduzierbarkeit (nicht deterministische Builds durch zeitlichen Systemdrift). Kubernetes kehrt das um: kurzlebige Pods (garantierte Isolation, automatisches Aufräumen), elastische Skalierung (Pods je nach Last dynamisch erzeugt und entfernt), deklaratives GitOps (Git als Quelle der Wahrheit, fortlaufender Abgleich über ArgoCD). Die CI/CD-Modernisierung gehört zu den ersten genannten Gründen für den Wechsel zu Kubernetes. Die beobachteten Gewinne: Lead Time -95 %, Deployment-Frequenz ×20, Kosten -40 bis -60 %.

GitOps mit ArgoCD beseitigt Configuration Drift und vereinfacht das Disaster Recovery

Die CNCF-Umfrage vom Juli 2025 findet Argo CD auf knapp 60 % der von den Befragten verwalteten Cluster, bei einem NPS von 79 und 97 % Produktionsnutzung. GitOps kehrt den Deployment-Fluss um: Klassisch pusht CI in den Cluster (kubectl apply) und erzeugt Drift, sobald manuell eingegriffen wird. GitOps beruht auf einem Pull-Modell: Git enthält den Sollzustand, ArgoCD gleicht den Cluster automatisch ab. Die Vorteile: vollständige Nachvollziehbarkeit, einfacheres Rollback, erleichtertes Disaster Recovery. Organisationen mit GitOps senken ihre MTTR um 45 bis 60 % und beseitigen driftbedingte Vorfälle.

CI/CD-Sicherheit in Kubernetes verlangt einen mehrschichtigen und nicht verhandelbaren Ansatz

Kubernetes-Pipelines bringen eine eigene Angriffsfläche mit: Zugriff auf den Docker-Socket (Root-Eskalation auf dem Host-Knoten), hartkodierte Secrets in Git (offengelegte Credentials), CI-Pods ohne Limits (Risiko einer unbeabsichtigten Dienstverweigerung). Der Sicherheitsansatz ruht auf mehreren Schichten: sichere Images (Kaniko, Trivy), Secret-Verwaltung (External Secrets Operator, Vault), striktes RBAC, Network Policies, Admission Control (OPA, Kyverno). Diese Massnahmen sind unverzichtbar: Reale Vorfälle zeigen kompromittierte CI-Pipelines mit Auswirkung auf die Produktion. Die Kosten eines kritischen Sicherheitsvorfalls werden auf 15 000 bis 50 000 CHF geschätzt, gegenüber einigen Wochen Aufwand, um die Pipelines sauber abzusichern.