Kubernetes: validar Deployment, Service e Ingress YAML en línea

Deployment, Service e Ingress: valida la estructura YAML antes de `kubectl apply` — comprobación local en el navegador, sin cluster ni kubectl.

07.09.2026

9 min de lectura

Compartir este artículo:

kubernetes

k8s

YAML

DevOps

Validación

Tutorial

¿Por qué validar YAML Kubernetes antes de `kubectl apply`?

Un typo en apiVersion, un Deployment sin spec.selector.matchLabels o un Ingress sin pathType suele aparecer demasiado tarde — cuando CI, un compañero o el API server rechaza el manifiesto. FastMinify no ejecuta kubectl, no habla con un cluster y no es kubeconform. El validador YAML Kubernetes aplica comprobaciones estructurales en el navegador: capa A (apiVersion, kind, metadata) más reglas por kind para Deployment, Service, Ingress y más. Combínalo con el formateador de manifiestos Kubernetes para YAML multi-documento legible. El cluster completo está en el hub de herramientas Kubernetes, hermano del hub DevOps (Compose, Terraform, Dockerfile).

Detectar incoherencias apiVersion/kind y metadata faltante antes del push

Comprobaciones por kind: selectores Deployment, puertos Service, pathType Ingress

YAML multi-documento (`---`) validado documento a documento

100 % en el navegador — los manifiestos no se suben a un servidor

Límite 512 KiB UTF-8, igual que otras herramientas Kubernetes del sitio

Errores habituales y workflow pre-apply

Lo que la validación atrapa a menudo

Algunos errores aparecen constantemente en manifiestos pegados, salida Helm y snippets de tutoriales.

Incoherencia apiVersion/kind (Deployment con `v1` en lugar de `apps/v1`)

Labels del selector Deployment que no coinciden con labels del pod template

Container sin `image` tras un mal merge conflict

Service con array `ports` vacío

Path Ingress sin `pathType` tras migración networking v1

Config vecina en el mismo proyecto

Un rollout Kubernetes rara vez viaja solo. Valida manifiestos, luego lintea el build de imagen y la IaC que provisiona el cluster.

Validar Compose y `.env` — ver validación Docker Compose y .env

Formatear HCL Terraform en la misma stack — Terraform y HCL en línea

Explorar el hub Kubernetes para generadores y values Helm

Nunca pegar secretos reales (tokens, kubeconfig, datos Secret) en un textarea público

Tratar YAML validado como fuente Git: revisado, versionado, aplicado vía CI

Validar vs formatear vs kubeconform vs kubectl

Elegir la capa correcta

Validación en navegador, formateo, herramientas OpenAPI y dry-runs de cluster responden a preguntas distintas. Mezclarlas produce un check verde aquí y un job CI rojo después.

Herramienta / capa

format:FastMinify format-kubernetes

validate:FastMinify validate-kubernetes

minify:kubeconform / kubectl apply --dry-run

Qué demuestra

format:YAML legible — no corrección semántica

validate:GVK estructural + reglas por kind — no OpenAPI completo

minify:Esquema o aceptación apiserver — requiere CLI/cluster

Orden recomendado

Una secuencia simple atrapa la mayoría de typos antes de que algo toque un cluster.

Formatear el manifiesto para indentación coherente

Validar estructura en el navegador (FastMinify)

Ejecutar kubeconform o `kubectl apply --dry-run=client` en CI cuando importan los esquemas

Aplicar en un namespace dev y smoke-test

Mantener values Helm separados — formatear con formatear Helm values, no el formateador de manifiestos

Cuando basta la herramienta del navegador

Escenarios habituales

No necesitas cluster ni kubeconfig para pillar tres errores estructurales en un manifiesto de un ticket.

Revisar un trío Deployment + Service + Ingress pegado desde Slack

Sanity-check de salida template Helm antes de abrir un PR

Enseñar forma YAML Kubernetes sin provisionar un cluster

Desbloquear a un compañero que no puede ejecutar kubectl localmente

Filtro rápido en un manifiesto vendor o tutorial antes de adaptarlo

Límites: lo que el navegador no sustituye

kubeconform y `kubectl apply --dry-run`

