Kustomize

Kustomize te permite mantener un conjunto de YAMLs "base" y aplicar modificaciones (parches) específicas por entorno (dev, prod) sin duplicar código.

• Bases y Overlays:

• Base: El directorio con los YAMLs genéricos de tu aplicación (Deployment, Service) y un archivo kustomization.yaml que los agrupa.

• Overlay: Un directorio separado (ej. prod/ o dev/) que hereda la Base y le aplica cambios específicos.

• Strategic Merge Patches: Son archivos YAML incompletos que Kustomize fusiona inteligentemente con los recursos de la Base. Kustomize sabe, por ejemplo, que si envías un parche de un Deployment con una nueva variable de entorno, debe agregarla a la lista de contenedores existente basándose en el nombre del contenedor.

• Components:

  Imagina que tienes tres entornos: dev, staging y prod. Tienes una base/ común.

  Ahora, el equipo de seguridad te pide que inyectes un sidecar de monitoreo (Datadog) en dev y en prod, pero NO en staging (para ahorrar costos).

  Si solo usas overlays tradicionales, tienes dos malas opciones:

  1. Duplicar código: Copiar y pegar el mismo patch.yaml del sidecar en la carpeta dev/ y en la carpeta prod/. (Rompe la regla de oro: Don't Repeat Yourself).

  2. Jerarquías complejas: Crear una "sub-base" llamada base-con-monitoreo/ que herede de base/, y hacer que dev y prod hereden de ahí. A medida que sumas más características (ej. "usar base de datos externa", "inyectar caché Redis"), este árbol de herencias se vuelve una pesadilla inmanejable.

  Los Components te permiten definir características "a la carta" (como si fueran plugins o mixins). Creas el parche del sidecar una sola vez como un Componente, y luego simplemente le dices a los overlays de dev y prod que "activen" ese componente.

  Un Componente encapsula un comportamiento específico y reutilizable que no pertenece estrictamente a la ruta vertical de herencia.

[!IMPORTANT] Para ver cómo queda tu YAML final fusionado sin aplicarlo en el clúster, NUNCA apliques a ciegas.
Usa siempre kubectl kustomize <directorio> (el equivalente a un dry-run de Kustomize).

Usar kubectl apply -k para aplicar los cambios.

Laboratorio Práctico

Vamos a armar un escenario real de despliegue multi-entorno.

1. Problema

Tienes una aplicación web básica definida en un directorio base/. El equipo de operaciones te pide crear el entorno de Producción (prod/). En producción, la aplicación no puede correr con la configuración por defecto de la base; necesita alta disponibilidad y una variable de entorno específica.

Aquí tienes la estructura de tu Base:

# base/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:1.21

# base/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml

2. Objetivo

Crear el overlay de producción en un nuevo directorio llamado prod/. Este overlay debe aplicar un Strategic Merge Patch sobre el Deployment original para lograr lo siguiente:

• Aumentar las réplicas a 3.
• Añadir la variable de entorno ENV: PROD al contenedor nginx.

3. Restricciones

• No puedes modificar los archivos dentro del directorio base/.
• Debes usar la estructura estándar de Kustomize (un kustomization.yaml y un archivo patch.yaml en el directorio prod/).

4. Tu turno

Para resolver este laboratorio, necesito que me des tu solución para los dos archivos que irán dentro del directorio prod/:

1. ¿Cómo escribirías el archivo prod/patch.yaml (recuerda que es un YAML incompleto, solo con lo necesario para el merge)?

Solución

[embedmd]:# (../k8s-lab/kustomize/overlays/prod/kustomization.yaml)

# overlays/prod/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base/
patches:
  - path: patch.yaml

[embedmd]:# (../k8s-lab/kustomize/overlays/prod/patch.yaml)

# overlays/prod/patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: nginx
        env:
          - name: ENV
            value: "PROD"

1. ¿Qué comando exacto de kubectl ejecutarías para desplegar este overlay en el clúster?

Solución

kubectl apply -k .