Deployment (K8s)

Die wichtigste YAML-Datei in deinem Leben:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3               # Ich will 3 Stück
  selector:
    matchLabels:
      app: nginx
  template:                 # Bauplan für den Pod
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2 # Version v1

kubectl apply -f deploy.yaml. Update auf v2? Ändere nginx:1.14.2 zu nginx:latest und kubectl apply. Kubernetes tauscht die Pods Stück für Stück aus.

Praxisroutine

In der Praxis lernst du Deployment (K8s), indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.

Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.

1. ReplicaSets (im Hintergrund)

Das Deployment managet Pods nicht direkt. Es managet ReplicaSets. Wenn du apply machst:

1. Deployment erstellt ReplicaSet-v1.
2. ReplicaSet-v1 erstellt 3 Pods. Bei einem Update:
3. Deployment erstellt ReplicaSet-v2 (Größe 0).
4. Es skaliert ReplicaSet-v2 hoch (0 -> 1).
5. Es skaliert ReplicaSet-v1 runter (3 -> 2).
6. Wiederholen bis v1=0 und v2=3. Das ermöglicht den Rollback (kubectl rollout undo). K8s muss nur ReplicaSet-v1 wieder hochskalieren. Es behält die alten ReplicaSets (Default: 10) in der History.

2. Update Strategien

• RollingUpdate (Default): Ersetzt Pods Schritt für Schritt. Keine Downtime. Parameter: maxSurge (Wie viele extra?) und maxUnavailable (Wie viele dürfen fehlen?).
• Recreate: Tötet ALLE alten Pods sofort. Startet dann die neuen. Kurze Downtime, aber sicher, wenn die App nicht zwei Versionen parallel kann (Datenbank Schema Konflikt).

3. Declarative vs. Imperative

Du sagst nicht "Update jetzt!". Du änderst den "Desired State" in der YAML. Der Deployment Controller in der Control Plane läuft in einer Endlosschleife (Reconciliation Loop). Er vergleicht IST (Cluster) mit SOLL (YAML). Wenn sie abweichen, handelt er. Das macht das System selbstheilend.

1. Die Architektur der Control Loop (Reconciliation)

Das Deployment manifestiert das "Declarative" Paradigma von Kubernetes. Im Kube-Controller-Manager läuft eine Go-basierte Endlosschleife (Reconciliation Loop). Das Deployment evaluiert ständig (im Millisekundentakt): Desired State - Current State = Delta. Du hast 3 Replicas konfiguriert, aber ein externer Sysadmin hat frech per Terminal einen Node hart rebootet und 1 Pod stirbt (Current = 2). Der Controller berechnet Delta = 1. Er schickt dem kube-apiserver den Auftrag: "Generiere einen weiteren Pod, um wieder auf 3 zu kommen". Dieser selbstheilende Ansatz (Self-Healing) ohne hartcodierte if/else Restart-Skripte rettet Ops in der Nachtschicht.

2. Zero-Downtime: Readiness und Liveness Probes

Ein Rolling Update bringt wenig, wenn der neue Pod sofort HTTP-Traffic erhält, aber die interne Java-Runtime noch 40 Sekunden zum Hochfahren braucht (User sehen "502 Bad Gateway"). Deployments operieren daher niemals blind. Sie stützen sich auf Probes.

• Liveness Probe: Testet "Ist die App abgestürzt?" (z.B. HTTP 200 auf /health). Schlägt dies fehl, tötet K8s den Pod und das Deployment spawnt Ersatz.
• Readiness Probe: Testet "Bist du bereit für echten Traffic?". Der Load Balancer wartet mit der Traffic-Umleitung, bis diese Probe (z.B. /ready) positiv meldet. Beim Update wartet das Deployment exakt auf das "Ready"-Signal des neuen V2-Pods, bevor es drüben den alten V1-Pod killt.

3. GitOps und CD (Continuous Deployment)

In hochreifen Umgebungen (wie Flux oder ArgoCD) tippt kein Mensch mehr kubectl apply. Das YAML des Deployments liegt in einem Git-Repository, das über Git und Versionierung verwaltet wird. Ein Software-Agent im Cluster überwacht Git. Pusht ein Entwickler einen Helm-Chart-Commit mit image:v3, bemerkt ArgoCD den Delta-Shift im Repository. ArgoCD pullt die Änderung ins Cluster und synchronisiert das YAML hart ("Single Source of Truth"). Macht ein Sysadmin manuelle CLI-Änderungen am Deployment, überschreibt der GitOps-Agent das gnadenlos nach 3 Sekunden wieder mit dem Git-Stand ("Configuration Drift" Ausgleich).