Kubernetes-YAML-Prüfer
Füge ein oder mehrere Kubernetes-Manifeste (getrennt durch ---) ein und prüfe sie gegen das echte Schema, bevor du kubectl apply ausführst.
Lege hier eine .yaml/.yml-Datei ab, oder füge den Manifest-Text oben ein.
Durch "---" getrennte Manifeste werden als eigenständige Dokumente geprüft.
Erweiterte Optionen
Parsen und Validierung laufen in deinem Browser — nur das Ressourcen-Schema (niemals dein Manifest) wird von einem öffentlichen CDN geladen.
Füge oben ein Kubernetes-Manifest ein (oder lade das Beispiel), dann erscheinen hier die Prüfergebnisse.
Fehler in Kubernetes-Manifesten finden, bevor kubectl es tut
Ein abgelehntes `kubectl apply` ist meist der erste Moment, in dem ein Fehler im Kubernetes-Manifest sichtbar wird – und dann steckst du oft mitten im Deployment und starrst auf eine Fehlermeldung, die einen JSON-Schema-Validierungspfad zitiert (`spec.template.spec.containers[0].image: Required value`), der sich nicht offensichtlich auf die gerade bearbeitete YAML-Datei zurückführen lässt. Wird derselbe Fehlertyp früher gefunden, mit exakt markierter Zeile, wird daraus ein Fünf-Sekunden-Fix statt eines Kontextwechsels.
Die YAML-Syntax hat Tücken, die in den meisten anderen Konfigurationsformaten fehlen: Einrückung ist bedeutsam, und gemischte Tabs und Leerzeichen erzeugen mitunter stillschweigend eine andere (falsche) Struktur statt eines Fehlers. Die Trenner `---` verliert man in einer langen Datei mit mehreren Ressourcen leicht aus den Augen, und eine überzählige Verschachtelungsebene sieht wie gültiges YAML aus, bedeutet für Kubernetes aber etwas völlig anderes. Dieses Tool parst mit einem Ansatz, der die Quellposition durchgehend mitführt, sodass ein Syntaxproblem in der tatsächlichen Zeile gemeldet wird und nicht bloß „irgendwo in dieser 200 Zeilen langen Datei“.
Veraltete apiVersions sind eine Falle in Zeitlupe: `extensions/v1beta1`-Deployments, `apps/v1beta1`/`apps/v1beta2`-StatefulSets und -DaemonSets sowie `networking.k8s.io/v1beta1`-Ingresses sind weiterhin vollkommen gültiges YAML und liefen auf älteren Clustern sogar – bis der Cluster über die Version hinaus aktualisiert wird, in der Kubernetes die alte API-Gruppe endgültig entfernt. Dann lässt sich jedes Manifest, das sie nutzt, ohne Vorwarnung nicht mehr anwenden. Findest du das schon beim Bearbeiten (mit der vorgeschlagenen neuen apiVersion), erlebst du es nicht erst beim Cluster-Upgrade.
Die Schemaprüfung gegen die echte Kubernetes-OpenAPI-Spezifikation fängt den Rest ab: ein Feld `replicas`, das als String in Anführungszeichen statt als Zahl endete, ein `containerPort` außerhalb des gültigen Bereichs, ein Pflichtfeld wie `spec.selector` bei einem Deployment, das beim Kopieren zwischen Manifesten verloren ging. Nichts davon ist ein YAML-Syntaxfehler – die Datei lässt sich problemlos parsen –, und genau deshalb findet ein eigener Schemadurchlauf, was ein kurzer Blick auf die Datei meist übersieht.
Häufig gestellte Fragen
Ersetzt das `kubectl apply --dry-run` oder `kubeconform`?
Nein. `kubectl apply --dry-run=server` ist die einzige Prüfung, die gegen den API-Server deines echten Clusters läuft (inklusive aller dort installierten CRDs und Admission-Webhooks), und `kubeconform`/`kubeval` sind ausgereifte CLI-Tools für CI-Pipelines. Dieses Tool prüft dieselbe Art von Dingen – YAML-Syntax, Schema-Struktur, veraltete apiVersions – direkt aus einem Browser-Tab, bevor du `kubectl` überhaupt mit etwas verbunden hast, oder beim Review eines Manifests, das dir jemand geschickt hat.
Woher stammen die Schemas?
Von `yannh/kubernetes-json-schema`, einem von der Community gepflegten, automatisch aktualisierten Spiegel der aus der OpenAPI-Spezifikation abgeleiteten JSON-Schemas von Kubernetes. Sie werden bei Bedarf von einem öffentlichen CDN für die gewählte Kubernetes-Version geladen. Nichts aus deinem Manifest wird irgendwohin gesendet – heruntergeladen wird nur die (versionierte, öffentliche) Schemadatei selbst, dieselbe für alle, die diesen Typ in dieser Version prüfen.
Warum nur 10 Ressourcentypen?
Deployment, Service, Ingress, ConfigMap, Secret, StatefulSet, DaemonSet, Job, CronJob und PersistentVolumeClaim decken den Großteil handgeschriebener Manifeste ab. Andere Typen bekommen weiterhin die volle YAML-Syntaxprüfung und die Erkennung veralteter apiVersions – nur noch keine Prüfung der Schema-Struktur.
Verlässt mein YAML jemals meinen Browser?
Nein. Parsen und Schemaprüfung laufen mit reinem JavaScript in diesem Tab – die einzige Netzwerkanfrage dieses Tools ist das Laden der öffentlichen JSON-Schema-Datei für den gewählten Ressourcentyp und die gewählte Kubernetes-Version, niemals der Inhalt deines Manifests.