En cuanto necesites validación de esquema OpenAPI contra una versión Kubernetes concreta, esquemas CRD o políticas admission webhook, las herramientas CLI y el apiserver siguen siendo obligatorios.

kubeconform con versión de esquema JSON Kubernetes fijada

`kubectl apply --dry-run=server` contra un apiserver real

Manifiestos CRD — FastMinify reporta info para kinds desconocidos, no esquema CRD completo

Motores de política (OPA, Kyverno) — fuera del alcance de validación estructural

Conectividad de red, image pull secrets, cuotas — solo en runtime

Lo que FastMinify no simula

El validador lee solo el YAML pegado. No resuelve charts Helm, no expande overlays Kustomize y no valida que un nombre de Service referenciado por un Ingress exista en otro documento.

Sin comprobaciones de referencias cruzadas entre bloques `---`

Sin `helm template` ni `kustomize build` — pega la salida renderizada

Sin defaulting de namespace ni lógica server-side apply

ConfigMap/Secret con data vacía → solo advertencia (placeholder OK)

Más de 512 KiB UTF-8 → entrada rechazada — divide o usa herramientas CLI locales

CLI y ecosistema

Herramientas locales de referencia

kubeconform, kubectl y yamllint siguen siendo el estándar en CI. FastMinify complementa exploración y one-shots.

kubeconform

Valida manifiestos contra esquemas OpenAPI Kubernetes (versión fijada).

Ventajas:

Errores a nivel esquema con control de versión Kubernetes

Encaja en CI y pre-commit hooks

Soporta CRDs cuando se proporcionan esquemas

Inconvenientes:

Requiere instalación y descarga de esquemas

Menos práctico para un snippet pegado único

kubectl apply --dry-run=client

Dry-run cliente con validación de esquema local (depende de la versión kubectl).

Ventajas:

Ya presente en la mayoría de máquinas de desarrollo

Salida familiar para equipos de plataforma

Se combina con dry-run real de cluster cuando está configurado

Inconvenientes:

Necesita kubectl y a menudo un contexto kubeconfig válido

Comportamiento client vs server dry-run distinto

yamllint

Linter YAML genérico para indentación y estilo.

Ventajas:

Reglas de indentación configurables

Útil más allá de Kubernetes (CI, Ansible…)

Integración en editor

Inconvenientes:

No conoce semántica apiVersion/kind

No detecta mismatches selector/template

Manifiestos habituales: Deployment, Service e Ingress

Forma mínima de un documento Kubernetes

Cada manifiesto es un mapping YAML con apiVersion, kind y metadata (name o generateName). FastMinify comprueba el emparejamiento: por ejemplo Deployment espera apps/v1, Service espera v1, Ingress espera networking.k8s.io/v1. Grupos de API obsoletos como extensions/v1beta1 generan una advertencia — no un bloqueo duro.

Archivos multi-documento: separar recursos con `---` — cada doc se valida de forma independiente

Kinds desconocidos (CRD) → nivel info — reglas estructurales omitidas, metadata aún comprobada

apiVersion obsoleta → advertencia con pista para migrar el GVK

Entrada vacía permanece idle — no se reporta como «válida»

Errores de parse YAML con pista de línea cuando js-yaml la proporciona

Deployment: selector, template y containers

Un Deployment necesita spec.selector.matchLabels (no vacío), spec.template.spec.containers (array no vacío), y cada container debe tener name e image. FastMinify también comprueba que los valores de spec.selector.matchLabels coincidan con spec.template.metadata.labels — un error clásico de copiar-pegar que pasa el lint YAML pero falla en runtime.

Antes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api-wrong
    spec:
      containers:
        - name: api
          image: myapp:1.0

Después

Corrige spec.template.metadata.labels.app para que coincida con spec.selector.matchLabels.app (ambos "api").

Selector faltante o matchLabels vacío → error

Container sin name o image → error con path

selector_mismatch cuando los labels del template no coinciden con el selector

replicas debe ser un número cuando está presente

Genera un starter con generar Deployment, luego valida

Puertos Service y pathType Ingress

Un Service debe declarar un array spec.ports no vacío; cada puerto necesita port (número o cadena IntOrString). Un Ingress (networking.k8s.io/v1) necesita spec.rules con http.paths; cada path requiere path, pathType (Prefix, Exact o ImplementationSpecific) y backend.service.name más backend.service.port.number o port.name.

