Qué hace este validador
Los manifests de Kubernetes parecen YAML normal, pero la validación real vive dentro del cluster: `kubectl apply` acepta un fichero y solo más tarde, tras que el API server lo resuelva contra el schema en vivo y los admission controllers, descubres que algo está mal. Para entonces puedes tener un Deployment mal configurado corriendo en producción sin liveness probe, sin resource limits, y un Service que no enruta a sus pods porque el label selector no coincide.
Esta herramienta pilla los 30 errores principales antes de que apliques. Pega cualquier manifest K8s, ficheros multi-documento con separadores `---` incluidos. El validador parsea cada documento, detecta el kind y ejecuta comprobaciones hechas a mano: `apiVersion` o `metadata.name` ausentes, Service `targetPort` que no existe en el pod, selector de Deployment que no coincide con las labels del pod, contenedores `privileged: true`, tags `:latest`, resource limits y probes ausentes, Ingress en una versión de API obsoleta, PVCs sin tamaño de almacenamiento.
Todo corre en tu navegador. Sin subidas, sin kubectl, sin contacto con cluster. El validador no descarga schemas de CRD en vivo (esos viven en tu cluster específico), así que los recursos custom se muestran solo como info.
Cómo usarlo
- Elige una muestra arriba para ver cómo se ve la salida, o pega tu propio YAML en el panel de entrada. El validador gestiona ficheros multi-documento con separadores `---`.
- Lee los contadores de error / warning / info a la derecha. Los errores significan que el manifest será rechazado por el API server o se comportará roto (campos ausentes, selectores no coincidentes, HPA inválido). Los warnings son violaciones de buenas prácticas (tag `:latest`, sin resource limits, `privileged: true`). Los info son sugerencias.
- Cada issue lista el kind, el nombre del recurso, el índice del documento (qué manifest en un fichero multi-doc), el mensaje y una pista de arreglo.
- Arreglos comunes cubiertos: añadir liveness/readiness probes, configurar resource requests y limits, quitar hostPort, reemplazar `:latest` por un tag fijo, alinear selector matchLabels con template metadata.labels, configurar HPA scaleTargetRef y un rango válido de min/max replicas.
- Para Services, el validador comprueba cruzadamente que el `targetPort` existe realmente como `containerPort` en el pod seleccionado por `spec.selector`. Esto pilla el error clásico de un Service que enruta silenciosamente a nada.
- Cuando la entrada está vacía o el parseo YAML falla, recibes un error de parseo con el número de línea de js-yaml. Arregla eso primero y el resto de comprobaciones se encienden.
- Pulsa Copiar para poner el manifest en tu portapapeles, luego mételo en `kubectl apply -f -` para desplegar de verdad. El validador nunca envía tu YAML a ningún sitio.
Cuándo es útil
Siete situaciones concretas en las que pillar errores K8s antes de kubectl apply ahorra downtime real:
- Primera vez tocando K8s. La documentación oficial es enorme y todavía no tienes intuición de qué campos son obligatorios. El validador marca `apiVersion`, `kind`, `metadata.name` ausentes inmediatamente y da una pista de arreglo para cada uno.
- Service que no conecta con nada. El error clásico: el selector del Service dice `app: web`, las labels del template del Deployment dicen `app: api`. K8s crea el Service, el Service no tiene endpoints, el tráfico devuelve 503s. El validador dice exactamente qué claves no coinciden.
- Puerta pre-commit para repos K8s. Enchufa la comprobación de salida del validador en tu proceso de revisión. Los PRs que introducen `privileged: true`, `:latest`, limits ausentes, probes ausentes se marcan antes del merge.
- Comprobación de salud de repo GitOps. Un repo con cientos de manifests es difícil de auditar a ojo. Pega un fichero, ve todas las issues a la vez. Repite por fichero o conéctalo a CI a mano.
- Migración de Ingress extensions/v1beta1 a networking.k8s.io/v1. El validador marca la versión de API antigua con un arreglo de una línea. Ahorra un deploy que devuelve 404 la próxima vez que el cluster se actualiza.
- CronJob sin limits corriendo en un nodo pequeño. Un backup nocturno sin memory limit puede OOM el nodo. El validador avisa sobre cada contenedor sin limits.
- HPA mal configurado para escalar solo entre 1 y 1. La comprobación pilla `minReplicas >= maxReplicas` (lo cual es inválido) y `scaleTargetRef` ausente (lo cual hace que el HPA no haga nada).