Ein Pod ist die kleinste deploybare Einheit in Kubernetes. Er besteht aus einem oder mehreren eng gekoppelten Containern, die sich Netzwerk-Namespace (gemeinsame IP-Adresse, gemeinsamer Port-Bereich), gegebenenfalls Volumes und denselben Lifecycle teilen. Pods sind kurzlebig: Bei einem Neustart, Knoten-Ausfall oder Skalierungsereignis werden alte Pods gelöscht und neue Pods mit neuen IPs erzeugt. Stabilität und Erreichbarkeit erreichen Pods erst durch übergeordnete Ressourcen wie Deployments, ReplicaSets, StatefulSets, DaemonSets oder Jobs in Verbindung mit Services.
Eingesetzt werden Pods für jede Workload, die in Kubernetes ausgeführt wird. Multi-Container-Pods folgen typischen Mustern: Sidecar (z. B. ein Log-Forwarder neben einer Web-Anwendung), Adapter (Anpassung von Datenformaten zwischen Anwendung und externer Schnittstelle) oder Ambassador (Proxy zu externen Diensten). Init-Container laufen vor den eigentlichen Anwendungs-Containern und können Setup-Aufgaben übernehmen — etwa das Migrieren von Datenbank-Schemas oder das Bereitstellen von Konfigurationsdateien.
Der Einsatzzweck und das gelöste Problem liegen in der Bündelung eng zusammenarbeitender Container in einer Einheit. Ein Pod garantiert, dass die enthaltenen Container immer zusammen geplant, zusammen gestartet und zusammen beendet werden, denselben Hostknoten teilen und über localhost direkt miteinander kommunizieren können. Damit löst Kubernetes ein Problem, das reine Container-Runtimes nicht abdecken: Wie modelliert man eine "Anwendung mit ihren Hilfskomponenten" so, dass sie sich wie eine Einheit verhält, ohne ein einziges Container-Image bauen zu müssen?
"Pod ein klassisches Erbstück aus dem Borg- und Omega-System bei Google, in dem Workloads ebenfalls als "Tasks" in Gruppen organisiert wurden. Mit Kubernetes 1.0 (2015) wurde das Konzept öffentlich. Spätere Erweiterungen umfassen die offizielle Unterstützung für Sidecar-Container (KEP-753, ab 1.28 Alpha, ab 1.29 Beta, stabilisiert in 1.33), Pod Topology Spread Constraints, Pod Disruption Budgets, das Pod Security Admission (statt der älteren PodSecurityPolicy) und feingranulare Ressourcensteuerung über In-Place Pod Resize.
Der Name ‚Pod' ist eine bewusste Anspielung auf "a pod of whales" — eine Schule von Walen, die gemeinsam schwimmen. In Verbindung mit dem maritimen Thema von Kubernetes (Steuermann, Container, Hafen) entsteht damit eine konsistente Metaphorik, die sich auch im Maskottchen "Phippy" (eine Elefantin, ursprünglich von Microsoft) spiegelt.