Kubernetes-YAML-validator
Plak een of meer Kubernetes-manifests (gescheiden door ---) en valideer ze tegen het echte schema voordat je kubectl apply uitvoert.
Sleep hier een .yaml/.yml-bestand naartoe, of plak de manifesttekst hierboven.
Manifests gescheiden door "---" worden als aparte documenten gevalideerd.
Geavanceerde opties
Parsen en validatie draaien in je browser — alleen het resource-schema (nooit je manifest) wordt van een openbare CDN gehaald.
Plak hierboven een Kubernetes-manifest (of laad het voorbeeld) en de validatieresultaten verschijnen hier.
Fouten in Kubernetes-manifests opsporen vóór kubectl dat doet
Een afgewezen `kubectl apply` is meestal het eerste moment waarop een fout in een Kubernetes-manifest zichtbaar wordt — en dan zit je vaak midden in een deployment en staar je naar een foutmelding met een JSON Schema-validatiepad (`spec.template.spec.containers[0].image: Required value`) dat niet vanzelfsprekend terug te herleiden is naar het YAML-bestand dat je net bewerkte. Dezelfde soort fouten eerder opsporen, met de exacte regel gemarkeerd, maakt er een oplossing van vijf seconden van in plaats van een contextwissel.
De syntaxis van YAML zelf heeft scherpe randen die je in de meeste andere configuratieformaten niet tegenkomt: inspringing is betekenisvol en inconsistente tabs/spaties leveren soms stilletjes een andere (verkeerde) structuur op in plaats van een fout, `---`-documentscheidingen raak je in een lang bestand met meerdere resources makkelijk kwijt, en een los extra nestniveau leest als geldige YAML terwijl het voor Kubernetes iets totaal anders betekent. Deze tool parset met dezelfde bibliotheekaanpak die tijdens het parsen alle bronposities bewaart, zodat een syntaxisprobleem wordt gemeld bij de echte regel waar het optreedt, en niet alleen "ergens in dit bestand van 200 regels".
Verouderde apiVersions zijn een val in slow motion: Deployments met `extensions/v1beta1`, StatefulSets en DaemonSets met `apps/v1beta1`/`apps/v1beta2` en Ingresses met `networking.k8s.io/v1beta1` parsen allemaal als volkomen geldige YAML en werkten zelfs op oudere clusters — tot het cluster wordt geüpgraded voorbij de versie waarin Kubernetes de oude API-groep definitief verwijdert, en elk manifest dat die gebruikt zonder voorafgaande waarschuwing niet meer wordt toegepast. Deze tijdens het bewerken opsporen (met de exacte vervangende apiVersion erbij) voorkomt dat je het pas tijdens een clusterupgrade ontdekt.
Schemavalidatie tegen de echte Kubernetes OpenAPI-specificatie vangt de rest: een `replicas`-veld dat als tekenreeks tussen aanhalingstekens is beland in plaats van als getal, een `containerPort` buiten het geldige bereik, een verplicht veld zoals `spec.selector` bij een Deployment dat is verdwenen tijdens het kopiëren tussen manifests. Geen van deze fouten is een YAML-syntaxisfout — het bestand parset prima — en juist daarom vangt een aparte schemacontrole wat een snelle visuele blik op het bestand meestal mist.
Veelgestelde vragen
Vervangt dit `kubectl apply --dry-run` of `kubeconform`?
Nee. `kubectl apply --dry-run=server` is de enige controle die draait tegen de API-server van je eigen cluster (inclusief eventuele geïnstalleerde CRD's en admission webhooks), en `kubeconform`/`kubeval` zijn volwassen CLI-tools voor CI-pijplijnen. Deze tool valideert dezelfde soort zaken — YAML-syntaxis, schemavorm, verouderde apiVersions — vanuit een browsertabblad, voordat je `kubectl` ergens op hebt ingesteld, of terwijl je een manifest beoordeelt dat iemand anders je heeft gestuurd.
Waar komen de schema's vandaan?
Van `yannh/kubernetes-json-schema`, een door de community onderhouden, automatisch bijgewerkte kopie van de JSON-schema's die uit de eigen OpenAPI-specificatie van Kubernetes zijn afgeleid. Ze worden op verzoek van een openbare CDN opgehaald voor de Kubernetes-versie die je kiest. Er wordt niets over je manifest verstuurd — alleen het (versiegebonden, openbare) schemabestand zelf wordt gedownload, hetzelfde bestand voor elke gebruiker die dat type/die versie valideert.
Waarom maar 10 resourcetypen?
Deployment, Service, Ingress, ConfigMap, Secret, StatefulSet, DaemonSet, Job, CronJob en PersistentVolumeClaim dekken het overgrote deel van met de hand geschreven manifests. Andere typen krijgen nog steeds een volledige YAML-syntaxiscontrole en detectie van verouderde apiVersions — alleen nog geen validatie van de schemavorm.
Verlaat mijn YAML ooit mijn browser?
Nee. Parsen en schemavalidatie draaien allebei met gewone JavaScript in dit tabblad — het enige netwerkverzoek dat deze tool ooit doet, is het ophalen van het openbare JSON Schema-bestand voor het resourcetype en de Kubernetes-versie die je hebt gekozen, nooit de inhoud van je manifest.