Kubernetes Deployment mit GitOps (Push vs. Pull)

Kubernetes-Deployments können auf zwei grundlegend verschiedene Arten durchgeführt werden: Push und Pull. Während Push-Deployments die traditionelle Methode über CI/CD-Pipelines darstellen, revolutionieren Pull-basierte GitOps-Ansätze wie ArgoCD die Art und Weise, wie wir Infrastruktur und Anwendungen bereitstellen.

In diesem umfassenden Guide vergleichen wir beide Ansätze, erklären ihre Vor- und Nachteile und helfen dir dabei, die richtige Strategie für dein Projekt zu wählen.

Push vs. Pull: Die beiden Deployment-Strategien

Bei Kubernetes-Deployments unterscheiden wir zwischen zwei grundlegenden Ansätzen:

Push-Deployment (Traditionelle CI/CD)

Beim Push-Deployment wird der Deployment-Prozess von außen initiiert – typischerweise durch eine CI/CD-Pipeline wie GitLab CI/CD, GitHub Actions oder Jenkins. Die Pipeline führt alle Schritte aus: Code bauen, Container-Images erstellen, in eine Registry pushen und schließlich die Kubernetes-Ressourcen über Tools wie kubectl oder Helm direkt auf den Cluster anwenden.

Charakteristika:

• Deployment erfolgt von außen (externer Runner/Agent)
• Pipeline hat direkten Zugriff auf den Kubernetes-Cluster
• Deployment wird durch Code-Push oder manuellen Trigger ausgelöst
• Alle Schritte finden in der Pipeline statt

Pull-Deployment (GitOps)

Beim Pull-Deployment (auch GitOps genannt) läuft ein Controller direkt im Kubernetes-Cluster oder auf einem Deployment-Cluster. Dieser Controller überwacht kontinuierlich ein Git-Repository oder eine Container-Registry und synchronisiert automatisch den gewünschten Zustand mit dem tatsächlichen Zustand im Cluster.

Charakteristika:

• Deployment erfolgt von innen (Controller im Cluster)
• Controller hat Zugriff auf den Cluster
• Controller überwacht regelmäßig auf Änderungen
• Git-Repository ist die “Single Source of Truth”

Vergleichstabelle: Push vs. Pull Deployment

Die folgende Tabelle bietet einen schnellen Überblick über die wichtigsten Unterschiede, Vor- und Nachteile beider Ansätze:

Ausführliche Analyse: Push-Deployment

Wie funktioniert Push-Deployment?

Beim Push-Deployment wird der gesamte Deployment-Prozess durch eine externe CI/CD-Pipeline gesteuert. Hier ist ein typischer Ablauf:

1. Code-Push: Entwickler pusht Code in Git-Repository
2. Pipeline-Trigger: CI/CD-System erkennt Änderung
3. Build: Pipeline baut Anwendung und erstellt Container-Image
4. Push zu Registry: Image wird in Container-Registry (z.B. Docker Hub, GitLab Registry) hochgeladen
5. Deployment: Pipeline verwendet kubectl oder Helm, um Ressourcen auf Cluster anzuwenden
6. Verification: Pipeline prüft Deployment-Status

Beispiel: GitLab CI/CD Pipeline

# .gitlab-ci.yml
stages:
  - build
  - deploy

build:
  stage: build
  script:
    - docker build -t registry.example.com/app:$CI_COMMIT_SHA .
    - docker push registry.example.com/app:$CI_COMMIT_SHA

deploy:
  stage: deploy
  image: bitnami/kubectl:latest
  script:
    - kubectl set image deployment/app app=registry.example.com/app:$CI_COMMIT_SHA
    - kubectl rollout status deployment/app
  only:
    - main

Vorteile von Push-Deployment

1. Einfacher Einstieg und Vertrautheit

Push-Deployment nutzt bewährte CI/CD-Konzepte, die die meisten Entwickler bereits kennen. Es ist eine natürliche Erweiterung bestehender Workflows und erfordert keine neuen Paradigmen.

Praktisches Beispiel:

• Teams, die bereits Jenkins oder GitLab CI/CD verwenden, können ihre bestehenden Pipelines erweitern
• Keine Notwendigkeit, neue Tools oder Konzepte zu erlernen
• Schnelle Implementierung für kleine bis mittlere Projekte

2. Sofortige Deployment-Ausführung

Sobald die Pipeline läuft, wird das Deployment sofort ausgeführt. Es gibt keine Wartezeit auf einen Sync-Intervall, was für schnelle Iterationen und Hotfixes vorteilhaft ist.

