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

Cada equipo que ejecuta aplicaciones en Kubernetes se encuentra eventualmente con el mismo monstruo: tres copias casi idénticas de los mismos archivos de manifiesto, una para desarrollo, una 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 a producción. Nadie puede decir qué archivo es la verdad. Este curso enseña la herramienta que la comunidad de Kubernetes construyó para eliminar ese monstruo para siempre: Kustomize, la herramienta de personalización oficial y sin plantillas que ahora se distribuye 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 plantillas. En lugar de rellenar marcadores de posición dentro de tus archivos YAML, mantiene tus manifiestos como YAML simples y válidos en todo momento y describe cada diferencia específica del entorno en un pequeño archivo de instrucciones llamado kustomization. Piénsalo como un editor cuidadoso que revisa un documento: añade una etiqueta aquí, cambia un número allá y te entrega el resultado terminado, mientras que el original permanece intacto en el disco.

Unas pocas palabras de vocabulario te guiarán a través de 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 personalizado final que despliegas se llama variante. Construye un overlay para desarrollo y otro para producción, y obtendrás dos variantes de la misma aplicación, que difieren solo en formas controladas y revisables.

Todo está dirigido por un 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 vista previa. Solo cuando aplicas deliberadamente la salida, normalmente con kubectl apply -k, algo llega al clúster. Esa disciplina de construir y luego aplicar es la columna vertebral de GitOps, la filosofía de trabajo donde un repositorio de Git es la única fuente de verdad para lo que se ejecuta en tu clúster, y cada cambio es un commit revisado y auditable.

Fundamentos de Kustomize, instalación y primera 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 pasas a la práctica inmediatamente. Instalas la CLI oficial de Kustomize anclada a una versión específica, compruebas la conexión de tu clúster y creas tu 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 línea, kustomize edit set namespace, y la salida de la build coloca repentinamente cada recurso en el namespace que elegiste, sin cambiar ni un solo byte en los archivos originales. Despliegas ese resultado en un clúster de Kubernetes en vivo con kubectl apply -k, verificas que los pods estén en ejecución y limpias después de ti con el comando de eliminación correspondiente. Desde la primera sesión, estás ejecutando el ciclo profesional: editar, construir, leer, aplicar.

El archivo kustomization: Generadores y transformadores comunes

El módulo dos abre el archivo kustomization en sí. 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 la build. Comprender ese orden es lo que hace que las builds de Kustomize sean predecibles y depurables.

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

La segunda mitad del módulo cubre los transformadores comunes, los campos de una sola línea que los equipos usan a diario: namePrefix y nameSuffix para renombrar de forma segura, namespace para ubicar una build completa, labels y commonAnnotations para metadatos de propiedad, images para fijar versiones y replicas para escalar. Cada uno es un comando de edición único, cada uno es visible en la salida de la 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 parecen YAML parcial: nombran el recurso de destino y cambian solo los campos que mencionas, dejando todo lo demás intacto. Los JSON patches provienen de un estándar de internet, RFC 6902, y expresan cambios como operaciones compactas con rutas precisas dentro del documento, lo que los hace perfectos para ediciones quirúrgicas de listas, como eliminar una variable de entorno sin reescribir la lista.

Ambas técnicas viven en el mismo campo de patches modernos, cada una emparejada con 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 de la build, de modo que renombrar el Service actualiza el Deployment en la 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. Construyes el árbol estándar de la industria, una base neutral más overlays de dev, staging y producción, produces cada variante de forma independiente y comparas dos variantes para mostrar exactamente dónde divergen: tres cambios controlados, línea por línea, la evidencia que un gestor de lanzamientos quiere ver. También conoces los componentes, los paquetes opcionales que los entornos individuales pueden activar o desactivar, como flags de características expresadas en la estructura de carpetas.

Luego viene el puente hacia Helm, el gestor de paquetes del mundo de 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 ejecutan los equipos reales: inflar un chart con el soporte de Helm integrado en Kustomize, sobrescribir sus valores en línea y aplicar tus propias convenciones, tu namespace, tus etiquetas, tus patches, sobre los recursos planos que salen, todo 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 vista previa, apply como entrega, revert como rollback.

Lo que podrás hacer

Después de cuatro módulos y ocho prácticas prácticas contra un clúster en vivo, podrás instalar y operar la CLI de Kustomize, generar ConfigMaps y Secrets de forma segura con rollouts automáticos, remodelar recursos con los seis transformadores comunes, aplicar patches a cualquier cosa con cualquiera de las notaciones oficiales, conectar valores entre recursos para que nunca se desvíen, gestionar árboles de variantes de dev/staging/prod y adoptar charts de Helm mientras los post-renderizas a los estándares de tu equipo.

Primeros pasos

Cada módulo combina un bloque de teoría 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 tu estación de trabajo con el Course Baseline instalado, y cada sesión posterior comienza desde allí. Si estás listo para dejar de copiar y pegar YAML y empezar a personalizar la configuración de la manera declarativa, comienza con el Módulo 1 y construye tu primera kustomization hoy.