Dejad de copiar y pegar YAML de Kubernetes: Un curso práctico de Kustomize

Cada equipo que ejecuta aplicaciones en Kubernetes acaba encontrándose con el mismo monstruo: tres copias casi idénticas de los mismos archivos de manifiesto, una para desarrollo, otra para staging y otra para producción, todas alejándose silenciosamente entre sí. Un puerto cambia en una copia pero no en las demás. Una corrección de memoria llega a staging y nunca alcanza producción. Nadie puede decir qué archivo es la verdad. Este curso os enseña la herramienta que la comunidad de Kubernetes ha construido para matar a ese monstruo para siempre: Kustomize, la herramienta de personalización oficial y sin plantillas que ahora se incluye dentro del propio kubectl.

¿Qué es Kustomize, en términos sencillos?

Kustomize es una herramienta de línea de comandos que personaliza la configuración de Kubernetes sin utilizar plantillas. En lugar de rellenar marcadores de posición dentro de vuestros archivos YAML, mantiene vuestros manifiestos como YAML puro y válido en todo momento y describe cada diferencia específica del entorno en un pequeño archivo de instrucciones llamado kustomization. Pensadlo como un editor cuidadoso que revisa un documento: añade una etiqueta aquí, cambia un número allá y os devuelve el resultado final, mientras que el original permanece intacto en el disco.

Unas pocas palabras de vocabulario os guiarán por toda la herramienta. Una kustomization es esa hoja de instrucciones, siempre llamada kustomization.yaml, y la carpeta que la contiene se llama su root. Una base es cualquier kustomization a la que otra apunta; un overlay es una kustomization que añade cambios sobre una base sin modificar nunca sus archivos; y el resultado final personalizado que desplegáis se llama variante. Construid un overlay para desarrollo y otro para producción, y obtendréis dos variantes de la misma aplicación, que solo difieren en formas controladas y revisables.

Todo se basa en un solo comando, kustomize build, que lee una carpeta de destino e imprime el YAML final como texto plano. No cambia nada: es una máquina de previsualización. Solo cuando aplicáis deliberadamente el resultado, normalmente con kubectl apply -k, algo llega al clúster. Esa disciplina de “build-then-apply” es la columna vertebral de GitOps, la filosofía de trabajo donde un repositorio de Git es la única fuente de verdad de lo que se ejecuta en vuestro clúster, y cada cambio es un commit revisado y auditable.

Fundamentos de Kustomize, instalación y primer build

El curso comienza con los fundamentos: qué es Kustomize, por qué la comunidad eligió la personalización sin plantillas sobre el uso de plantillas, y el vocabulario anterior. Luego, pasáis directamente a la práctica. Instaláis la CLI oficial de Kustomize fijada a una versión específica, comprobáis la conexión con vuestro clúster y creáis vuestra primera kustomization a partir de dos manifiestos ordinarios, un Deployment y un Service.

La primera práctica ofrece un momento que todo principiante recuerda: una sola línea, kustomize edit set namespace, y el resultado del build sitúa de repente cada recurso en el namespace que habéis elegido, sin cambiar ni un solo byte en los archivos originales. Desplegáis ese resultado en un clúster de Kubernetes real con kubectl apply -k, verificáis que los pods estén en ejecución y limpiáis vuestro entorno con el comando delete correspondiente. Desde la primera sesión, estaréis ejecutando el ciclo profesional: edit, build, read, apply.

El archivo kustomization: Generators y Transformers comunes

El módulo dos abre el propio archivo kustomization. La documentación oficial lo describe como cuatro listas procesadas en orden estricto: resources, lo que se carga; generators, lo que se crea; transformers, lo que se modifica; y validators, lo que puede fallar en el build. Comprender ese orden es lo que hace que los builds de Kustomize sean predecibles y fáciles de depurar.

Los generators son el primer superpoder. En lugar de escribir a mano objetos de configuración, declaráis un configMapGenerator o un secretGenerator alimentado por valores simples o por archivos, y Kustomize produce automáticamente los recursos ConfigMap y Secret correctos. Los nombres generados incluyen un sufijo de hash de contenido, y ese hash es una función de seguridad: si cambiáis la configuración, el nombre cambia y cada pod que hace referencia a él se reinicia limpiamente con los nuevos valores. Sin configuraciones obsoletas, sin reinicios manuales, sin pods inconsistentes.