Anwendungsfall:

• Kritische Bugfixes können sofort deployed werden
• Entwickler sehen Änderungen unmittelbar nach Pipeline-Abschluss
• Keine Verzögerung durch Controller-Sync-Intervalle

3. Volle Kontrolle über den Deployment-Prozess

Die Pipeline kann komplexe Deployment-Logik enthalten, wie z.B.:

• Bedingte Deployments basierend auf Umgebung
• Manuelle Approvals für Production
• Custom Rollback-Strategien
• Integration mit externen Systemen (Monitoring, Notifications)

deploy-production:
  stage: deploy
  script:
    - ./scripts/pre-deployment-checks.sh
    - helm upgrade --install app ./helm-chart
    - ./scripts/notify-slack.sh "Deployment erfolgreich"
  when: manual
  only:
    - main

4. Einfache Integration mit bestehenden Tools

Push-Deployment integriert sich nahtlos in bestehende DevOps-Toolchains:

• Code-Quality-Tools (SonarQube, CodeClimate)
• Security-Scanner (Trivy, Snyk)
• Testing-Frameworks
• Notification-Systeme

Nachteile von Push-Deployment

1. Sicherheitsrisiken durch Cluster-Zugriff

Die Pipeline benötigt direkten Zugriff auf den Kubernetes-Cluster, was Sicherheitsrisiken birgt:

Probleme:

• CI/CD-Runner müssen Cluster-Credentials speichern
• Breitere Angriffsfläche (Runner können kompromittiert werden)
• Schwierige Berechtigungsverwaltung (Pipeline hat oft zu viele Rechte)
• Credentials müssen in CI/CD-System gespeichert werden

Lösungsansätze:

• Verwendung von kurzlebigen Tokens
• RBAC mit minimalen Berechtigungen
• Separate Service-Accounts pro Pipeline

# Token mit begrenzter Gültigkeitsdauer erstellen
kubectl create token pipeline-sa --duration=1h

# ServiceAccount mit minimalen Rechten
apiVersion: v1
kind: ServiceAccount
metadata:
  name: pipeline-sa
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pipeline-role
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "update", "patch"]

2. Keine automatische Drift-Detection

Wenn jemand manuell Ressourcen im Cluster ändert (z.B. kubectl edit), werden diese Änderungen nicht erkannt. Die Pipeline weiß nichts von Abweichungen zwischen gewünschtem und tatsächlichem Zustand.

Problem-Szenario:

# Jemand ändert manuell die Replica-Anzahl
kubectl scale deployment/app --replicas=10

# Pipeline weiß nichts davon
# Nächstes Deployment überschreibt möglicherweise die Änderung
# Aber: Keine automatische Erkennung der Abweichung

3. Komplexität bei Multi-Cluster-Deployments

Bei mehreren Clustern (Dev, Staging, Production) muss die Pipeline jeden Cluster einzeln ansprechen:

Herausforderungen:

• Pipeline muss alle Cluster-Credentials verwalten
• Komplexe Logik für unterschiedliche Umgebungen
• Fehleranfällig bei Hinzufügen neuer Clustern
• Schwierige Synchronisation zwischen Clustern

deploy-all-clusters:
  script:
    - kubectl --context=dev apply -f k8s/
    - kubectl --context=staging apply -f k8s/
    - kubectl --context=production apply -f k8s/

deploy-all-clusters:
  script:
    - helm upgrade --install app ./helm-chart --kube-context=dev
    - helm upgrade --install app ./helm-chart --kube-context=staging
    - helm upgrade --install app ./helm-chart --kube-context=production

4. Schwieriges Rollback

Rollbacks erfordern entweder:

• Manuelles Eingreifen
• Komplexe Pipeline-Logik
• Zugriff auf vorherige Versionen

Typisches Problem:

• Pipeline muss alte Image-Tags speichern
• Rollback erfordert erneute Pipeline-Ausführung
• Keine automatische Rückkehr zum letzten funktionierenden Zustand

5. Abhängigkeit von Pipeline-Verfügbarkeit

Wenn die CI/CD-Pipeline ausfällt oder nicht verfügbar ist, können keine Deployments durchgeführt werden. Dies kann kritisch sein, wenn schnelle Hotfixes erforderlich sind.

Ausführliche Analyse: Pull-Deployment (GitOps)

Wie funktioniert Pull-Deployment?

