Kubernetes-YAML-validerare
Klistra in en eller flera Kubernetes-manifest (åtskilda med ---) och validera dem mot det verkliga schemat innan du kör kubectl apply.
Släpp en .yaml/.yml-fil här, eller klistra in manifesttexten ovan.
Manifest åtskilda med "---" valideras som separata dokument.
Avancerade alternativ
Tolkning och validering körs i din webbläsare. Bara schemafiler hämtas från ett offentligt CDN: resursschemat och, för anpassade resurser, posten i CRD-katalogen — de begärs enbart via group/kind/version, ditt manifest skickas aldrig.
Klistra in ett Kubernetes-manifest ovan (eller läs in exemplet) så visas valideringsresultaten här.
Fånga fel i Kubernetes-manifest innan kubectl gör det
Ett avvisat `kubectl apply` är oftast första gången ett fel i ett Kubernetes-manifest blir synligt — och då är du ofta mitt i en driftsättning och stirrar på ett felmeddelande som citerar en JSON Schema-valideringssökväg (`spec.template.spec.containers[0].image: Required value`) som inte självklart går att koppla tillbaka till YAML-filen du just redigerade. Att fånga samma typ av fel tidigare, med exakt rad markerad, gör det till en fix på fem sekunder i stället för ett kontextbyte.
YAML har egna vassa kanter som inte syns i de flesta andra konfigurationsformat: indragen är betydelsebärande och inkonsekventa tabbar/blanksteg ger i vissa fall tyst en annan (fel) struktur i stället för ett fel, avgränsare med `---` är lätta att tappa bort i en lång fil med flera resurser, och en extra nivå av nästling ser ut som giltig YAML men betyder något helt annat för Kubernetes. Det här verktyget tolkar med ett bibliotek som behåller full information om källpositioner under tolkningen, så ett syntaxproblem rapporteras på den faktiska raden där det uppstår, inte bara "någonstans i den här filen på 200 rader".
Föråldrade apiVersion är en fälla i slow motion: `extensions/v1beta1`-Deployments, `apps/v1beta1`/`apps/v1beta2`-StatefulSets och -DaemonSets samt `networking.k8s.io/v1beta1`-Ingresses tolkas fortfarande som helt giltig YAML och fungerade till och med på äldre kluster — tills klustret uppgraderas förbi den version där Kubernetes slutligen tar bort den gamla API-gruppen helt, och varje manifest som använder den då slutar fungera vid apply utan förvarning. Att fånga dem under redigeringen (med exakt ersättande apiVersion föreslagen) gör att du slipper upptäcka det under en klusteruppgradering.
Schemavalidering mot den riktiga Kubernetes OpenAPI-specifikationen fångar resten: ett `replicas`-fält som blev en sträng inom citationstecken i stället för ett tal, en `containerPort` utanför det giltiga intervallet, ett obligatoriskt fält som `spec.selector` i en Deployment som försvann vid copy-paste mellan manifest. Inget av detta är YAML-syntaxfel — filen tolkas utan problem — och just därför fångar ett dedikerat schemasteg det som en snabb visuell genomläsning av filen oftast missar.
Vanliga frågor
Ersätter det här `kubectl apply --dry-run` eller `kubeconform`?
Nej. `kubectl apply --dry-run=server` är den enda kontrollen som körs mot ditt faktiska klusters API-server (inklusive alla CRD:er och admission webhooks som är installerade), och `kubeconform`/`kubeval` är mogna kommandoradsverktyg byggda för CI-pipelines. Det här verktyget validerar samma typ av saker — YAML-syntax, schemats form, föråldrade apiVersion — från en webbläsarflik, innan du har `kubectl` konfigurerat mot något, eller när du granskar ett manifest som någon annan skickat dig.
Var kommer schemana ifrån?
Från `yannh/kubernetes-json-schema`, en community-underhållen och automatiskt uppdaterad spegling av Kubernetes egna OpenAPI-baserade JSON-scheman, som hämtas vid behov från ett offentligt CDN för den Kubernetes-version du väljer. Ingenting om ditt manifest skickas någonstans — bara själva (versionerade, offentliga) schemafilen laddas ner, samma fil för alla som validerar den typen och versionen.
Varför bara 10 resurstyper?
Deployment, Service, Ingress, ConfigMap, Secret, StatefulSet, DaemonSet, Job, CronJob och PersistentVolumeClaim täcker de allra flesta manifest som skrivs för hand. Övriga typer får ändå full kontroll av YAML-syntax och upptäckt av föråldrade apiVersion — de får bara inte validering av schemats form ännu.
Lämnar min YAML någonsin webbläsaren?
Nej. Både tolkning och schemavalidering körs med vanlig JavaScript i den här fliken — den enda nätverksbegäran som verktyget gör är att hämta den offentliga JSON Schema-filen för den resurstyp och Kubernetes-version du valt, aldrig innehållet i ditt manifest.