Service sin ports → error

Path Ingress sin pathType → error (frecuente tras migración v1)

Backend Ingress sin nombre de service o puerto → error

Combina Ingress con generar Ingress para un scaffold v1

Los values Helm tienen otra forma — usa formatear Helm values, no el validador de manifiestos

Formatear, validar, generar: un workflow concreto

Usar el validador YAML Kubernetes

Abre la herramienta validar Kubernetes, pega o sube un archivo .yaml / .yml (máx. 512 KiB) y espera el debounce (~300 ms). El panel de resultados lista issues por nivel (error, advertencia, info) con path, docIndex opcional para archivos multi-doc y una línea cuando esté disponible. Válido con advertencias sigue mostrando issues — léelas antes de hacer merge.

Capa A: apiVersion, kind, metadata.name o generateName

Capa B: reglas estructurales por kind para kinds integrados

YAML multi-documento soportado — docIndex identifica qué bloque `---` falló

No es kubeconform, no OpenAPI apiserver, no políticas de admission

Todo permanece local — sin cuenta, sin credenciales de cluster

Formatear manifiestos antes del review

La herramienta formatear Kubernetes hace pretty-print de manifiestos multi-documento vía js-yaml (indentación 2 o 4 espacios). Pegar, subir o ejemplo: auto-formato; tras edición manual, botón Formatear (⌘↵). Los comentarios YAML # se pierden en el round-trip — cópialos primero si dependes de ellos.

Multi-doc `---` preservado — distinto de beautifiers genéricos mono-doc

Comentarios no preservados — advertencia soft si la entrada probablemente tenía comentarios

Encadena format → validate para diffs legibles y comprobaciones estructurales

YAML genérico fuera de K8s: embellecer YAML

Los archivos Compose no son manifiestos K8s — usa validar Docker Compose

Escenario — Ingress sin pathType tras upgrade de API

Migras de networking.k8s.io/v1beta1 a v1. El YAML sigue parseando, pero cada path necesita un pathType explícito. El validador marca invalid_path_type antes de desperdiciar un paso de pipeline en kubectl apply.

apiVersion obsoleta → advertencia — planifica la migración GVK

pathType faltante o inválido → error con path

Regenera un esqueleto v1 con generar Ingress si el archivo es sobre todo boilerplate

Formatea primero para que los números de línea coincidan con tu editor

Para YAML CI en el mismo repo, ver lint workflow GitHub Actions

Conclusión

Validar la estructura de manifiestos Kubernetes antes de kubectl apply evita desperdiciar minutos de CI en typos que podrías pillar en el navegador. Usa FastMinify como filtro estructural rápido — formatear para legibilidad, validar para GVK y reglas por kind — luego kubeconform o dry-run de cluster cuando importa la verdad del esquema. Continúa en el hub Kubernetes para generadores, values Helm y el cluster DevOps para Compose y Terraform.

Valida tu YAML Kubernetes ahora

Formatear YAML multi-doc antes del review — los comentarios se pierden al formatear

Corregir pronto pares apiVersion/kind y labels selector/template

Tratar advertencias (API obsoleta, ConfigMap vacía) como bloqueadores de merge cuando importan

Ejecutar kubeconform o kubectl dry-run en CI para verdad a nivel esquema

Nunca pegar kubeconfig o payloads Secret en una herramienta en línea

Compartir este artículo

Compartir este artículo:

Kubernetes: validar Deployment, Service e Ingress YAML en línea

¿Por qué validar YAML Kubernetes antes de `kubectl apply`?

Errores habituales y workflow pre-apply

Validar vs formatear vs kubeconform vs kubectl

Herramienta / capa

Qué demuestra

Cuando basta la herramienta del navegador

Límites: lo que el navegador no sustituye

CLI y ecosistema

kubeconform

Ventajas:

Inconvenientes:

kubectl apply --dry-run=client

Ventajas:

Inconvenientes:

yamllint

Ventajas:

Inconvenientes:

Manifiestos habituales: Deployment, Service e Ingress

Antes

Después

Formatear, validar, generar: un workflow concreto

Conclusión

Artículos relacionados