Beim Pull-Deployment (GitOps) überwacht ein Controller kontinuierlich ein Git-Repository oder eine Container-Registry und synchronisiert automatisch den gewünschten Zustand mit dem Cluster. Der Controller läuft direkt im Cluster oder auf einem separaten Deployment-Cluster.

Typischer Ablauf:

1. Code-Push: Entwickler pusht Kubernetes-Manifeste oder Helm-Charts in Git-Repository
2. Controller-Überwachung: GitOps-Controller (z.B. ArgoCD) prüft regelmäßig das Repository
3. Änderungserkennung: Controller erkennt neue Commits oder Image-Updates
4. Synchronisation: Controller wendet Änderungen auf Cluster an
5. Health-Check: Controller überwacht kontinuierlich den Zustand und korrigiert Drifts

Beispiel: ArgoCD Application

# argocd-application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/example/k8s-manifests
    targetRevision: main
    path: apps/my-app
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Vorteile von Pull-Deployment (GitOps)

1. Git als Single Source of Truth

Das Git-Repository wird zur zentralen Quelle für alle Infrastruktur- und Anwendungskonfigurationen. Dies bietet:

Vorteile:

• Vollständige Historie: Alle Änderungen sind in Git nachvollziehbar
• Code Review: Änderungen können vor Deployment geprüft werden
• Branching-Strategien: Verschiedene Umgebungen können verschiedene Branches nutzen
• Audit-Trail: Wer hat was wann geändert? Alles in Git sichtbar

# Entwickler erstellt Feature-Branch
git checkout -b feature/new-feature

# Änderungen an Kubernetes-Manifesten
vim k8s/deployment.yaml

# Pull Request erstellt
# Code Review durch Team
# Nach Merge: ArgoCD synchronisiert automatisch

2. Automatische Drift-Detection und Self-Healing

Der GitOps-Controller erkennt automatisch, wenn der tatsächliche Cluster-Zustand vom gewünschten Zustand (in Git) abweicht und korrigiert dies automatisch.

# Jemand ändert manuell die Replica-Anzahl
kubectl scale deployment/app --replicas=10

# ArgoCD erkennt die Abweichung
# ArgoCD korrigiert automatisch zurück zu Git-Zustand (z.B. 3 Replicas)
# Self-Healing aktiviert

# ArgoCD CLI: Status prüfen
argocd app get my-app

# Drift erkennen
argocd app diff my-app

Vorteile:

• Konsistenz zwischen Git und Cluster
• Automatische Korrektur von manuellen Änderungen
• Schutz vor Konfigurationsdrift
• Compliance-Anforderungen werden erfüllt

3. Verbesserte Sicherheit

Der Controller läuft im Cluster und nutzt Kubernetes RBAC (Role-Based Access Control). Die CI/CD-Pipeline benötigt keinen direkten Cluster-Zugriff mehr.

Sicherheitsverbesserungen:

• Keine Cluster-Credentials in CI/CD: Pipeline pusht nur Code, nicht direkt auf Cluster
• RBAC-basierte Berechtigungen: Controller nutzt Service-Accounts mit minimalen Rechten
• Audit-Logging: Alle Änderungen werden im Controller geloggt
• Separation of Concerns: CI/CD für Build, GitOps für Deployment

Architektur:

CI/CD Pipeline → Container Registry (Images)
                ↓
            Git Repository (Manifests)
                ↓
         GitOps Controller (ArgoCD)
                ↓
         Kubernetes Cluster

4. Einfaches Multi-Cluster-Management

Ein GitOps-Controller kann mehrere Cluster verwalten, indem er einfach verschiedene Application-Definitionen erstellt:

# Production Cluster
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: app-production
spec:
  destination:
    server: https://prod-cluster.example.com
    namespace: production

---
# Staging Cluster
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: app-staging
spec:
  destination:
    server: https://staging-cluster.example.com
    namespace: staging

# Cluster zu ArgoCD hinzufügen
argocd cluster add prod-cluster-context

Vorteile:

• Zentrale Verwaltung mehrerer Cluster
• Konsistente Konfigurationen über alle Umgebungen
• Einfaches Hinzufügen neuer Cluster

5. Einfaches Rollback durch Git-Revert

Rollbacks werden so einfach wie ein Git-Revert:

# Rollback durch Revert des letzten Commits
git revert HEAD
git push

# ArgoCD synchronisiert automatisch den vorherigen Zustand

Vorteile:

• Keine komplexe Pipeline-Logik erforderlich
• Rollback ist genauso einfach wie jede andere Git-Operation
• Vollständige Historie bleibt erhalten
• Kann durch Code Review geprüft werden

6. Klare Trennung von Build und Deployment

