Validador de YAML de Kubernetes
Pega uno o varios manifiestos de Kubernetes y elige la versión de tu clúster. Cada documento se revisa en busca de errores de sintaxis YAML, apiVersions eliminadas u obsoletas, campos desconocidos o mal escritos, tipos de valor incorrectos, campos obligatorios y errores comunes como un selector que no coincide con las etiquetas del pod. Cada problema muestra su línea y la ruta del campo.
Última actualización:
Las comprobaciones se ejecutan en tu navegador con un esquema integrado de los tipos de recursos principales de Kubernetes. Los recursos personalizados (CRD) se enumeran pero no se comprueban.
Cómo usar Validador de YAML de Kubernetes
- Pega tus manifiestos o abre un archivo .yaml. Puedes incluir varios documentos separados por
---. - Elige tu versión de Kubernetes para que las API eliminadas y las nuevas se evalúen correctamente.
- Lee el resumen: cada documento aparece como válido, con advertencias, con errores o no comprobado (recursos personalizados).
- Haz clic en un problema para saltar a su línea en el editor. Las líneas con errores también se marcan en rojo en los números de línea.
- Corrige y vuelve a comprobar. La validación se repite mientras escribes; copia el informe para compartirlo en una revisión.
Errores comunes en el YAML de Kubernetes
| Escribiste | Qué ocurre | Solución |
|---|---|---|
replicas: "3" | Rechazado: replicas debe ser un entero | replicas: 3 |
value: 8080 en env | Rechazado: los valores de env son cadenas | value: "8080" |
Etiqueta version: 1.10 | Se lee como el número 1.1 y luego se rechaza | version: "1.10" |
enabled: on en un ConfigMap | YAML 1.1 lee on como true, que se rechaza en data | enabled: "on" |
memory: 512MB | Cantidad no válida | memory: 512Mi (o 512M) |
contianerPort: 80 | Campo desconocido: se rechaza en modo estricto y, si no, se descarta sin aviso | containerPort: 80 |
selector app: web, etiqueta del pod app: website | Deployment rechazado: el selector no coincide con la plantilla | Usa las mismas etiquetas en ambos sitios |
type: ClusterIp | Valor no admitido (los valores distinguen mayúsculas y minúsculas) | type: ClusterIP |
serviceName / servicePort en un Ingress | Sintaxis antigua de v1beta1, eliminada en 1.22 | service: {name: web, port: {number: 80}} y pathType |
apiVersion actual para cada kind
| Kind | Usar | Versiones eliminadas |
|---|---|---|
| Deployment, StatefulSet, DaemonSet, ReplicaSet | apps/v1 | extensions/v1beta1, apps/v1beta1, apps/v1beta2 (1.16) |
| Ingress, IngressClass | networking.k8s.io/v1 | extensions/v1beta1, networking.k8s.io/v1beta1 (1.22) |
| CronJob | batch/v1 | batch/v1beta1 (1.25) |
| HorizontalPodAutoscaler | autoscaling/v2 | v2beta1 (1.25), v2beta2 (1.26) |
| PodDisruptionBudget | policy/v1 | policy/v1beta1 (1.25) |
| Role, ClusterRole, RoleBinding, ClusterRoleBinding | rbac.authorization.k8s.io/v1 | v1beta1 (1.22) |
| CustomResourceDefinition | apiextensions.k8s.io/v1 | v1beta1 (1.22) |
| Pod, Service, ConfigMap, Secret, PVC, Namespace, ServiceAccount | v1 | (nunca cambió) |
Consejos
- Valida también contra un clúster:
kubectl apply --dry-run=server -f file.yamltambién ejecuta los admission webhooks y las políticas. - Pon entre comillas todo lo que no sea a propósito un número o un booleano, sobre todo versiones, puertos en variables de entorno y palabras como yes, no, on y off.
- Genera un punto de partida correcto con el generador de YAML de Kubernetes, o convierte un archivo compose existente con el conversor Docker Compose a Kubernetes.
Preguntas frecuentes
¿Qué comprueba este validador de YAML de Kubernetes?
Primero la sintaxis YAML, con las reglas de YAML 1.1 como el servidor de API de Kubernetes. Después cada objeto se compara con un esquema de su kind y apiVersion: campos desconocidos, campos obligatorios, tipos de valor y valores permitidos. Por último ejecuta comprobaciones que el servidor de API realiza durante la validación, como que el selector de un Deployment coincida con las etiquetas de la plantilla del pod o que un volumeMount haga referencia a un volumen definido.
¿Por qué replicas: "3" es un error?
Los campos de Kubernetes tienen tipos estrictos. replicas es un entero, así que el servidor de API rechaza la cadena entre comillas "3". Lo contrario también es habitual: los valores de las variables de entorno y de las etiquetas deben ser cadenas, así que value: 4 o version: 1.2 necesitan comillas.
¿Qué apiVersions se eliminaron?
Eliminaciones importantes: Deployments, DaemonSets y ReplicaSets en extensions/v1beta1 y apps/v1beta1/v1beta2 en 1.16; Ingress en extensions/v1beta1 y networking.k8s.io/v1beta1, además de rbac v1beta1 y apiextensions v1beta1 en 1.22; CronJob de batch/v1beta1, PodDisruptionBudget de policy/v1beta1 y PodSecurityPolicy en 1.25; autoscaling/v2beta2 en 1.26; flowcontrol v1beta3 en 1.32. Elige tu versión para ver si un manifiesto se ve afectado.
¿Qué es el modo estricto?
Desde Kubernetes 1.25, el servidor de API puede rechazar campos desconocidos o duplicados, y las versiones recientes de kubectl validan de forma estricta por defecto. Si no, un campo mal escrito como contianerPort se descarta sin aviso, y el ajuste que querías nunca se aplica. Desactiva el modo estricto para que los campos desconocidos se muestren como advertencias.
¿Valida recursos personalizados (CRD)?
Los recursos personalizados, como los Certificates de cert-manager o las Applications de Argo CD, se reconocen como YAML válido, pero sus campos no se comprueban, porque sus esquemas están en los CRD instalados en tu clúster. Para ellos, usa kubectl apply --dry-run=server contra un clúster.
¿Es lo mismo que kubectl apply --dry-run?
Cubre el mismo esquema y muchas de las mismas reglas de validación, pero funciona sin conexión y sin clúster. Las ejecuciones de prueba en el servidor también aplican los admission webhooks, las cuotas y las políticas de tu clúster, así que pueden rechazar un manifiesto que aquí pasa la validación.
¿Se suben mis manifiestos?
No. El análisis y la validación se ejecutan en JavaScript en tu navegador; solo se descarga la biblioteca de código abierto del analizador YAML. Los Secrets y los nombres internos de tus manifiestos se quedan en tu equipo.
¿Se prueban todas las herramientas de FreeToolCabin para comprobar su calidad y precisión?
Sí. Cada herramienta del sitio pasa pruebas automáticas en navegadores reales para comprobar que el resultado es correcto y que no hay errores. Si encuentras un fallo o tienes una sugerencia, escríbenos a [email protected] y lo revisaremos.