Pod ist in Kubernetes die kleinste einsetzbare Einheit (Deployment-Einheit). Ein Pod kapselt einen oder mehrere Container und stellt ihnen gemeinsame Ressourcen bereit: ein eigenes Netzwerk-Interface samt IP-Adresse, Storage-Volumes und dieselbe lokale Netzwerkumgebung (localhost). Das Wort stammt von einem Pod aus Walen — eine Gruppe von Walen, die gemeinsam schwimmt.
Ein Container oder mehrere?
Der häufigste Fall ist ein Pod mit genau einem Container (Muster 1:1). Mehrere Container in einem Pod sind die Ausnahme und folgen typischen Sidecar-Mustern: Ein Hilfscontainer (Sidecar) ergänzt den Hauptcontainer, zum Beispiel für Log-Weiterleitung, Proxy oder Konfigurations-Synchronisation. Alle Container eines Pods starten gemeinsam auf demselben Kubernetes-Knoten und teilen sich CPU- und Speicherlimits.
Pods sind flüchtig
Pods sind ephemer (kurzlebig): Sie werden nicht dauerhaft betrieben, sondern von Controllern wie Deployment, StatefulSet oder DaemonSet erzeugt, überwacht und bei Problemen neu gestartet. Fällt ein Pod aus, startet der Daemon-artige Controller- bzw. Kubelet-Mechanismus automatisch Ersatz. Deshalb sollte eine Anwendung nie direkt an die IP eines Pods gebunden werden — Services übernehmen die stabile Erreichbarkeit.
Lebenszyklus
- Pending – Pod ist angefordert, wartet auf Ressourcen (z.B. Platz auf einem Knoten).
- Running – Container laufen.
- Succeeded – alle Container erfolgreich beendet.
- Failed – ein Container mit Fehler beendet.
- Unknown – Zustand nicht ermittelbar (z.B. Knoten nicht erreichbar).
Praxis
kubectl get pods
kubectl describe pod mein-pod
kubectl logs mein-pod
kubectl exec -it mein-pod -- /bin/bashDie Pod-Verwaltung selbst übernimmt Kubernetes: Der Kernel des Hosts stellt über cgroups und Namespaces die Isolation, ähnlich wie bei LXC. Wer Container grundlegend verstehen will, sollte Container, Kubernetes und die docker-Befehle kennen — das Init-System des Knotens kümmert sich um den Start der Kubernetes-Prozesse.