Die CI/CD-Pipeline konzentriert sich nur auf:

• Code bauen
• Tests ausführen
• Container-Images erstellen und pushen
• Git-Repository mit neuen Manifests aktualisieren

Das Deployment wird vollständig vom GitOps-Controller übernommen.

Workflow:

CI/CD Pipeline:
  1. Build → Image → Registry
  2. Update Git mit neuem Image-Tag
  3. Fertig!

GitOps Controller:
  1. Erkennt neue Git-Änderung
  2. Synchronisiert Cluster
  3. Überwacht Health

Nachteile von Pull-Deployment (GitOps)

1. Höhere initiale Komplexität

Die Einrichtung eines GitOps-Setups erfordert:

• Installation und Konfiguration des Controllers (z.B. ArgoCD)
• Verständnis von GitOps-Konzepten
• Strukturierung von Git-Repositories
• Einrichtung von RBAC und Berechtigungen

Lernkurve:

• Teams müssen GitOps-Prinzipien verstehen
• Neue Tools müssen erlernt werden
• Initiale Konfiguration ist komplexer als einfache kubectl-Befehle

2. Sync-Intervall-Verzögerung

Der Controller prüft nicht kontinuierlich, sondern in Intervallen (typischerweise 3-5 Minuten). Dies bedeutet eine Verzögerung zwischen Git-Push und tatsächlichem Deployment.

Beispiel:

# ArgoCD prüft standardmäßig alle 3 Minuten
# Bei kritischen Hotfixes kann dies zu lange sein

Lösungen:

• Webhook-basierte Synchronisation (sofortige Updates)
• Manuelle Synchronisation über UI/CLI
• Reduzierung des Sync-Intervalls (erhöht Last)

spec:
  syncPolicy:
    syncOptions:
      - CreateNamespace=true
    # Reduziertes Intervall (Standard: 3 Minuten)
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

# GitHub Webhook konfigurieren
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
data:
  url: https://argocd.example.com
  webhook.github: |
    secret: your-webhook-secret

# Über CLI
argocd app sync my-app

# Über UI: Button "Sync" in ArgoCD-Interface

3. Zusätzliche Infrastruktur-Anforderungen

Der GitOps-Controller benötigt:

• Laufende Infrastruktur (Pod im Cluster)
• Monitoring und Alerting
• Backup-Strategien für Controller-Konfiguration
• Wartung und Updates

Ressourcen:

• CPU und Memory für Controller
• Persistent Storage für State
• Netzwerk-Zugriff auf Git-Repositories

4. Komplexität bei dynamischen Konfigurationen

Für sehr dynamische Konfigurationen, die häufig geändert werden müssen, kann GitOps zu starr sein:

Herausforderungen:

• Jede Änderung erfordert Git-Commit
• Keine “on-the-fly” Anpassungen möglich
• Für experimentelle Deployments weniger flexibel

5. Abhängigkeit von Git-Repository-Verfügbarkeit

Wenn das Git-Repository nicht verfügbar ist, können keine neuen Deployments synchronisiert werden. Dies erfordert:

• Hochverfügbare Git-Infrastruktur
• Backup-Strategien
• Offline-Fähigkeiten für kritische Systeme

Praktische Entscheidungshilfe: Wann welche Strategie?

Wähle Push-Deployment, wenn:

• ✅ Kleine bis mittlere Projekte mit einfachen Anforderungen
• ✅ Schnelle Iterationen und sofortige Deployments erforderlich
• ✅ Bestehende CI/CD-Infrastruktur bereits vorhanden
• ✅ Team kennt CI/CD-Tools bereits gut
• ✅ Einzelner Cluster oder wenige Umgebungen
• ✅ Experimentelle Deployments mit häufigen Änderungen

Typische Anwendungsfälle:

• Startups mit kleinen Teams
• Projekte mit einfachen Deployment-Anforderungen
• Teams ohne GitOps-Erfahrung
• Prototypen und Proof-of-Concepts

Wähle Pull-Deployment (GitOps), wenn:

• ✅ Mehrere Cluster oder komplexe Multi-Environment-Setups
• ✅ Strikte Compliance-Anforderungen und Audit-Trails
• ✅ Große Teams mit klarer Trennung von Build und Deployment
• ✅ Automatische Drift-Detection erforderlich
• ✅ Self-Service-Deployments für Entwickler
• ✅ Production-grade Infrastruktur mit hohen Anforderungen

Typische Anwendungsfälle:

• Enterprise-Umgebungen
• Multi-Cluster-Architekturen
• Regulierte Industrien (Banking, Healthcare)
• Teams mit GitOps-Erfahrung
• Langfristige, produktive Projekte

Hybrid-Ansatz: Beste aus beiden Welten

Viele Organisationen kombinieren beide Ansätze:

Push für CI/CD:

• Build und Test
• Image-Erstellung und Push zu Registry
• Update von Git-Repository mit neuen Manifests

Pull für Deployment:

• GitOps-Controller übernimmt Deployment
• Automatische Synchronisation
• Drift-Detection und Self-Healing

# GitLab CI/CD Pipeline
stages:
  - build
  - update-git

build:
  stage: build
  script:
    - docker build -t registry.example.com/app:$CI_COMMIT_SHA .
    - docker push registry.example.com/app:$CI_COMMIT_SHA

update-git:
  stage: update-git
  script:
    # Update Kubernetes Manifest mit neuem Image-Tag
    - sed -i "s|image:.*|image: registry.example.com/app:$CI_COMMIT_SHA|" k8s/deployment.yaml
    - git add k8s/deployment.yaml
    - git commit -m "Update app to $CI_COMMIT_SHA"
    - git push

# ArgoCD synchronisiert automatisch nach Git-Push

Best Practices für beide Ansätze

Push-Deployment Best Practices

# Beispiel: Health-Check nach Deployment
deploy:
  script:
    - kubectl set image deployment/app app=registry.example.com/app:$CI_COMMIT_SHA
    - kubectl rollout status deployment/app --timeout=5m
    - ./scripts/health-check.sh

rollback:
  script:
    - kubectl rollout undo deployment/app
    - kubectl rollout status deployment/app
  when: on_failure

Pull-Deployment (GitOps) Best Practices

k8s-manifests/
├── apps/
│   ├── app1/
│   │   ├── base/
│   │   └── overlays/
│   │       ├── dev/
│   │       ├── staging/
│   │       └── prod/
│   └── app2/
└── infrastructure/
    ├── monitoring/
    └── networking/

spec:
  syncPolicy:
    syncWindows:
    - kind: allow
      schedule: '10 1 * * *'  # Nur nachts
      duration: 2h
      applications:
      - '*-prod'

Fazit: Push vs. Pull – Die richtige Wahl

Beide Deployment-Strategien haben ihre Berechtigung und sind für verschiedene Szenarien optimal geeignet:

Push-Deployment ist ideal für:

• Teams, die schnell starten möchten
• Einfache, direkte Deployments
• Projekte mit bestehender CI/CD-Infrastruktur
• Schnelle Iterationen und Experimente

Pull-Deployment (GitOps) ist ideal für:

• Enterprise-Umgebungen mit mehreren Clustern
• Teams, die Git als Single Source of Truth nutzen möchten
• Anforderungen an Compliance und Audit-Trails
• Langfristige, produktive Projekte mit hohen Stabilitätsanforderungen

Die moderne Best Practice ist oft ein Hybrid-Ansatz: CI/CD-Pipelines für Build und Image-Management, GitOps-Controller für Deployment und Cluster-Management. Dies kombiniert die Stärken beider Ansätze und minimiert die Schwächen.

Nächste Schritte

Wenn du GitOps ausprobieren möchtest, empfehle ich:

1. ArgoCD installieren: Beginne mit einem lokalen Minikube-Cluster
2. Einfache Anwendung deployen: Starte mit einem einfachen Beispiel
3. Best Practices anwenden: Implementiere Repository-Struktur und RBAC
4. Erweitern: Skaliere auf mehrere Umgebungen und Cluster

Benötigst du professionelle Kubernetes-Unterstützung?

Du möchtest GitOps in deiner Infrastruktur implementieren oder benötigst Unterstützung bei der Einrichtung von Push- oder Pull-Deployments? Wir bieten professionelle Systemadministration und Systemintegration mit modernen Kubernetes- und GitOps-Tools. Von der Planung bis zur Wartung – wir übernehmen die komplette Verantwortung für Ihre IT-Infrastruktur.

Häufig gestellte Fragen (FAQ)

syncPolicy:
  automated:
    selfHeal: true  # Korrigiert manuelle Änderungen automatisch

Weiterführende Ressourcen

• ArgoCD Dokumentation - Offizielle ArgoCD-Dokumentation
• Flux Dokumentation - Alternative GitOps-Lösung
• GitOps Principles - GitOps-Best-Practices und Prinzipien
• Kubernetes Deployment Strategies - Offizielle Kubernetes-Dokumentation