78 Validitätsniveau von YAML-Konvertierungen

YAML-Konvertierungen im Kontext von Containern und Kubernetes sind ein heikler Bereich. Werkzeuge wie podman generate kube oder podman play kube erzeugen und interpretieren YAML-Strukturen, die sich an Kubernetes orientieren, aber in ihrer Semantik, ihrem Umfang und ihrer Validität nicht vollständig Kubernetes-konform sind. Die Frage „Wie gültig ist dieses YAML?“ lässt sich nur beantworten, wenn man zwischen mehreren Validitätsebenen unterscheidet: syntaktisch, strukturell, semantisch und kontextuell. Jede Ebene beschreibt ein eigenes Maß an Korrektheit, das je nach Zielumgebung – Podman oder Kubernetes – unterschiedliche Bedeutung hat.

Ein YAML-Dokument kann formal korrekt sein und trotzdem im Kubernetes-Cluster sofort scheitern. Ebenso kann ein YAML für Podman lauffähig sein, aber in einem Kubernetes-Kontext unvollständig wirken. Die Validität ist also relativ zum Ausführungsraum.

78.1 Vier Ebenen der Validität

YAML-Strukturen müssen auf vier Ebenen bestehen:

• syntaktische Validität: korrekte YAML-Form
• strukturelle Validität: gültige Objektform (kind, apiVersion, spec …)
• semantische Validität: sinnvolle und umsetzbare Inhalte
• kontextuelle Validität: gültig im Zielsystem (Podman vs. Kubernetes)

Diese Ebenen beeinflussen einander, sind aber nicht deckungsgleich.

78.1.1 Syntaktische Validität

Eine reine YAML-Prüfung (via Linter oder Parser) checkt nur:

• korrekte Einrückungen
• gültige Schlüssel-Wert-Paare
• Listenstrukturen
• Datentypen

Ein Beispiel, das syntaktisch gültig ist, aber funktional wertlos:

foo: bar
baz:
  - 123

Podman und Kubernetes ignorieren es vollständig.

78.1.2 Strukturelle Validität

Dies prüft den „Skelettbau“ eines Kubernetes-Objekts:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: app
      image: nginx

Das YAML erfüllt das Minimum dessen, was Kubernetes oder Podman interpretieren kann. podman play kube erwartet genau diese Minimalstruktur – nicht mehr, nicht weniger.

Fehlt eine Ebene, verweigert Podman die Ausführung sofort:

Error: no containers defined in spec

Diese strukturelle Validität ist bei Podman strikter als bei Kubernetes, weil Podman nur Pod-Objekte interpretiert – kein Deployment, kein ReplicaSet, keine CRD.

78.1.3 Semantische Validität

Semantisch valide YAML ist logisch korrekt. Beispiele für semantische Fehler:

• Ein Container nutzt einen Port, der gar nicht existiert.
• Ein VolumeMount referenziert ein Volume, das nicht im Volumes-Block existiert.
• Ein Init-Container schreibt in ein Verzeichnis, das nicht gemountet wurde.

Podman erkennt viele dieser Fehler beim Ausführen:

Error: no such volume: data

Kubernetes validiert semantisch oft erst beim Scheduling oder während des Containerstarts.

78.1.4 Kontextuelle Validität

Hier beginnt die kritische Differenzierung:

• YAML, das in podman play kube gültig ist, kann in Kubernetes ungültig sein.
• YAML, das Kubernetes akzeptiert, kann für Podman vollkommen irrelevant sein.

Beispiel: podman play kube versteht keine Deployments:

kind: Deployment

Podman bricht ab:

Error: unsupported kind "Deployment"

Umgekehrt versteht Kubernetes zwar Pods, aber „hostPort“ oder filesystemnahe Optionen haben möglicherweise andere Auswirkungen.

Kontextuelle Validität ist also das entscheidende Kriterium bei YAML-Konvertierungen.

