Saltar al contenido
100% Privacidad — Tus archivos permanecen en tu dispositivo
>_
Español

Validador YAML de Kubernetes

Pega uno o varios manifiestos de Kubernetes (separados por ---) y valídalos contra el esquema real antes de hacer kubectl apply.

Arrastra un archivo .yaml/.yml aquí, o pega el texto del manifiesto arriba.

Los manifiestos separados por "---" se validan como documentos independientes.

Opciones avanzadas

El análisis y la validación se ejecutan en tu navegador — solo el esquema del recurso (nunca tu manifiesto) se descarga de una CDN pública.

Pega arriba un manifiesto de Kubernetes (o carga el ejemplo) y los resultados de la validación aparecerán aquí.

Detectar errores en manifiestos de Kubernetes antes que kubectl

Un `kubectl apply` rechazado suele ser la primera vez que se hace visible un error en un manifiesto de Kubernetes, y para entonces es habitual que estés en pleno despliegue, mirando un mensaje que cita una ruta de validación de JSON Schema (`spec.template.spec.containers[0].image: Required value`) que no se relaciona de forma evidente con el archivo YAML que acabas de editar. Detectar el mismo tipo de error antes, con la línea exacta resaltada, lo convierte en una corrección de cinco segundos en lugar de un cambio de contexto.

La sintaxis de YAML tiene aristas que no aparecen en la mayoría de los demás formatos de configuración: la sangría es significativa y mezclar tabuladores y espacios puede producir en silencio una estructura distinta (y errónea) en lugar de un error; los separadores de documento `---` son fáciles de perder de vista en un archivo largo con varios recursos; y un nivel extra de anidamiento se lee como YAML válido pero significa algo totalmente distinto para Kubernetes. Esta herramienta analiza el YAML con un enfoque que conserva toda la información de posición del código fuente, así que un problema de sintaxis se notifica en la línea real donde ocurre, y no solo como «en algún lugar de este archivo de 200 líneas».

Las apiVersions obsoletas son una trampa de acción más lenta: los Deployments con `extensions/v1beta1`, los StatefulSets y DaemonSets con `apps/v1beta1`/`apps/v1beta2` y los Ingress con `networking.k8s.io/v1beta1` siguen siendo YAML perfectamente válido e incluso funcionaban en clústeres antiguos, hasta que el clúster se actualiza más allá de la versión en la que Kubernetes elimina por completo el grupo de API antiguo; a partir de ahí, todos los manifiestos que lo usan dejan de aplicarse sin aviso previo. Detectarlas mientras editas, con la apiVersion de reemplazo sugerida, evita enterarte durante una actualización del clúster.

La validación del esquema contra la especificación OpenAPI real de Kubernetes se encarga del resto: un campo `replicas` que acabó como cadena entre comillas en lugar de número, un `containerPort` fuera del rango válido, un campo obligatorio como `spec.selector` en un Deployment que se borró al copiar y pegar entre manifiestos. Ninguno de estos es un error de sintaxis YAML (el archivo se analiza sin problemas), y justo por eso una pasada específica de esquema detecta lo que una lectura visual rápida del archivo suele pasar por alto.

Preguntas frecuentes

¿Sustituye esto a `kubectl apply --dry-run` o a `kubeconform`?

No. `kubectl apply --dry-run=server` es la única comprobación que se ejecuta contra el servidor de la API de tu clúster real (incluidos los CRD y webhooks de admisión que tenga instalados), y `kubeconform`/`kubeval` son herramientas de línea de comandos maduras pensadas para pipelines de CI. Esta herramienta valida el mismo tipo de cosas (sintaxis YAML, forma del esquema, apiVersions obsoletas) desde una pestaña del navegador, antes de tener `kubectl` configurado contra nada o mientras revisas un manifiesto que te ha enviado otra persona.

¿De dónde salen los esquemas?

De `yannh/kubernetes-json-schema`, un espejo mantenido por la comunidad y actualizado automáticamente de los JSON Schema que Kubernetes deriva de su propio OpenAPI, que se obtienen bajo demanda desde un CDN público para la versión de Kubernetes que elijas. Nada de tu manifiesto se envía a ningún sitio: solo se descarga el archivo de esquema (público y versionado), el mismo para todos los usuarios que validan ese tipo y versión.

¿Por qué solo 10 tipos de recurso?

Deployment, Service, Ingress, ConfigMap, Secret, StatefulSet, DaemonSet, Job, CronJob y PersistentVolumeClaim cubren la gran mayoría de los manifiestos escritos a mano. Los demás tipos igualmente reciben la comprobación completa de sintaxis YAML y la detección de apiVersions obsoletas; simplemente aún no tienen validación de la forma del esquema.

¿Mi YAML sale alguna vez de mi navegador?

No. El análisis y la validación del esquema se ejecutan con JavaScript simple en esta pestaña. La única petición de red que hace esta herramienta es descargar el archivo JSON Schema público del tipo de recurso y de la versión de Kubernetes que hayas elegido, nunca el contenido de tu manifiesto.

Herramientas relacionadas