Ir al contenido principal

Kustomize en Kubernetes: Gestión Flexible de Configuraciones.

Kustomize es una herramienta que permite gestionar configuraciones de Kubernetes sin modificar los archivos base directamente, usando un enfoque basado en capas y sobrecargas. Esto es especialmente útil en situaciones donde quieres mantener una base de configuración común y, al mismo tiempo, personalizar ciertos aspectos según las necesidades de distintos entornos o clientes. En este artículo, vamos a ampliar el concepto de Kustomize y explicar cómo funciona a través de un ejemplo práctico.

¿Qué es Kustomize y por qué es importante?

Kustomize es una herramienta declarativa de Kubernetes que permite realizar personalizaciones de configuraciones sin necesidad de modificar los manifiestos YAML originales (los archivos base). Este enfoque es especialmente valioso en entornos donde las mismas aplicaciones deben desplegarse en diferentes configuraciones, como desarrollo, pruebas y producción.

Kustomize introduce el concepto de overlays (sobrecargas), que son personalizaciones o variaciones de los recursos base (denominados base). Estas personalizaciones se aplican sin alterar los archivos base, lo que facilita la reutilización y mantiene la coherencia de las configuraciones.

Ventajas de Kustomize

  1. Separación de Configuraciones Base y Personalizadas: Los archivos base se mantienen intactos y se reutilizan. Las personalizaciones se aplican mediante overlays, lo que permite gestionar configuraciones específicas para cada entorno o cliente sin duplicar archivos ni modificar los originales.

  2. Modularidad: Kustomize permite construir configuraciones de manera modular, lo que facilita la actualización de las configuraciones base y garantiza que las personalizaciones se apliquen solo donde sean necesarias.

  3. Flexibilidad: Puedes personalizar prácticamente cualquier campo de un recurso de Kubernetes, incluyendo réplicas, variables de entorno, políticas de escalado automático (HPA), entre otros, sin tener que tocar los archivos originales.

Ejemplo práctico: Estructura de Directorios con Kustomize

Para ilustrar cómo funciona Kustomize, vamos a utilizar un ejemplo en el que tenemos una configuración base para una aplicación de Kubernetes y queremos personalizar el comportamiento del escalado automático (HPA) para un cliente específico sin modificar los archivos base.

Paso 1: Estructura de Directorios de Kustomize

La estructura básica que utilizaremos será la siguiente:

kustomize/ ├── base/ │ ├── deployment.yaml │ ├── service.yaml │ └── hpa.yaml └── overlays/ ├── development/ │ └── kustomization.yaml ├── staging/ │ └── kustomization.yaml └── production/ └── kustomization.yaml
  • base/: Aquí se almacenan los archivos YAML de Kubernetes que definen la configuración general de la aplicación, como el Deployment, el Service y el HPA (Horizontal Pod Autoscaler).
  • overlays/: Aquí creamos diferentes directorios para cada entorno (development, staging, production), donde aplicamos las personalizaciones específicas que sobrecargan los recursos base.

Paso 2: Archivos Base

Veamos cómo se vería un ejemplo de los archivos base:

deployment.yaml (Base de despliegue de la aplicación):

apiVersion: apps/v1 kind: Deployment metadata: name: my-app spec: replicas: 3 selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - name: my-app image: my-app-image:1.0 ports: - containerPort: 80

service.yaml (Base del servicio):

apiVersion: v1 kind: Service metadata: name: my-app-service spec: selector: app: my-app ports: - protocol: TCP port: 80 targetPort: 80 type: LoadBalancer

hpa.yaml (Base de escalado automático HPA):

apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: my-app-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-app minReplicas: 1 maxReplicas: 5 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 50

Paso 3: Personalizaciones para el Entorno de Producción

Queremos personalizar los recursos para el entorno de producción, en particular aumentar el número de réplicas del Deployment y ajustar el HPA para que soporte más carga.

  1. Crea el archivo kustomization.yaml en el directorio overlays/production/:

    resources: - ../../base patchesStrategicMerge: - production-replicas-patch.yaml - production-hpa-patch.yaml

    En este archivo indicamos que vamos a usar los recursos base y aplicaremos dos parches: uno para cambiar el número de réplicas y otro para modificar la configuración del HPA.

  2. Crea el parche production-replicas-patch.yaml para modificar las réplicas del Deployment:

    apiVersion: apps/v1 kind: Deployment metadata: name: my-app spec: replicas: 10 # Aumentamos el número de réplicas en producción
  3. Crea el parche production-hpa-patch.yaml para ajustar el HPA:


    apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: my-app-hpa spec: minReplicas: 3 maxReplicas: 10 # Aumentamos el máximo de réplicas en producción metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60 # Ajustamos el umbral de utilización de CPU

