Ein Deployment funktioniert wie ein Vorarbeiter, der eine Personalplanung im Kopf hat. Er weiß, wie viele Leute arbeiten sollen, und meldet sofort, wenn jemand fehlt.

Der Vorarbeiter hat einen Plan: Drei Arbeiter an einer Station. Kommt einer nicht, schickt er einen Ersatz. Der Ersatz übernimmt dieselbe Aufgabe, ohne dass jemand nachfragen muss. Der Vorarbeiter prüft dabei nicht die Stimmung oder die Leistung. Er zählt nur: Sind noch drei da? Solange die Zahl stimmt, greift er nicht ein.

In Kubernetes ist der Vorarbeiter das Deployment, eine Verwaltungseinheit für gleichartige Pods. Der Pod ist die kleinste betreibbare Einheit und umhüllt einen oder mehrere Container, also Anwendungen samt Abhängigkeiten. Der Plan steckt im Feld replicas: Dort steht die Soll-Stärke, etwa die Zahl drei. Fällt ein Pod aus, startet das Deployment automatisch einen neuen. Kubernetes verteilt die Pods dabei auf die Knoten, die Arbeitsrechner des Clusters.

Ein Deployment für eine Webanwendung mit replicas: 3 erzeugt drei gleiche Pods. Stürzt einer ab, läuft die Zahl ohne Eingriff auf drei zurück. Die Container eines Pods teilen sich eine IP-Adresse und reden über localhost miteinander.

Das Bild hat eine Grenze: Ein Arbeiter bleibt derselbe Mensch, ein ersetzter Pod ist eine neue Instanz mit neuer IP-Adresse. Der Vorarbeiter delegiert auch aktiv, das Deployment vergleicht nur Ist und Soll. Stabile Adressen für Anfragen liefert deshalb ein Kubernetes-Service.

Pods also nie von Hand starten: Wer replicas selbst überwacht, ersetzt keine ausgefallenen Pods. Deployment heißt nicht Pod, sondern Soll-Stärke, die Kubernetes von selbst hält.

📌 Pod · Deployment · replicas

📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #devops #docker