La segunda mitad del módulo cubre los transformers comunes, los campos de una sola línea que los equipos usan a diario: namePrefix y nameSuffix para renombrar de forma segura, namespace para situar un build completo, labels y commonAnnotations para metadatos de propiedad, images para fijar versiones y replicas para el escalado. Cada uno es un solo comando de edición, cada uno es visible en el resultado del build antes de que algo toque el clúster, y juntos remodelan una aplicación completa sin tocar un manifiesto.

Patching de recursos: Strategic merge, JSON 6902 y Replacements

Algunos cambios son demasiado específicos para los campos de una sola línea: el límite de memoria de un contenedor, una sola variable de entorno, una operación profunda dentro de una lista. El módulo tres enseña las dos técnicas oficiales de patch. Los strategic merge patches se parecen a un YAML parcial: nombran el recurso de destino y cambian solo los campos que mencionáis, dejando todo lo demás intacto. Los JSON patches provienen de un estándar de internet, RFC 6902, y expresan los cambios como operaciones compactas con rutas precisas dentro del documento, lo que los hace perfectos para ediciones quirúrgicas en listas, como eliminar una variable de entorno sin reescribir la lista.

Ambas técnicas conviven en el mismo campo de patches modernos, cada una asociada a un selector de destino que puede coincidir con recursos por tipo, por nombre o por etiquetas, de modo que un pequeño patch puede alcanzar varios recursos a la vez. El módulo cierra con replacements, que conectan valores entre recursos automáticamente: un Deployment aprende el nombre del Service que tiene delante en el momento del build, de modo que renombrar el Service actualiza el Deployment en el siguiente build, sin copias obsoletas en ningún lugar.

Overlays, Variantes e integración con Helm

El módulo final ensambla el flujo de trabajo completo. Construís el árbol estándar de la industria: una base neutral más overlays de dev, staging y producción; producís cada variante de forma independiente y comparáis dos variantes para mostrar exactamente dónde divergen: tres cambios controlados, línea por línea, la evidencia que un responsable de lanzamientos quiere ver. También conoceréis los componentes, los paquetes opcionales que los entornos individuales pueden activar o desactivar, como flags de funciones expresadas en la estructura de carpetas.

Luego viene el puente hacia Helm, el gestor de paquetes del mundo Kubernetes. Los charts de la comunidad son plantillas, que es precisamente lo que Kustomize evita, por lo que el curso enseña la combinación pragmática que utilizan los equipos reales: inflar un chart con el soporte de Helm integrado en Kustomize, sobrescribir sus valores de forma inline y aplicar vuestras propias convenciones, vuestro namespace, vuestras etiquetas, vuestros patches, sobre los recursos planos que salen, todo ello sin hacer un fork del chart. El curso cierra ejecutando el ciclo completo de GitOps de principio a fin: archivos en un repositorio, build y diff como previsualización, apply como entrega, revert como rollback.

Lo que seréis capaces de hacer

Después de cuatro módulos y ocho prácticas prácticas contra un clúster real, podréis instalar y operar la CLI de Kustomize, generar ConfigMaps y Secrets de forma segura con rollouts automáticos, remodelar recursos con los seis transformers comunes, aplicar patches con cualquiera de las notaciones oficiales, conectar valores entre recursos para que nunca diverjan, gestionar árboles de variantes de dev/staging/prod y adoptar charts de Helm aplicándoles vuestros estándares de equipo mediante post-rendering.

Primeros pasos

Cada módulo combina un bloque teórico con una práctica grabada paso a paso ejecutada contra un clúster de Kubernetes real, seguida de una comprobación de conocimientos de diez preguntas. Las prácticas se construyen unas sobre otras: la primera deja vuestra estación de trabajo con el Course Baseline instalado, y cada sesión posterior comienza desde ahí. Si estáis listos para dejar de copiar y pegar YAML y empezar a personalizar la configuración de forma declarativa, empezad con el Módulo 1 y construid vuestra primera kustomization hoy mismo.