Paso 4: Aplicar los Overlays con Kustomize

Una vez configurados los archivos, podemos aplicar las personalizaciones de producción con el siguiente comando:

kubectl apply -k overlays/production/

Este comando aplicará todos los recursos base y las modificaciones específicas para el entorno de producción, como el aumento en el número de réplicas y la configuración ajustada del HPA.

Beneficios de Usar Kustomize en este Escenario

  • Consistencia: Los archivos base se reutilizan para todos los entornos, lo que garantiza que la aplicación se mantenga consistente en diferentes despliegues.
  • Personalización Controlada: Las configuraciones específicas (como el número de réplicas y los ajustes del HPA) se aplican sin alterar los archivos base, lo que facilita el mantenimiento y la actualización.
  • Flexibilidad para Múltiples Entornos: Puedes crear diferentes overlays para otros entornos, como development o staging, con configuraciones más ligeras o ajustes específicos.

Instalación:

Kustomize  está integrado en kubectl a partir de la versión 1.14, lo que significa que no necesitas instalarlo por separado si ya tienes kubectl instalado en tu sistema. Puedes usarlo directamente con el comando kubectl apply -k, que es nativo para aplicar configuraciones gestionadas por Kustomize.

Si prefieres usar Kustomize de forma independiente, puedes instalarlo con el script de GitHub y utilizar kustomize build para generar y aplicar los manifiestos.

Comentarios

Entradas populares de este blog

Ubicación, Estructura y Manejo básico de certificados.

                                                     Kubernetes utiliza certificados TLS (X.509) para cifrar la comunicación entre sus componentes y autenticar identidades (usuarios, nodos, API Server, etc.). Estos certificados son generados y gestionados automáticamente cuando se instala un clúster con kubeadm . En este artículo, veremos dónde se almacenan los certificados , cuál es su estructura y cómo inspeccionarlos fácilmente, una habilidad muy útil para el examen CKA. Cuando creas un clúster con kubeadm , los certificados se generan por defecto en el directorio: /etc/ kubernetes /pki/ Puedes ver su contenido con: ls -l /etc/kubernetes/pki/ También hay certificados en: /etc/kubernetes/ (ahí verás admin.conf , kubelet.conf , etc., que incluyen certificados embebidos, como veremos más abajo). 🧱 Estructura de los ce...

🔁 Renovación y Rotación de Certificados en Kubernetes (kubeadm certs)

  🎯 Introducción En un clúster de Kubernetes, la mayoría de los certificados generados por kubeadm tienen una validez de un año . Para evitar interrupciones en los componentes críticos, es fundamental revisar periódicamente su vigencia y saber cómo renovarlos correctamente. En este artículo aprenderás: Cómo comprobar la expiración de los certificados Cómo renovarlos automáticamente con kubeadm Cómo simular una renovación manual con openssl Cómo aplicar los cambios reiniciando los componentes afectados 🕵️‍♂️ Comprobación del estado de los certificados Kubernetes ofrece una herramienta integrada para revisar los certificados del clúster: kubeadm certs check-expiration Este comando muestra información clave: Fecha de expiración Tipo de certificado Ruta en el sistema 📌 Salida de ejemplo: CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY apiserver Jan 06 , 2026 19 :56 UTC 330d ...

TLS Bootstrapping en Kubernetes: Qué es, cómo funciona y por qué importa en el examen CKA

                                                       Uno de los conceptos que a menudo pasan desapercibidos en la administración de Kubernetes —pero que resultan clave tanto en entornos reales como en el examen CKA— es el TLS Bootstrapping . En este artículo entenderás qué es, cómo funciona, qué lo diferencia del kubeadm join tradicional y cómo puede aparecer en el examen. ¿Qué es TLS Bootstrapping? TLS Bootstrapping es el proceso por el cual el kubelet , el agente que corre en cada nodo, obtiene automáticamente un certificado TLS firmado por el clúster para autenticarse con el kube-apiserver . En otras palabras: permite que un nuevo nodo se una de forma segura al clúster sin necesidad de copiar manualmente los certificados. ¿Por qué es necesario? Cuando añades un nuevo nodo worker, su kubelet necesita autentic...