# Kubernetes Deployments: Skalierung & Zero-Downtime Updates

TL;DR / Management Summary Ein Deployment ist ein Controller in Kubernetes, der den gewünschten Zustand einer Applikation beschreibt. Er verwaltet die Erstellung von ReplicaSets, die wiederum die Pods (Artikel 812) steuern. Ein Senior Admin nutzt Deployments, um sicherzustellen, dass immer die korrekte Anzahl an Instanzen läuft und führt Rolling Updates durch, bei denen die neue Version Pod für Pod ausgerollt wird, ohne dass die Applikation jemals offline geht.

# 1. Das Deployment-Objekt

Der Verwalter des Soll-Zustands.

In der YAML-Datei legen wir fest:

Replicas: Wie viele Kopien der App sollen laufen? (z.B. 3).
Template: Das Image und die Config für die Pods.
Selector: Wie findet das Deployment “seine” Pods? (via Labels).

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
      - name: nginx
        image: nginx:1.21

# 2. Skalierung (Scaling)

Anpassen an die Last.

# Manuelles Skalieren

kubectl scale deployment web-app --replicas=10

# Horizontales Auto-Scaling (HPA)

Kubernetes kann selbstständig skalieren basierend auf Metriken (z.B. CPU > 70%).

Vorteil: Spart Geld in der Cloud (Artikel 784) und schützt vor Überlastung.

# 3. Deep Dive: Rolling Updates & Rollbacks

Update ohne Schmerz.

Wenn Sie das Image im Deployment ändern:

Start: K8s startet einen neuen Pod (v2).
Wait: Sobald v2 gesund ist (Readiness Probe), wird ein alter Pod (v1) gelöscht.
Iteration: Dies wird wiederholt, bis nur noch v2 läuft.

Rollback: Wenn v2 abstürzt, reicht ein Befehl:

kubectl rollout undo deployment web-app

# 4. Day-2 Operations: Ressourcen-Limits

Stabilität für den Cluster.

Jedes Deployment sollte resources definieren:

Requests: Was die App mindestens braucht (wichtig für den Scheduler).
Limits: Was die App maximal nutzen darf (schützt den Host vor Amok-laufenden Apps).

# 5. Troubleshooting & “War Stories”

Wenn das Update klemmt.

# Top 3 Fehlerbilder

Symptom: ImagePullBackOff.
- Ursache: Tippfehler im Image-Namen oder fehlende Registry-Credentials.
- Lösung: kubectl describe deployment prüfen.
Symptom: Das Update bleibt bei 1 von 3 Pods hängen.
- Ursache: Der neue Pod wird nicht “Ready”, weil der Health-Check (Artikel 748) fehlschlägt.
- Fix: Timeout oder Startup-Logic der App prüfen.
Symptom: “OOMKilled” (Out of Memory).
- Lösung: Memory-Limits im Deployment erhöhen.

# “War Story”: Die “Version-Mix” Falle

Ein Admin nutzte ein Deployment ohne festes Image-Tag (image: my-app:latest). Das Ereignis: Er startete einen vierten Pod via Scaling. Das Ergebnis: Drei Pods liefen mit Version 1.0 (die beim ersten Start ‘latest’ war). Der vierte Pod lud das mittlerweile aktualisierte ‘latest’ Image (Version 2.0). Die Katastrophe: Die zwei Versionen hatten inkompatible API-Formate. User-Anfragen schlugen zufällig fehl, je nachdem, auf welchem Pod sie landeten. Lehre: Nutzen Sie niemals :latest in Deployments. Verwenden Sie eindeutige Versionen (z.B. Git-Hashes oder SemVer).

# 6. Monitoring & Reporting

Deployment-Status.

# Rollout Status

kubectl rollout status deployment web-app

KPI: Available Replicas vs. Desired Replicas.

# 7. Fazit & Empfehlung

Deployments sind das wichtigste Werkzeug für den Applikations-Lifecycle.

Empfehlung: Nutzen Sie Canary-Releases (Artikel 804) für kritische Updates, indem Sie zwei Deployments parallel betreiben.
Wichtig: Definieren Sie eine Revision History Limit (z.B. 10), damit Sie auch nach Wochen noch auf alte Stände zurückrollen können.

# Anhang: Cheatsheet (Deployment CLI)

Aufgabe	Befehl
Deployments listen	`kubectl get deploy`
Image updaten	`kubectl set image deploy/web nginx=nginx:1.22`
Rollout Historie	`kubectl rollout history deploy/web`
Pause Rollout	`kubectl rollout pause deploy/web`