Vai al contenuto
100% Privacy — I file restano sul tuo dispositivo
>_
Italiano

Validatore YAML Kubernetes

Incolla uno o più manifest Kubernetes (separati da ---) e validali rispetto allo schema reale prima di eseguire kubectl apply.

Trascina qui un file .yaml/.yml, oppure incolla il testo del manifest sopra.

I manifest separati da "---" vengono convalidati come documenti separati.

Opzioni avanzate

L'analisi e la validazione vengono eseguite nel tuo browser — viene scaricato da un CDN pubblico solo lo schema della risorsa, mai il tuo manifest.

Incolla un manifest Kubernetes qui sopra (o carica l'esempio) e i risultati della validazione compariranno qui.

Individuare gli errori nei manifest Kubernetes prima di kubectl

Un `kubectl apply` rifiutato è di solito il primo momento in cui un errore in un manifest Kubernetes diventa visibile, e a quel punto sei spesso in pieno deploy, davanti a un messaggio che cita un percorso di validazione JSON Schema (`spec.template.spec.containers[0].image: Required value`) che non corrisponde in modo ovvio al file YAML che stavi modificando. Individuare lo stesso tipo di errore prima, con la riga esatta evidenziata, lo trasforma in una correzione di cinque secondi invece di un cambio di contesto.

La sintassi YAML ha spigoli che nella maggior parte degli altri formati di configurazione non esistono: l'indentazione è significativa e un mix incoerente di tab e spazi in certi casi produce in silenzio una struttura diversa (e sbagliata) invece di un errore, i separatori di documento `---` sono facili da perdere di vista in un lungo file con più risorse, e un livello di annidamento in più per errore è YAML perfettamente valido ma per Kubernetes significa tutt'altro. Questo strumento esegue il parsing con un approccio che conserva le informazioni di posizione nel sorgente, quindi un problema di sintassi viene segnalato sulla riga reale in cui si trova, non genericamente "da qualche parte in questo file di 200 righe".

Gli apiVersion deprecati sono una trappola più lenta: i Deployment `extensions/v1beta1`, gli StatefulSet e i DaemonSet `apps/v1beta1`/`apps/v1beta2` e gli Ingress `networking.k8s.io/v1beta1` si leggono ancora come YAML perfettamente valido e funzionavano pure sui cluster più vecchi, finché il cluster non viene aggiornato oltre la versione in cui Kubernetes rimuove definitivamente il vecchio gruppo API: da quel momento ogni manifest che lo usa smette di essere applicato, senza alcun avviso preventivo. Scoprirli mentre modifichi (con l'apiVersion sostitutivo esatto suggerito) evita di accorgersene durante un aggiornamento del cluster.

La validazione rispetto alle vere specifiche OpenAPI di Kubernetes intercetta il resto: un campo `replicas` finito tra virgolette come stringa invece che come numero, una `containerPort` fuori dall'intervallo valido, un campo obbligatorio come `spec.selector` in un Deployment cancellato per sbaglio mentre copiavi e incollavi tra manifest. Nessuno di questi è un errore di sintassi YAML, il file viene letto senza problemi, ed è proprio per questo che un passaggio dedicato sullo schema trova ciò che una rapida lettura a occhio del file di solito non vede.

Domande frequenti

Sostituisce `kubectl apply --dry-run` o `kubeconform`?

No. `kubectl apply --dry-run=server` è l'unico controllo che gira sull'API server del tuo cluster reale (inclusi CRD e admission webhook installati), mentre `kubeconform`/`kubeval` sono strumenti CLI maturi pensati per le pipeline CI. Qui si verifica lo stesso tipo di cose, cioè sintassi YAML, struttura dello schema e apiVersion deprecati, da una scheda del browser, prima ancora di avere `kubectl` configurato o mentre rivedi un manifest che ti ha mandato qualcun altro.

Da dove arrivano gli schemi?

Da `yannh/kubernetes-json-schema`, un mirror mantenuto dalla community e aggiornato automaticamente degli schemi JSON derivati dall'OpenAPI di Kubernetes, scaricati su richiesta da una CDN pubblica per la versione di Kubernetes che scegli. Del tuo manifest non viene inviato nulla: si scarica solo il file di schema pubblico e versionato, lo stesso per tutti gli utenti che validano quel kind e quella versione.

Perché solo 10 tipi di risorsa?

Deployment, Service, Ingress, ConfigMap, Secret, StatefulSet, DaemonSet, Job, CronJob e PersistentVolumeClaim coprono la grande maggioranza dei manifest scritti a mano. Gli altri kind ottengono comunque il controllo completo della sintassi YAML e il rilevamento degli apiVersion deprecati; semplicemente non hanno ancora la validazione della struttura dello schema.

Il mio YAML esce mai dal browser?

No. Il parsing e la validazione dello schema girano in JavaScript puro in questa scheda: l'unica richiesta di rete che lo strumento fa è scaricare il file JSON Schema pubblico per il tipo di risorsa e la versione di Kubernetes selezionati, mai il contenuto del tuo manifest.

Strumenti correlati