Kubernetes / Helm
Version auswählen, Feldfehler untersuchen und einzelne Ressourcen aus dem Manifest exportieren.
Ergebnis veraltet. Erneut formatieren.
Manifeste und eigene Schemas bleiben im Browser. Es wird keine Clusterverbindung aufgebaut.
Ergebnis veraltet. Erneut formatieren.
Statische Prüfungen garantieren kein Deployment. YAML lässt sich auch mit Validierungsfehlern exportieren; zuerst die Diagnosen lesen.
Kubernetes YAML validieren hilft vor allem dann, wenn ein Parser keinen Syntaxfehler findet, die Konfiguration aber trotzdem fragwürdig bleibt. Ein korrekt eingerücktes Feld kann am falschen Ort stehen oder den falschen Datentyp haben. Die Dokumentnummer hält den Befund mit der betroffenen Ressource zusammen.
Für Kubernetes-Manifeste stehen die festen Schemastände 1.35.0, 1.36.0 und 1.37.0 bereit. Das Werkzeug liest keine kubeconfig und bestimmt keine Cluster-Version automatisch. Ein Ergebnis bezieht sich auf den ausgewählten Stand und den gerade eingegebenen Inhalt.
Kubernetes YAML validieren heißt hier auch, Ressourcen nach kind, Namespace und Name zu unterscheiden. Diagnosen nennen Dokument, Zeile, Spalte und Feldpfad. Die Auswahl eines einzelnen Dokuments ändert nur die Ausgabe; der gesamte Eingabestrom bleibt für die Prüfung erhalten.
Service-Selektoren werden mit Pod-Labels und Workload-Templates im selben Namespace verglichen. Referenzen auf ConfigMaps und Secrets werden ebenfalls gesucht. Ein fehlendes Objekt wird als Hinweis gemeldet, weil es bereits im Cluster existieren kann, ohne in dieser Eingabe enthalten zu sein.
Voreingestellt ist 1.37.0. Änderungen an Inhalt, Version, Einrückung oder eigenem Schema sperren den Export des alten Ergebnisses. Die Prüfung startet per Schaltfläche oder Ctrl/Cmd+Enter. Eine automatische Prüfung während des Tippens findet nicht statt.
Für eine Custom Resource apiVersion und kind zusammen mit einem Draft-07-Schema eintragen. Nur exakt passende Ressourcen verwenden diese Definition. Interne Referenzen funktionieren; fehlende externe Referenzen führen zu einem Fehler statt zu einem Download.
Formatieren und Zusammenführen zeigen vor dem Ersetzen Zeichen- und Dokumentzahlen. Erst Übernehmen ändert die Eingabe. Rückgängig stellt Eingabe und vorheriges Ergebnis gemeinsam wieder her. Für den Export lässt sich zwischen allen Dokumenten und einer Ressource wechseln.
Die mitgelieferten Schemas stammen aus einem festgeschriebenen Registry-Commit und wurden aus Kubernetes OpenAPI abgeleitet. Sie prüfen zusätzliche Felder, Pflichtwerte und Typen. Pro Ressource erscheint zunächst der erste Schemafehler; nach einer Korrektur kann ein weiterer sichtbar werden.
Für verbreitete Typen gelten DNS-Namensprüfungen, für RBAC gelten Regeln für Pfadsegmente. API-Gruppe, kind, Namespace und Name bestimmen eine doppelte Identität; die API-Version unterscheidet dasselbe Objekt nicht. Nicht abgedeckte Namensregeln bleiben ausdrücklich offen. Job-Namen sind auf 63 Zeichen begrenzt, CronJob-Namen auf 52.
Neben Pods werden unter anderem Deployment-, StatefulSet-, Job- und CronJob-Templates berücksichtigt. Untersucht werden Umgebungsvariablen, Volumes und projizierte Volumes mit ConfigMap- oder Secret-Verweisen. Weder einzelne Konfigurationsschlüssel noch tatsächliche Netzwerkverbindungen werden getestet.
Die Formatierung arbeitet auf dem YAML-Syntaxbaum. Kommentare, Anker und numerische Quellschreibweisen bleiben erhalten. Lokale Dateien lassen sich verbinden und Dokumente einzeln exportieren. Ressourcen werden dabei weder sortiert noch automatisch von unbekannten Feldern bereinigt.
So lassen sich Feldfehler bereits bei der Durchsicht finden. Kubernetes YAML validieren kann eine falsche Einrückung von einem falschen Feldtyp unterscheiden. Die spätere Prüfung im Zielcluster bleibt notwendig, weil dessen Zulassungsregeln und aktueller Zustand hier nicht bekannt sind.
Nein. Das Ergebnis beschreibt statische Checks anhand eines festen Schemas. Berechtigungen, Admission-Webhooks, Quotas, Images und Laufzeitbedingungen können eine Anwendung weiterhin verhindern. Verwenden Sie den Befund als Teil der Prüfung, nicht als Deployment-Freigabe.
Unbekannte eigene Ressourcen brauchen ein vom Benutzer bereitgestelltes Schema. Der Inhalt einer CRD wird nicht automatisch als Definition für andere Dokumente übernommen. Kubernetes-Erweiterungen wie CEL werden nicht ausgeführt; vollständige serverseitige Semantik ist daher nicht abgedeckt.
Ja, bis zu 100 mit --- getrennte Dokumente. Nichtleere Dokumente erscheinen einzeln in der Ressourcenliste und lassen sich separat speichern. Ein List-Objekt wird dagegen ausdrücklich nicht aufgelöst oder als Sammlung geprüfter items behandelt.
Als Kubernetes-YAML-Validator prüft die Seite Ressourcen gegen mitgelieferte oder eigene Definitionen. Ein eigenes Draft-07-Schema wird vor seiner Verwendung überprüft. Für unabhängige Schemaentwicklung oder allgemeine Konfigurationsdateien ist ein spezialisierter JSON-Schema- beziehungsweise YAML-Prüfer geeigneter.
Ein Ergebnis ist unklar?
Kubernetes YAML validieren lässt sich in die normale Review-Routine aufnehmen: Version festhalten, Befunde korrigieren, erneut prüfen und genau den benötigten Dokumentumfang exportieren.