Ir al contenido principal

Uso Conjunto de Kustomize y Helm en Kubernetes

  

En Kubernetes, tanto Helm como Kustomize son herramientas poderosas que facilitan la gestión de despliegues y configuraciones. Aunque ambas herramientas se suelen utilizar de forma independiente, también es posible aprovechar las capacidades de personalización de Kustomize junto con la funcionalidad de empaquetado y despliegue de Helm. En este artículo, vamos a explorar cómo utilizar estas dos herramientas juntas para gestionar configuraciones complejas de Kubernetes de manera efectiva.

¿Por qué usar Kustomize y Helm juntos?

Helm es excelente para la gestión de charts y el despliegue de aplicaciones empaquetadas. Sin embargo, cuando necesitamos personalizar estos charts para diferentes entornos o aplicar configuraciones específicas a nuestros manifiestos sin modificar los charts originales, Kustomize es la herramienta ideal. Kustomize nos permite superponer configuraciones adicionales o modificar los manifiestos generados por Helm, lo que proporciona un enfoque más declarativo para las personalizaciones.

En resumen, puedes usar Helm para instalar una aplicación y luego Kustomize para modificar los recursos generados, como personalizar configuraciones para distintos entornos (desarrollo, staging, producción) sin tocar el chart de Helm directamente.

Paso a paso: Uso conjunto de Kustomize y Helm

Vamos a seguir un ejemplo práctico en el que:

  • Usaremos Helm para desplegar una aplicación básica (por ejemplo, NGINX).
  • Luego, aplicaremos Kustomize para modificar la configuración de los recursos generados por Helm, como ajustar los recursos solicitados o personalizar las etiquetas.

Paso 1: Desplegar la aplicación con Helm

Primero, vamos a instalar una aplicación sencilla como NGINX utilizando Helm. Usaremos el chart de NGINX del repositorio de Helm.

  1. Añadir el repositorio de Helm si no lo tienes ya añadido:

    helm repo add bitnami https://charts.bitnami.com/bitnami helm repo update
  2. Instalar el chart de NGINX:

    helm install my-nginx bitnami/nginx

    Esto creará varios recursos de Kubernetes, como un Deployment, un Service, y posiblemente ConfigMaps y Secrets, dependiendo del chart.

Paso 2: Exportar los manifiestos generados por Helm

Para usar Kustomize sobre los recursos generados por Helm, primero necesitamos exportar esos recursos como manifiestos YAML.

  1. Guardar los manifiestos generados por Helm en un archivo YAML:

    helm template my-nginx bitnami/nginx > base-nginx.yaml

    Esto generará un archivo base-nginx.yaml con todos los recursos que se desplegarían mediante el chart de Helm. En este punto, tenemos los manifiestos básicos listos para usar con Kustomize.

Paso 3: Configurar Kustomize para personalizar los recursos

Ahora que tenemos los manifiestos exportados, podemos usar Kustomize para aplicar personalizaciones adicionales sin modificar el archivo base. Crearemos una estructura de Kustomize que nos permitirá superponer configuraciones específicas.

  1. Crear la estructura de directorios para Kustomize:

    mkdir -p kustomize/base mkdir -p kustomize/overlays/production
  2. Mover el archivo generado por Helm al directorio base:

    mv base-nginx.yaml kustomize/base/deployment.yaml
  3. Crear un archivo kustomization.yaml en el directorio base para que Kustomize reconozca los recursos base:

    # kustomize/base/kustomization.yaml resources: - deployment.yaml
  4. Crear un kustomization.yaml para el entorno de producción en el directorio overlays/production:

    # kustomize/overlays/production/kustomization.yaml resources: - ../../base patchesStrategicMerge: - replica-patch.yaml - label-patch.yaml
  5. Crear el parche replica-patch.yaml para escalar el número de réplicas en producción:

    # kustomize/overlays/production/replica-patch.yaml apiVersion: apps/v1 kind: Deployment metadata: name: my-nginx spec: replicas: 5 # Escalar a 5 réplicas en producción
  6. Crear el parche label-patch.yaml para agregar etiquetas específicas del entorno:

    # kustomize/overlays/production/label-patch.yaml apiVersion: apps/v1 kind: Deployment metadata: name: my-nginx labels: environment: production

Paso 4: Aplicar las personalizaciones con Kustomize

Una vez configurados los parches, podemos usar Kustomize para aplicar las personalizaciones sobre los recursos generados por Helm.

  1. Aplicar los manifiestos personalizados en el clúster:

    kubectl apply -k kustomize/overlays/production

    Este comando aplicará los recursos modificados en el entorno de producción, con el número de réplicas escalado y las etiquetas personalizadas agregadas.

Beneficios del uso combinado de Helm y Kustomize

  • Separación de responsabilidades: Puedes usar Helm para gestionar la instalación y actualización de aplicaciones empaquetadas, mientras que Kustomize te permite personalizar fácilmente los manifiestos sin tocar los archivos originales generados por Helm.
  • Facilidad para diferentes entornos: Con Kustomize, puedes gestionar personalizaciones específicas para diferentes entornos (desarrollo, staging, producción) utilizando las mismas bases generadas por Helm.
  • Modificaciones sin modificar los charts: Puedes aplicar ajustes específicos sin la necesidad de modificar los charts de Helm, lo que facilita las actualizaciones futuras.

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...