76 podman play kube

podman play kube ist die inverse Funktion von podman generate kube. Während generate kube aus einem Podman-Pod ein Kubernetes-Manifest erzeugt, nimmt play kube ein Kubernetes-kompatibles YAML und erzeugt daraus lokale Podman-Pods und Container. Man könnte sagen: Es ist Kubernetes – auf einem einzelnen Host, ohne Scheduler, ohne Control Plane, aber mit denselben grundlegenden Pod- und Containerstrukturen. Für viele Entwickler ist podman play kube der schnellste Weg, Kubernetes-Manifeste lokal auszuführen, ohne ein Cluster wie Kind, Minikube oder K3s hochzufahren.

76.1 Kube-Manifest als Single-Node-Betriebssystem

Ein Kubernetes-Pod ist eine deklarative Beschreibung einer eng gekoppelten Containereinheit. podman play kube interpretiert diese Spezifikation und erzeugt aus ihr:

einen Podman-Pod
alle Container innerhalb dieses Pods
deren Ports
deren Volumes
deren Environment-Variablen

Die Idee ist bewusst pragmatisch: Kubernetes-Pods sollen nicht nur im Cluster, sondern auch lokal reproduzierbar sein. podman play kube erfüllt genau diese Brücke.

Diagramm:

Podman wird so zur lokalen Testmaschine für Kubernetes-Workloads.

76.2 Einfache Anwendung: YAML einspielen

Ein minimales Manifest:

apiVersion: v1
kind: Pod
metadata:
  name: demo
spec:
  containers:
    - name: app
      image: nginx:latest
      ports:
        - containerPort: 80

Ausführen:

podman play kube demo.yaml

Podman erzeugt:

den Pod demo
den Container app
ein lokales Netzwerk
Portfreigaben → -p wird automatisch abgeleitet

Das Ergebnis fühlt sich an wie Kubernetes, ohne dass eine einzige Kubernetes-Komponente läuft.

76.3 Unterstützte Kubernetes-Ressourcen

podman play kube unterstützt nicht alle Kubernetes-Objekttypen, aber überraschend viele für Pods relevante Strukturen:

Pod
Service (ClusterIP → lokaler Loadbalancer-Ersatz)
ConfigMap (als einfache Datei-Inhalte)
Volumes (hostPath, emptyDir)
Init-Container
Ports und Environment-Variablen
Pod-Annotations und Labels (eingeschränkt)

Nicht unterstützt:

Deployments
StatefulSets
Jobs/CronJobs
DaemonSets
Ingress
ConfigMap-Projektionen wie Key-Mappings
Secret-Management mit Kubernetes-Semantik

Man muss sich klar machen: play kube ist ein Interpreter für Pod-Spezifikationen, kein Mini-Kubernetes.

76.4 Warum „play“?

Der Name ist treffend: play kube bedeutet wörtlich „spiele dieses Kubernetes-Manifest“. Es führt die YAML-Struktur aus, als wäre sie eine direkte Anweisung an Podman.

Das macht das Tool ideal für:

Test-Deployments
Smoke-Tests für Containerimages
schnelle lokale Reproduktion von Cluster-Workloads
Demo- und Lab-Setups
CI-Schritte, die Kubernetes-Manifeste evaluieren

Ohne die Hürden eines Clusters kommt man damit sehr nah an das reale Verhalten im Pod.

76.5 Roundtrip-Fähigkeit: generate ↔︎ play

Eine der elegantesten Funktionen in Podman ist die Roundtrip-Fähigkeit:

podman generate kube mypod > manifest.yaml

und später:

podman play kube manifest.yaml

Damit entsteht ein reversibler Workflow:

Das ist mächtig, weil man Podman als lokale „Drafting Engine“ für Kubernetes benutzen kann.

76.6 Pod-Startverhalten: Unterschiede zu Kubernetes

Ein Kubernetes-Pod wird vom Control Plane orchestriert:

Scheduler entscheidet Node
Kubelet startet Container
Controller sorgen für Restarts

Bei Podman sieht es anders aus:

Kein Scheduler
Kein ReplicaSet
Keine Autoskalierung
Kein distributed Health Check

Das Pod-Verhalten ist puristisch: Der Pod existiert auf dem Host, weil Podman ihn erzeugt, und bleibt aktiv, bis er gestoppt wird.

Restart-Logik liegt außerhalb der YAML und muss über systemd realisiert werden, z. B.:

podman generate systemd mypod > mypod.service
systemctl enable mypod.service

Dadurch kombiniert man Podman-Pods + systemd-Supervision = Single-Node-Orchestrierung.

76.7 Networking: Wie Podman Kubernetes-Netze interpretiert

Podman emuliert einen Kubernetes-ähnlichen Netzwerkraum:

Jeder Pod erhält ein eigenes Netzwerk
Ports werden an den Host gemappt
Services werden als lokale Routingregeln abgebildet
Kein CNI-Plugin nötig

Beispiel YAML:

ports:
  - containerPort: 8080
    hostPort: 8080

Podman erstellt automatisch:

-p 8080:8080

Wer ein Service-Objekt definiert:

kind: Service
spec:
  ports:
    - port: 80
      targetPort: 8080

erhält ein local-only Service-Binding.

76.8 Init-Container: voll unterstützte Kubernetes-Semantik

Init-Container sind ein gutes Beispiel für API-Semantik, die Podman technisch exakt unterstützt:

initContainers:
  - name: init-db
    image: busybox
    command: ["sh", "-c", "echo init > /work/init"]

podman play kube:

startet erst den Init-Container
wartet, bis er erfolgreich beendet wurde
startet erst danach die regulären Container

Das entspricht 1:1 der Kubernetes-Mechanik.

76.9 Volumes und Datenhaltung

Unterstützt werden unter anderem:

hostPath
emptyDir

Beispiel:

volumes:
  - name: data
    hostPath:
      path: /var/data/demo

containers:
  - name: app
    volumeMounts:
      - name: data
        mountPath: /data

Podman erzeugt exakt diese Bind-Mounts.

Nicht unterstützt werden:

PersistentVolumeClaims
CSI-Volumes
dynamische Provisioner

Es bleibt ein Single-Node-Datenmodell – aber für Entwicklungsumgebungen ist das vollkommen ausreichend.

76.10 Mehrwert im Architekturprozess

podman play kube ist ein ausgesprochen nützliches Werkzeug für Architekten:

Validate Kubernetes-Manifeste ohne Cluster
Experimentieren mit Pod-Layouts
Testen von Sidecar-Patterns
Analyse von Netzwerkbeziehungen
Prototyping von CI/CD-Komponenten

Ein Vorteil, den Architekten besonders schätzen: Fehler im Kubernetes-YAML werden nicht erst im Cluster entdeckt. Podman bricht sofort ab, wenn das Manifest syntaktisch oder semantisch unlogisch ist.

76.11 Vergleich: Kubernetes vs. Podman play kube

Kubernetes hat ein Orchestrierungsgefüge. Podman spielt nur die Pod-Spezifikation aus.

podman play kube verwandelt Kubernetes-Manifeste in ausführbare Single-Node-Workloads. Es ist kein Ersatz für eine Kubernetes-Installation, aber ein brillantes Werkzeug für lokale Entwicklung, Tests und CI-Prototypen – und damit ein unverzichtbares Bindeglied zwischen Container-Engine und Orchestrator.