78.2 Das Validitätsniveau von podman generate kube

podman generate kube zielt bewusst auf ein interoperables Minimum. Es erzeugt YAML, das folgende Eigenschaften besitzt:

• syntaktisch korrekt
• strukturell korrekt für pod-basierte Kubernetes-Objekte
• semantisch korrekt bezogen auf den lokalen Pod
• konzeptionell übertragbar – aber nicht vollständig Kubernetes-idiomatisch

Das generierte YAML ist „Cluster-fähig“, aber nicht „Cluster-optimal“.

Typische Einschränkungen:

• keine Deployments
• keine Probes (liveness, readiness, startup)
• keine Ressourcenlimits
• keine PodSecurityContext-Optionen
• keine Affinity/NodeSelector-Spezifikationen
• kein komplettes Service-Labeling

Podman erzeugt also Kubernetes-YAML, das im Kern funktioniert, aber für Produktion überprüft und erweitert werden muss.

Ein Diagramm zur Qualitätsstufe:

Der letzte Punkt ist entscheidend: Das YAML ist „minimal funktionsfähig“.

78.3 Das Validitätsniveau von podman play kube

podman play kube verarbeitet Kubernetes-YAML selektiv. Es versteht nur:

• Pod
• Service
• ConfigMap (Basics)
• Volumes (hostPath, emptyDir)

Alles darüber hinaus ignoriert oder bricht Podman ab. Eine Deployment-Datei führt zu einem Fehler, selbst wenn der eingebettete Pod korrekt wäre.

play kube kennt keine CRDs, keine HorizontalPodAutoscaler, keine StatefulSets. Es unterstützt das YAML-Subset, das der lokale Podman-Pod modellieren kann.

Das Validitätsniveau ist damit:

• syntaktische Validität → erforderlich
• strukturelle Validität → sehr strikt, auf Pods beschränkt
• semantische Validität → teilweise geprüft, zur Laufzeit sichtbar
• kontextuelle Validität → nur für Podman, nicht für Kubernetes allgemein

78.4 Validitätsprobleme bei Roundtrips

Ein Roundtrip:

podman generate kube → YAML → podman play kube

ergibt vollständige Roundtrip-Validität. Doch ein Roundtrip mit Kubernetes:

podman generate kube → kubectl apply → Kubernetes → export → podman play kube

führt fast immer zu Validitätsverlust:

• Kubernetes fügt eigene Felder ein
• Ressourcenlimits werden ergänzt
• Volume- und Mount-Spezifikationen ändern sich
• Podman kann einige Felder nicht interpretieren
• initContainers oder ServiceAccounts werden erweitert

Podman akzeptiert dieses YAML nicht mehr, obwohl Kubernetes es validiert.

Damit entstehen zwei Validitätsräume:

• Podman-valid
• Kubernetes-valid

Sie überlappen, aber decken sich nie vollständig.

78.5 Praktischer Umgang mit Validitätsniveaus

Erfahrene Architekten betrachten Podman-YAML nicht als „normgerechtes“ Kubernetes-YAML, sondern als „funktional übersetztes YAML“ – ein Prototyp, kein Finale.

Vorgehen:

1. Podman als Entwicklungs-Engine benutzen
2. generate kube einsetzen für Basis-YAML
3. YAML manuell erweitern (Deployments, Probes, Limits …)
4. Im Cluster validieren
5. Podman nur noch als Test-Interpreter für Pod-Semantik nutzen

Damit trennt man die Validitätsräume sauber.

Das Validitätsniveau von YAML-Konvertierungen entscheidet über die Übertragbarkeit zwischen Podman und Kubernetes. Wer diese Ebenen präzise versteht, nutzt Podman bewusst als Werkzeug – nicht als Orchestratorersatz – und setzt Kubernetes-YAML nicht als rein syntaktisches Konstrukt ein, sondern als deklaratives, kontextspezifisches Systemmodell.