54 Vergleich: OCI-Pod vs. Kubernetes-Pod

Pods gehören zu den konzeptionell stärksten Ideen moderner Containerarchitekturen. Doch „Pod“ ist nicht gleich „Pod“. Podman implementiert Pods als OCI-konforme Konstrukte, während Kubernetes Pods als Control-Plane-gesteuerte Objekte behandelt, die neben Namespaces auch Policies, Scheduling, Lifecycle-Management und Clusterintegration abbilden. Beide Modelle benutzen denselben Begriff, aber sie verkörpern unterschiedliche Ebenen der Architektur. Der Vergleich beider Pod-Typen zeigt, wie eng verwandt und zugleich wie unterschiedlich sie sind.

54.1 Zwei Definitionen, zwei Schichten

Ein OCI-Pod ist ein reines Laufzeitkonstrukt. Ein Kubernetes-Pod ist ein Control-Plane-Objekt, das auf einem Laufzeitkonstrukt aufbaut.

Das grundlegende Containerverhalten ist identisch: gemeinsamer Netzwerknamespace, gemeinsames Zeit- und Prozessmodell, optional gemeinsame PID-/IPC-/UTS-Namespaces. Aber Kubernetes erweitert dieses Modell um eine Vielzahl operativer Mechanismen, die Podman bewusst nicht bereitstellt.

Eine erste Gegenüberstellung:

54.2 Der OCI-Pod: ein reines Namespace-Modell

Der OCI-Pod, wie ihn Podman implementiert, ist eine minimalistische Interpretation des Pod-Konzepts:

Ein OCI-Pod hat keine:

Er ist damit keine „Deployment-Einheit“, sondern eine Ausführungseinheit.

Ein OCI-Pod ist so nah an Linux wie möglich und so fern von Distribution und Orchestrierung wie nötig.

54.3 Der Kubernetes-Pod: ein hochstrukturiertes Architekturobjekt

Der Kubernetes-Pod ist ein Abstraktionsobjekt, das die Laufzeit (OCI/CRun/CRIO) mit der operativen Steuerung der Control Plane verbindet. Er ist das kleinste schedulbare Objekt im Cluster und besitzt eine Vielzahl an Metadaten, die seine Bedeutung definieren:

In Kubernetes ist der Pod kein technisches Detail, sondern ein zentrales Domänenobjekt, das im gesamten Clusterkontext lebt.

54.4 Die Namespace-Ebene: identisch im Kern

Trotz aller Unterschiede basiert beides auf denselben Grundmechanismen: Linux-Namespaces.

54.4.1 Gemeinsamkeiten

Beide Pod-Typen:

Der Unterschied liegt nicht in der Laufzeitgrundlage. Der Unterschied liegt oberhalb der Laufzeit.

54.4.2 Visualisierung:

Auf der Prozess- und Namespace-Ebene funktionieren beide ähnlich.

54.5 Die Control Plane macht den Unterschied

Kubernetes-Pods existieren nicht alleine — sie sind eingebettet in einen vollständig orchestrierten Kontext:

Ein OCI-Pod hingegen:

Dadurch ist der Kubernetes-Pod ein gewolltes, persistent beschriebenes Objekt, während der OCI-Pod ein ad-hoc-laufzeitliches Konstrukt ist.

54.6 Lifecycle-Modelle im Vergleich

54.6.1 OCI-Pod:

54.6.2 Kubernetes-Pod:

Der Kubernetes-Pod ist damit nicht nur eine Prozessgruppe — er ist ein verwaltetes Lebewesen im Cluster.

54.7 Storage- und Volume-Modelle

54.7.1 OCI-Pod (Podman)

54.7.2 Kubernetes-Pod

Die Storage-Schicht ist einer der größten Unterschiede — Kubernetes abstrahiert, Podman nicht.

54.8 Netzwerk und Service Discovery

54.8.1 OCI-Pod

54.8.2 Kubernetes-Pod

Ein Kubernetes-Pod ist damit ein Knoten im Clustergraphen. Ein OCI-Pod ist ein isoliertes Laufzeitobjekt.

54.9 Architekturmuster: wann welcher Pod Sinn ergibt

54.9.1 OCI-Pods sind ideal für:

54.9.2 Kubernetes-Pods sind ideal für:

Beide Pod-Modelle adressieren unterschiedliche Betriebsebenen.

54.10 Essenz des Vergleichs

Der OCI-Pod ist ein technisches Pod-Modell, der Kubernetes-Pod ist ein architekturelles Pod-Modell.

Der eine ist unmittelbar, direkt, überschaubar. Der andere ist orchestriert, verwaltet, eingebettet in ein deklaratives Ecosystem.

Beide sprechen dieselbe Sprache – Namespaces – aber sie leben in unterschiedlichen Welten.