Tutorial del Cuadro de Mando: Guía paso a paso con ejemplos

Instalación y configuración de Helm

Veremos cómo instalar Helm CLI en Windows, Mac y Linux.

En el momento de escribir esto, la última versión de Helm es la 3.17.2. En los ejemplos de este artículo se utilizará la versión 3.17.2. Puedes encontrar el último binario en las versiones oficiales de GitHub.

Instalación en Windows

Descarga el binario correcto correspondiente a la arquitectura de tu sistema desde el enlace de versiones de GitHub que aparece más arriba.

Helm binario para Windows

Extrae el archivo ZIP descargado. Deberías obtener los archivos que se muestran a continuación.

Timón binario

Crea una carpeta llamada "helm" en el directorio "C:Archivos de programa". Mueve allí los tres archivos anteriores.

Mueve los archivos a la carpeta "helm" recién creada

Ahora tendremos que añadir una ruta en nuestras variables de entorno para que apunte a este directorio "C:\Archivos de programa\helm" recién creado. Abre la opción "Editar las variables de entorno del sistema".

Edita las variables de entorno del sistema

Aparecerá la ventana "Propiedades del sistema". En la pestaña "Avanzado", selecciona "Variables de entorno...".

Propiedades del sistema

Aparecerá la ventana "Variables de entorno" que se muestra a continuación. En "Variables del sistema", selecciona "Ruta". Asegúrate de que está resaltado en azul. A continuación, selecciona "Editar".

Variables de entorno

Aparecerá la ventana "Editar variable de entorno". Selecciona "Nuevo", introduce la ruta "C:Archivos de programa" y selecciona "Aceptar".

Edita la variable de entorno

Selecciona "Aceptar" en las ventanas "Variables de entorno" y "Propiedades del sistema" para cerrarlas. Abre un terminal nuevo y comprueba que el comando Helm funciona.

Verifica la instalación de Helm CLI

Instalación en macOS

Podemos instalar la CLI de Helm en macOS mediante Homebrew o el binario. Cubriré ambos métodos de instalación.

Instalación binaria

Abre el terminal (zsh) y ejecuta los siguientes comandos.

# Download the correct binary corresponding to your system’s architecture.
wget https://get.helm.sh/helm-v3.17.2-darwin-arm64.tar.gz

# Extract the binary
tar -zxvf helm-v3.17.2-darwin-arm64.tar.gz

# Move the helm binary to /usr/local/bin
sudo mv darwin-arm64/helm /usr/local/bin/

# Verify Helm CLI
helm version

Instalación de Helm mediante binario en macOS

Elaboración casera

Asegúrate de que tienes Homebrew instalado localmente. Para verificarlo, ejecuta brew --version. Si no, puedes consultar la página oficial de Homebrew para obtener instrucciones de instalación.

Ejecuta los siguientes comandos para instalar la CLI de Helm:

# With brew installed, update Homebrew's formulae and cask definitions
brew update

# Install Helm CLI
brew install helm

# Verify the installation
helm version

# Verify the location of the helm binary stored locally
which helm

Instalación de Helm mediante brew en macOS

Instalación en Linux

Para demostrar la instalación en Linux, he puesto en marcha un EC2 de Amazon Linux con la AMI ami-065a492fef70f84b1.

# Switch to superuser
sudo su -

# Download the correct binary corresponding to your system’s architecture.
wget https://get.helm.sh/helm-v3.17.2-linux-amd64.tar.gz

# Extract the binary
tar -zxvf helm-v3.17.2-linux-amd64.tar.gz

# Move the helm binary to /usr/local/bin
mv linux-amd64/helm /usr/local/bin/helm

# Verify Helm CLI
helm version

# Clean-up
rm -rf linux-amd64
rm -f helm-v3.17.2-linux-amd64.tar.gz

Descarga, extrae y mueve el binario

Configurar Helm con tu clúster

De forma idéntica a cómo se configura kubectl para comunicarse con un cluster concreto, Helm también utiliza el archivo ~/.kube/config para saber en qué cluster ejecutar los comandos.

# To find out which context (and therefore cluster) is currently being used
kubectl config current-context

# To view the entire ~/.kube/config file
kubectl config view

# If you’re running an EKS cluster on AWS, execute this command to update your .kubeconfig file and set it to the current context.
aws eks update-kubeconfig --name <Name of EKS cluster> --region <region>

# View helm charts installed in all namespaces on the cluster
helm list -A

Salida de los comandos kubectl config

Añadir y actualizar repositorios Helm

Los gráficos Helm públicos se almacenan en repositorios Helm. Antes de utilizar un gráfico Helm público, debemos añadir algunos metadatos de ese repositorio a nuestro local.

# Adds a Helm repository locally
helm repo add bitnami https://charts.bitnami.com/bitnami

¿Dónde guarda la información el comando helm repo add? Ejecuta helm env.

Salida de helm repo add y helm env

La ruta mostrada por HELM_REPOSITORY_CONFIG es donde se guarda la información del repositorio.

Para listar todos los repositorios añadidos localmente, ejecuta el comando helm repo list. Obtiene la información a partir del valor de HELM_REPOSITORY_CONFIG.

Para mí, será el archivo ~/Library/Preferences/helm/repositories.yaml.

Para listar todos los gráficos del repositorio, ejecuta helm search repo bitnami.

Salida de helm repo list y helm search repo

Como repositorios públicos, reciben actualizaciones periódicas de los respectivos colaboradores. Para actualizar los gráficos dentro del repositorio, basta con actualizar todo el repositorio.

# Update a repository
helm repo update bitnami

Salida de la actualización del repositorio helm

Explorando la Estructura de un Cuadro de Mando

Para comprender realmente cómo funcionan los gráficos Helm, es importante familiarizarse con su estructura. 

Un gráfico Helm es algo más que un conjunto de archivos YAML: es un directorio bien organizado que define una aplicación Kubernetes combinando plantillas, configuración y metadatos. 

En esta sección, desglosaré los componentes clave, incluida la disposición general del directorio del gráfico, el papel del archivo values.yaml para la configuración y cómo Helm utiliza plantillas Go para generar manifiestos Kubernetes de forma dinámica.

Estructura del directorio del gráfico

El directorio por defecto del gráfico es el siguiente, donde demo-helm es el nombre del gráfico que he definido. Lo crearemos en la siguiente sección. 

Veamos brevemente la finalidad de cada archivo o carpeta que contiene.

#    demo-helm/
#    ├── .helmignore   # Contains patterns to ignore when packaging Helm charts.
#    ├── Chart.yaml    # Information about your chart
#    ├── values.yaml   # The default values for your templates
#    ├── charts/       # Charts that this chart depends on
#    └── templates/    # The template files
#        └── tests/    # The test files

• El archivo .helmignore funciona de forma similar a .gitignore o .dockerignore. Si queremos excluir determinados archivos o directorios de nuestro gráfico Helm, podemos listar sus patrones en el archivo .helmignore. Cualquier archivo o directorio que coincida con esos patrones será ignorado durante la ejecución de los comandos de Helm.
• Chart.yaml contiene metadatos sobre el gráfico Helm, como el nombre del gráfico, la descripción, la versión del gráfico y la versión de la aplicación.
• values.yaml contiene los valores de configuración por defecto que convierten las plantillas Go del gráfico Helm en manifiestos Kubernetes. Algunos valores comunes definidos en este archivo son
  • El repositorio de imágenes y la etiqueta.
  • Banderas booleanas para activar o desactivar recursos específicos.
  • Números de puerto.
  • Otros ajustes específicos de la aplicación.
• El directorio de la carpeta charts/ almacena las dependencias de los gráficos. Si nuestro gráfico Helm depende de otros gráficos (conocidos como subgráficos), se colocarán aquí.
• Por último está la carpeta templates/, que contiene los archivos de plantilla Go utilizados para generar manifiestos Kubernetes. Estas plantillas definen los recursos que se desplegarán, como Deployment, ServiceAccount, Service, Ingress, y ConfigMap.

Comprender values.yaml

values.yaml es el archivo de configuración por defecto, que proporciona una ubicación central para definir los valores de entrada a los que hacen referencia las plantillas al renderizar los manifiestos de Kubernetes.

Al instalar un gráfico Helm, Helm lee el archivo values.yaml e inyecta su contenido en las plantillas del gráfico a través del motor de plantillas. Esto nos permite parametrizar la configuración de la aplicación, como las versiones de las imágenes contenedoras, los límites de recursos, el recuento de réplicas, la configuración de entrada, etc., sin alterar directamente las plantillas.

Un fragmento del values.yaml predeterminado de un gráfico Helm recién creado es el siguiente:

# Default values for demo-helm.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

# This will set the replicaset count more information can be found here: https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/
replicaCount: 1

# This sets the container image more information can be found here: https://kubernetes.io/docs/concepts/containers/images/
image:
  repository: nginx
  # This sets the pull policy for images.
  pullPolicy: IfNotPresent
  # Overrides the image tag whose default is the chart appVersion.
  tag: ""

# This is for the secrets for pulling an image from a private repository more information can be found here: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
imagePullSecrets: []
# This is to override the chart name.
nameOverride: ""
fullnameOverride: ""

# This section builds out the service account more information can be found here: https://kubernetes.io/docs/concepts/security/service-accounts/
serviceAccount:
  # Specifies whether a service account should be created
  create: true
  # Automatically mount a ServiceAccount's API credentials?
  automount: true

Estos valores se referencian en los archivos de plantilla utilizando la notación ., como {{ .Values.replicaCount }} o {{ .Values.image.repository }}. Helm permite anular estos valores por defecto en la instalación o actualización, lo que se hace utilizando un archivo de valores personalizados o pasando valores individuales en línea.

# Install a helm chart with the default values from values.yaml
helm install demo-helm ./demo-helm

# Values defined in custom-values.yaml will override those in values.yaml.
# Nonetheless, values in values.yaml not found in custom-values.yaml will still be applied.
# “-f” flag is short for the “--values” flag
helm install demo-helm ./demo-helm -f custom-values.yaml

# Overwrite default values using the  “--set” flag
helm install demo-helm ./demo-helm --set replicaCount=3 --set image.tag=latest

Plantillas Go

Una de las características más potentes de Helm es su motor de plantillas, que permite una configuración dinámica y reutilizable de los manifiestos de Kubernetes. Las plantillas Go son el núcleo de esta función, y el mismo lenguaje de plantillas se utiliza en muchas otras herramientas y marcos basados en Go, como Terraform y Docker.

En lugar de codificar valores directamente en nuestros archivos YAML, Helm nos permite definir plantillas que hacen referencia a entradas dinámicas, normalmente de values.yaml. Por ejemplo, en el fragmento de plantilla deployment que aparece a continuación:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.name }}
spec:
  replicas: {{ .Values.replicas }}

{{ .Values.name }} y {{ .Values.replicas }} son expresiones de plantilla Go. Donde .Values se refiere al contenido del archivo values.yaml, al archivo definido en la bandera --values o a valores pasados en línea. Estos marcadores de posición se sustituyen por valores reales cuando se representa el gráfico.

Por ejemplo, la plantilla deployment que aparece a continuación utiliza valores como replicaCount y image.repository.

Mapeo entre values.yaml y deployment.yaml

Mientras tanto, la plantilla serviceAccount utiliza serviceAccount.create. Se omitirá todo el recurso serviceAccount si el valor es falso.

Mapeo entre values.yaml y serviceaccount.yaml

Para ilustrarlo mejor, supongamos que tienes la siguiente configuración en tu values.yaml.

replicaCount: 2
image:
  repository: nginx
  tag: "1.21.1"

Tu plantilla deployment.yaml (en templates/deployment.yaml ) podría tener este aspecto:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Release.Name }}
  template:
    metadata:
      labels:
        app: {{ .Release.Name }}
    spec:
      containers:
        - name: nginx
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          ports:
            - containerPort: 80

Cuando Helm renderiza el manifiesto de Kubernetes, ya sea durante helm template, helm install, o helm upgrade, lo hace inyectando los valores de values.yaml.

# helm template <release name> <chart name OR path to chart folder>
helm template my-nginx <chart name OR path to chart folder>

En el que obtendremos el siguiente manifiesto:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-nginx
  template:
    metadata:
      labels:
        app: my-nginx
    spec:
      containers:
        - name: nginx
          image: "nginx:1.21.1"
          ports:
            - containerPort: 80

Crear tu primer cuadro de mando

La forma más fácil de aprender Helm es construyendo nosotros mismos un gráfico. Vamos a caminar a través de la creación de un gráfico básico, la comprensión de su estructura, y la personalización para desplegar nuestra aplicación en Kubernetes.

Usando helm create

En lugar de utilizar los gráficos Helm públicos de los repositorios Helm, a los que ya nos hemos referido en la subsección "Añadir y actualizar repositorios Helm", vamos a crear uno propio.

# Creates a helm chart with the name “demo-helm”
helm create demo-helm

La estructura de directorios será la siguiente

#    demo-helm/
#    ├── .helmignore   # Contains patterns to ignore when packaging Helm charts.
#    ├── Chart.yaml    # Information about your chart
#    ├── values.yaml   # The default values for your templates
#    ├── charts/       # Charts that this chart depends on
#    └── templates/    # The template files
#        └── tests/    # The test files

Salida del comando helm create

Personalizar plantillas

Exploremos el contenido de la carpeta templates para entenderlo mejor antes de modificarlo.

Contenido de la carpeta de plantillas

El archivo _helpers.tpl almacena ayudantes de plantillas Go reutilizables (similares a funciones) que pueden llamarse desde otras plantillas dentro del gráfico, promoviendo la reutilización y el mantenimiento del código .

La siguiente imagen muestra cómo se asignan las secciones del archivo _helpers.tpl al archivo service.yaml.

Asignación entre _helpers.tpl y service.yaml

Podemos ejecutar el comando helm template para obtener el renderizado service.yaml. El comando valida que el gráfico no contiene errores y renderiza los archivos de manifiesto.

# helm template <release name> <chart name OR path to chart folder>
helm template demo-helm ./demo-helm

Salida del comando plantilla helm

Podemos añadir o modificar los contenidos tanto del archivo _helpers.tpl como de cualquiera de los recursos de la plantilla para adaptarlos a nuestras necesidades. Por ejemplo, para añadir una etiqueta selectora al recurso service a través del archivo _helpers.tpl:

{{- define "demo-helm.selectorLabels" -}}
app.kubernetes.io/name: {{ include "demo-helm.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/custom: "testing" # Add this line
{{- end }}

Añadir una etiqueta selectora en _helpers.tpl

Las comillas utilizadas alrededor del valor testing deben ser comillas rectas ("probando") y no comillas rizadas ("probando"). Aunque helm template no nos arrojará un error, helm install sí lo hará .

• Guarda el archivo _helpers.tpl y vuelve a ejecutar el comando helm template. Deberías ver que el selector se añade al recurso de servicio.

Salida actualizada del comando de plantilla helm

Observa que, además de añadirse al selector, también se ha añadido a las etiquetas de todos los recursos. Esto se debe a que el {{- define "demo-helm.labels" -}} contiene el {{ include "demo-helm.selectorLabels" . }}. Así, todo lo que aparezca en selectorLabels se incluirá en las etiquetas .

Otro ejemplo es que podemos modificar el deployment.yaml para exponer otro puerto en el contenedor. Por defecto, cuando creamos un gráfico desde el comando helm create, la plantilla de despliegue sólo expone un puerto en el contenedor.

• Añade la siguiente configuración a deployment.yaml.

- name: https
  containerPort: 443
  protocol: TCP

Añadido un puerto al contenedor en deployment.yaml

Para simplificar, el valor de containerPort está codificado como 443. En la siguiente subsección exploraremos cómo utilizar la values.yaml para parametrizarla .

• Guarda el archivo deployment.yaml y vuelve a ejecutar el comando helm template. El puerto debería añadirse ahora al contenedor en el recurso de despliegue.

Como la sangría es crucial en el formato YAML, la plantilla de los recursos Kubernetes incluye la función nindent para sangrar los bloques necesarios en consecuencia.

apiVersion: v1
kind: Service
metadata:
  name: {{ include "demo-helm.fullname" . }}
  labels:
    {{- include "demo-helm.labels" . | nindent 4 }} 
spec:
  type: {{ .Values.service.type }}
  ports:
    - port: {{ .Values.service.port }}
      targetPort: http
      protocol: TCP
      name: http
  selector:
    {{- include "demo-helm.selectorLabels" . | nindent 4 }}

Definir valores por defecto

Ahora que hemos cubierto la mayor parte del contenido de la carpeta de plantillas, estamos listos para pasar a la página values.yaml.

Directorio de cartas del timón

En la subsección anterior, hemos establecido que containerPort sea 443. Vamos a parametrizarlo. 

• En values.yaml, bajo la clave service, añade la clave anidada https_port con el valor 443.

Añadir clave anidada

• Modifica el deployment.yaml para sustituir el 443 codificado por {{ .Values.service.port }}.

Parametriza el número de puerto

• Para validar y renderizar los recursos Kubernetes:

# helm template <release name> <chart name OR path to chart folder>
helm template demo-helm ./demo-helm

Deberías ver que el valor 443 está correctamente configurado en containerPort.

Valor de https_port renderizado

Si hay otras ubicaciones dentro del gráfico del timón que requieran el valor de este containerPort, simplemente utiliza {{ .Values.service.https_port }}.

Despliegue y gestión de versiones

Ahora que hemos creado nuestro propio gráfico Helm, el siguiente paso sería desplegarlo en un clúster Kubernetes. 

Helm gestiona el ciclo de vida de los recursos Kubernetes desplegados como una versión. En esta sección, exploraremos cómo Helm gestiona los despliegues, las actualizaciones, las reversiones y el seguimiento del historial de versiones, proporcionándonos un control y una visibilidad potentes sobre nuestras cargas de trabajo Kubernetes.

¿Qué es una liberación?

En Helm, una versión es una instancia específica de un gráfico de Helm que se ha desplegado en un clúster Kubernetes.

Cada vez que instalamos una carta utilizando helm install, Helm crea una nueva versión con su propio nombre, configuración y versión. Del mismo modo, cuando actualizamos una versión utilizando helm upgrade, Helm crea una nueva revisión de esa versión con el mismo nombre, pero la configuración y la versión pueden diferir. Esencialmente, una versión es una nueva versión de la misma versión con ajustes actualizados o contenido gráfico.

Así que, cuando decimos "instalar un gráfico Helm", en realidad nos referimos a "crear una versión Helm".

Ilustración visual de las liberaciones - imagen del Autor.

Aunque sólo se despliega activamente en el clúster la revisión más reciente de una versión, Helm conserva el historial completo de las revisiones anteriores. Esto significa que podemos volver fácilmente a un estado anterior utilizando helm rollback.

Cuando realizamos un rollback, Helm no restaura la antigua revisión de la versión tal cual, sino que crea una nueva revisión que replica la configuración de la versión anterior seleccionada. Cada revisión está numerada, y las reversiones incrementan el número de revisión, manteniendo el historial de versiones coherente y auditable.

Instalar una carta con helm install

Vamos a desplegar una versión de Helm en un clúster Kubernetes. Instalaremos dos cartas Helm: la que creamos en la sección anterior y la carta bitnami/apache del repositorio público de Bitnami que ya hemos añadido a nuestra configuración local de Helm.

cuadro bitnami/apache Helm

Al instalar un gráfico, debemos especificar un nombre de publicación: puede ser cualquier cosa que elijamos y no tiene por qué coincidir con el nombre del gráfico. Sin embargo, se recomienda utilizar un nombre que esté estrechamente relacionado con el gráfico para facilitar a los usuarios la comprensión de lo que representa la versión de un vistazo.

• En primer lugar, para el gráfico Helm que hemos creado:

# Install the helm chart (in other words, create a helm release) into the default namespace
# helm install <release name> <chart name OR path to chart folder>
helm install datacamp-demo-helm ./demo-helm
# OR
helm upgrade --install datacamp-demo-helm ./demo-helm

# If installing to a specific namespace, add the -n flag
# Install the chart to the “app” namespace
helm install my-amazing-helm-demo ./demo-helm -n app

Despliega un gráfico Helm personalizado

# To validate the Kubernetes resources
# Get pods, service, and serviceaccount resources in the default namespace
kubectl get pods,svc,sa

Validar los recursos desplegados desde el gráfico personalizado de Helm

• En segundo lugar, para el gráfico bitnami/apache:

# Install the helm chart into the default namespace
helm install apache bitnami/apache
# OR
helm upgrade --install apache bitnami/apache

Salida de la instalación del timón

Salida de helm upgrade --install

Para ver las versiones de Helm que se han desplegado:

# List all helm releases in all namespaces
helm list -A

Lista de todos los comunicados de Helm

Mejora con la mejora del timón

Tras el despliegue inicial de un gráfico Helm, las actualizaciones son inevitables, ya sea cambiando la etiqueta de la imagen, ajustando el número de réplicas, activando o desactivando recursos opcionales o modificando los valores de configuración.

Helm proporciona el comando helm upgrade para aplicar estos cambios a una versión existente sin volver a desplegar desde cero. Este comando nos permite actualizar nuestra aplicación en ejecución volviendo a renderizar las plantillas con la nueva configuración y aplicando los cambios al clúster Kubernetes, gestionando sin problemas las actualizaciones con una interrupción mínima.

La aplicación desplegada a través de nuestro gráfico personalizado de helm ejecuta una imagen nginx con la etiqueta 1.16.0. Podemos determinar la etiqueta ejecutando el comando helm get manifest.

# Output the rendered Kubernetes manifest that was installed by the helm chart
# helm get manifest <release name>
helm get manifest datacamp-demo-helm

En el manifiesto del recurso deployment, deberías ver lo siguiente:

Valor de la imagen

¿De dónde viene la etiqueta 1.16.0? Nuestro valor image.tag en values.yaml está vacío .

Examina la plantilla deployment.yaml: la clave image tiene el valor "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}". Cuando el image.tag no esté definido en values.yaml, Helm obtendrá el valor del appVersion definido en Charts.yaml.

appVersion in Chart.yaml

• Actualicemos el values.yaml de nuestro gráfico personalizado, actualiza el image.tag a "1.26".

Actualiza image.tag de "" a "1.26"

• A continuación, ejecuta el comando helm upgrade.

# helm upgrade <release name> <chart name or path to chart>
helm upgrade datacamp-demo-helm ./demo-helm

# Alternatively, you can update the value via the --set flag
helm upgrade datacamp-demo-helm ./demo-helm --set 

La salida del comando de actualización helm

Examina el recurso de despliegue; la etiqueta de imagen debe ser 1.26. Entre bastidores, durante una actualización, Helm hace lo siguiente:

1. Renderizado de plantillas: Helm vuelve a renderizar las plantillas del gráfico utilizando los valores (actualizados) pasados con el comando.
2. Determina los cambios: Helm compara los manifiestos recién renderizados con los actuales del cluster. En la última sección del artículo, exploraremos la verificación de los cambios antes de aplicarlos.
3. Actualización selectiva: Sólo se actualizan los recursos que han cambiado (como un deployment, configmaps, o secrets ).
4. Seguimiento del historial de versiones: Helm registra la nueva versión y configuración, permitiéndonos retroceder si es necesario.

# To view the release history. It also shows the revision numbers.
# helm history <release name>
helm history datacamp-demo-helm

Salida del comando helm history

Retroceder con helm rollback

Acabamos de actualizar una versión de Helm, pero poco después nos damos cuenta de que la aplicación no se comporta como esperábamos. Aunque la resolución de problemas es importante, en un entorno de producción, la prioridad inmediata suele ser estabilizar el sistema. Ahí es donde entra en juego la función de retroceso de Helm. 

Helm facilita la reversión a una versión anterior conocida y buena con un solo comando, lo que nos permite recuperarnos rápidamente de implantaciones fallidas y minimizar el tiempo de inactividad. 

• Revertiremos la actualización realizada anteriormente.

# The first argument of the rollback command is the name of a release, and the second is a revision (version) number. If this argument is omitted or set to 0, it will roll back to the previous release.
# helm rollback <release name> <revision number>
helm rollback datacamp-demo-helm 0

La salida del comando helm rollback

Examina el despliegue de datacamp-demo-helm, y deberías ver que la etiqueta de imagen nginx vuelve a 1.16.0.

kubectl get deploy datacamp-demo-helm -oyaml

Desinstalar una versión

Para desinstalar la versión de Helm, es decir, para eliminar todos los recursos de Kubernetes desplegados desde la versión, ejecuta el comando helm uninstall.

# helm uninstall <release name>
helm uninstall datacamp-demo-helm
helm uninstall apache

Salida del comando helm uninstall

Para ver cómo Helm admite canalizaciones CI/CD escalables, especialmente para flujos de trabajo de ML, explora el curso CI/CD para machine learning.

Personalizar los gráficos del timón para distintos entornos

Uno de los mayores puntos fuertes de Helm es su flexibilidad. Tanto si estamos desplegando en desarrollo, staging o producción, Helm facilita la personalización del comportamiento de nuestro gráfico mediante la configuración. 

En esta sección exploraremos cómo adaptar un gráfico Helm a distintos entornos utilizando herramientas como values.yaml, anulaciones específicas del entorno y los indicadores --set y -f de Helm.

Utilizar varios archivos values.yaml

Helm proporciona una forma flexible de gestionar configuraciones específicas del entorno utilizando varios archivos values.yaml .

En lugar de mantener un único y complejo values.yaml que intente tener en cuenta todos los ajustes posibles en desarrollo, preparación y producción, o complejas sentencias condicionales en nuestras plantillas para tener en cuenta los distintos entornos, podemos dividirlos en archivos separados, cada uno adaptado a un entorno específico.

Por ejemplo, nuestro directorio de gráficos podría incluir

my-chart/
├── values.yaml                    # default values
├── values-dev.yaml           # development-specific overrides
├── values-staging.yaml    # staging-specific overrides
└── values-prod.yaml          # production-specific overrides

Anular valores en el momento de la instalación

Helm nos permite anular los valores por defecto definidos en values.yaml utilizando la bandera --set para anulaciones en línea o la bandera -f para proporcionar un archivo de valores externo. La bandera -f es la abreviatura de la bandera --values.

Para instalar o actualizar nuestra versión de Helm con el comando -f :

# For installing on dev
helm install <release name> <chart name or path to chart> -f values-dev.yaml

# For upgrading on dev
helm upgrade <release name> <chart name or path to chart> -f values-dev.yaml

# For installing on staging
helm install <release name> <chart name or path to chart> -f values-staging.yaml

# For upgrading on staging
helm upgrade <release name> <chart name or path to chart> -f values-staging.yaml

Para instalar o actualizar nuestra versión de Helm con la bandera --set:

# For installation
helm install <release name> <chart name or path to chart> --set image.tag=1.26

# For upgrading
helm upgrade <release name> <chart name or path to chart> --set image.tag=1.26

Si durante la instalación (o actualización) se utilizan tanto --set como -f, Helm aplica los valores en el siguiente orden:

1. La base values.yaml (si existe)
2. Valores del archivo especificado con -f
3. Valores en línea pasados con --set

Esto significa que si la misma clave aparece tanto en el archivo -f como en la bandera --set, tendrá prioridad el valor de --set.

Por ejemplo, si definimos que image.tag sea 1.22 en values-dev.yaml, pero establecemos que image.tag sea 1.26 a través de la bandera --set, el valor image.tag que se utilizará para renderizar el manifiesto de Kubernetes será 1.26.

# E.g. we defined image.tag to be 1.22 in values-dev.yaml
helm install <release name> <chart name OR path to chart> --set image.tag=1.26 -f values-dev.yaml

Gestión de secretos

Al desplegar aplicaciones en Kubernetes utilizando Helm, el manejo de datos sensibles, como claves API, credenciales de bases de datos o certificados TLS, requiere un cuidado especial. Aunque Helm es compatible con el recurso Secret de Kubernetes, los valores del recurso secreto están simplemente codificados en base64, lo que puede ser descodificado por cualquiera .

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  namespace: default
type: Opaque
data:
  key1: c3VwZXJzZWNyZXQ=  # ← This is base64 encoded
  key2: dG9wc2VjcmV0          # ← This is base64 encoded

# Decode the value of key1
echo "c3VwZXJzZWNyZXQ=" | base64 -d

# Decode the value of key2
echo "dG9wc2VjcmV0" | base64 -d

Almacenar secretos directamente en un archivo values.yaml o en texto plano dentro de nuestra tabla no es seguro y debe evitarse, especialmente al enviar archivos al control de versiones .

Para gestionar los secretos de forma segura en los gráficos de Helm en distintos entornos, considera la posibilidad de utilizar herramientas diseñadas específicamente para este fin. Dos soluciones ampliamente adoptadas son los Secretos Sellados y los Secretos Externos.

Secretos sellados

Sealed Secrets es un proyecto de código abierto desarrollado por Bitnami que ayuda a gestionar datos confidenciales en Kubernetes de forma segura y compatible con GitOps. Introduce una definición de recurso personalizada (CRD) llamada SealedSecret, que nos permite cifrar secretos antes de consignarlos en un repositorio Git.

A diferencia de los recursos normales de Kubernetes secrets, que almacenan datos en codificación base64 y no están cifrados, los recursos SealedSecret contienen valores cifrados que sólo puede descifrar el controlador de Secretos Sellados que se ejecuta dentro del clúster Kubernetes de destino. Esto significa que los secretos encriptados pueden almacenarse de forma segura en sistemas de control de versiones como Git.

Para configurar nuestro clúster y entorno local para utilizar Secretos Sellados:

• Instala el CRD SealedSecret y el controlador del lado del servidor (que se ejecuta como un pod) en el espacio de nombres kube-system

kubectl apply -f https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.29.0/controller.yaml
#OR
helm install sealed-secret bitnami/sealed-secrets -n kube-system

Instalar SealedSecret en nuestro cluster mediante kubectl

Instalar SealedSecret en nuestro cluster a través de Helm

• Verifica los recursos:

Verificar los recursos de la instalación de Secretos Sellados

• Instalar la CLI kubeseal en nuestro sistema local.

# Linux x86_64:
curl -OL "https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.29.0/kubeseal-0.29.0-linux-amd64.tar.gz"
tar -xvzf kubeseal-0.29.0-linux-amd64.tar.gz kubeseal
sudo install -m 755 kubeseal /usr/local/bin/kubeseal

# macOS
brew install kubeseal

Para crear el recurso SealedSecret CRD:

# Pass the secret manifest to kubeseal for it to generate the SealedSecret CRD resource containing the encrypted secrets. Saves the SealedSecret CRD manifest in sealed-mysecret.yaml.
kubectl create secret generic mysecret --dry-run=client --from-literal key1=supersecret --from-literal key2=topsecret --output json | kubeseal | tee sealed-mysecret.yaml

# Or if you have the secret manifest saved in a JSON file
kubeseal -f mysecret.yaml -w sealed-mysecret.yaml

Genera y guarda el recurso CRD SealedSecret

Aplica el archivo sealed-mysecret.yaml. Cuando se crea un recurso SealedSecret en el clúster, el controlador desencripta automáticamente los datos sellados y crea a partir de ellos un recurso secrets estándar de Kubernetes.

Crea el recurso CRD SealedSecret

Este enfoque garantiza que la información sensible permanezca segura a lo largo de todo el proceso CI/CD.

Operador de Secretos Externos (ESO)

El Operador de Secretos Externos (ESO) es un operador de Kubernetes que nos permite obtener e inyectar de forma segura secretos de sistemas externos de gestión de secretos, como AWS Secrets Manager, HashiCorp Vault, Google Secret Manager, Azure Key Vault y otros, en los Secretos de Kubernetes. 

En lugar de crear o actualizar manualmente los Secretos de Kubernetes, ESO recupera los valores secretos más recientes de estos proveedores externos a través de sus API y garantiza que nuestro clúster de Kubernetes siempre disponga de credenciales o datos sensibles actualizados.

ESO introduce un conjunto de recursos personalizados -ExternalSecret y ClusterSecretStore- que abstraen las complejidades de interactuar con backends secretos externos. Estos recursos definen qué secretos obtener y de dónde, facilitando la gestión de los ciclos de vida de los secretos de forma declarativa y nativa de Kubernetes.

En este ejemplo, obtendremos un secreto de AWS Secrets Manager. 

• En primer lugar, crea un rol IAM que utilizará el pod external-secrets para obtener el secreto de AWS Secrets Manager.

Función IAM para el pod secretos-externos

La política de permisos del rol IAM es la siguiente:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ESO",
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetSecretValue"
            ],
            "Resource": "*"
        }
    ]
}

• En segundo lugar, crea un secreto en AWS Secrets Manager.

Secreto del administrador de secretos de AWS

Configurar nuestro clúster para utilizar ESO:

helm repo add external-secrets https://charts.external-secrets.io


# Replace the ARN of the IAM role
helm install external-secrets external-secrets/external-secrets \
    -n external-secrets \
    --create-namespace \
    --version 0.15.1 \
    --set serviceAccount.annotations."eks\.amazonaws\.com/role-arn"="<ARN of IAM Role>"

Resultado de la instalación de secretos externos

• Verifica la instalación:

kubectl get pods,crd -n external-secrets

Verificar los recursos de la instalación de la ESO

• A continuación, para desplegar el recurso ClusterSecretStore, guarda lo siguiente en cluster-secret-store.yaml y crea el recurso.

apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: "cluster-secret-store"
spec:
  provider:
    aws:
      service: SecretsManager
      region: ap-southeast-1
      auth:
        jwt:
          serviceAccountRef:
            name: "external-secrets"
            namespace: "external-secrets"

kubectl create -f cluster-secret-store.yaml
kubectl get ClusterSecretStore

El recurso personalizado ClusterSecretStore es un SecretStore para todo el clúster al que puede hacer referencia ExternalSecrets desde cualquier espacio de nombres. Hace referencia a external-secrets serviceAccount para autenticarse con AWS Secrets Manager.

Validar la creación del recurso ClusterSecretStore

• Por último, para extraer el secreto demo-datacamp-ESO de AWS Secrets Manager, despliega el recurso personalizado ExternalSecret. Extraeremos el valor de la clave password. Guarda lo siguiente en external-secret.yaml y crea el recurso.

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: demo-datacamp-secret
  namespace: default  # Change to your target namespace
spec:
  refreshInterval: 1h # How often to refresh the secret
  secretStoreRef:
    name: cluster-secret-store # This references your ClusterSecretStore
    kind: ClusterSecretStore
  target:
    name: demo-datacamp-k8s-secret # The name of the resulting Kubernetes Secret
    creationPolicy: Owner # ESO manages lifecycle of the K8s secret
  data:
    - secretKey: password # Key name in the Kubernetes Secret
      remoteRef:
        key: demo-datacamp-ESO # AWS Secrets Manager secret name
        property: password # Key in the AWS secret JSON object

kubectl create -f external-secret.yaml
kubectl get externalsecrets
kubectl get secrets

Verifica la obtención correcta del secreto

En la imagen anterior, podemos ver que el valor top_secret_password de la clave password se ha obtenido correctamente de AWS Secrets Manager, y se ha creado un secreto de Kubernetes que contiene el valor.

Mejores prácticas para el desarrollo de gráficos Helm

A medida que nuestro uso de Helm crece más allá de la instalación básica de cartas, es importante seguir las mejores prácticas que promuevan la mantenibilidad, la reutilización y la fiabilidad. 

Esta sección abarca prácticas de desarrollo clave, como el uso de complementos de Helm para ampliar la funcionalidad, la estructuración de gráficos para su reutilización, la validación de nuestros gráficos con herramientas de linting y la gestión eficaz de versiones y dependencias.

Plugins de Helm

Los plugins de Helm son una potente forma de ampliar la funcionalidad básica de Helm y adaptarla a tu flujo de trabajo. Nos permiten añadir comandos personalizados e integrarnos con herramientas externas sin modificar el propio Helm.

Los plugins pueden instalarse desde repositorios Git, tarballs o directorios locales, y una vez instalados, se comportan como comandos nativos de Helm. Los plugins de Helm se instalan localmente en nuestra máquina, no en el clúster Kubernetes. Esto significa que mejoran nuestras capacidades locales de la CLI de Helm y no requieren ningún cambio ni despliegue en el clúster de Kubernetes. Cada usuario o sistema que ejecute Helm debe instalar los plugins deseados de forma independiente.

Un plugin común que se utiliza mucho, sobre todo en los pipelines CI/CD, es helm-diff. Compara una versión de Helm con un gráfico de Helm y muestra qué cambios se aplicarían. Esto es especialmente útil para previsualizar las actualizaciones.

# Install the plugin
helm plugin install https://github.com/databus23/helm-diff

# List installed plugins
helm plugin list

# View the changes for an upgrade
helm diff upgrade datacamp-demo-helm ./demo-helm --set image.tag="1.26"

Salida de los comandos del plugin helm

Salida del comando diff de helm

Estructurar gráficos reutilizables

A medida que crece nuestro uso de Helm, resulta crucial estructurar nuestros gráficos para que sean reutilizables. Un gráfico Helm bien estructurado fomenta la coherencia, simplifica el mantenimiento y permite patrones de despliegue modulares en todos los proyectos. Aquí tienes dos consejos:

Utiliza plantillas y ayudantes

Como se demostró en la subsección "Personalizar plantillas" de la sección "Crear tu primer gráfico Helm", aprovechamos el archivo _helpers.tpl para añadir un selector adicional al recurso deployment y etiquetas a todos los recursos. El uso de plantillas de ayuda evita la duplicación, proporcionando así una única fuente de verdad para los fragmentos reutilizados habitualmente. Esto mejora la coherencia en todo tu gráfico y facilita el mantenimiento: cualquier cambio futuro sólo tiene que hacerse en un lugar.

Dividir gráficos grandes en subgráficos

Si nuestra aplicación consta de varios componentes débilmente acoplados (por ejemplo, una aplicación web, una base de datos y Redis), considera la posibilidad de dividir el gráfico en subgráficos. Colócalos dentro de la carpeta charts/ y gestiónalos como dependencias a través de Chart.yaml.

dependencies:
  - name: redis
    version: 17.1.2
    repository: https://charts.bitnami.com/bitnami

Ejecuta helm dependency update para sacar esos subgráficos. Esto hace que cada componente sea gestionable de forma independiente y fomenta la reutilización en distintos proyectos.

Limar y validar tablas

Antes de desplegar un gráfico Helm en un clúster Kubernetes, es importante asegurarse de que el gráfico está bien estructurado, es sintácticamente correcto y lógicamente sólido. Helm proporciona herramientas integradas para ayudarnos a detectar problemas en una fase temprana mediante pruebas y linting.

El comando helm lint analiza nuestro gráfico en busca de errores comunes e infracciones de las mejores prácticas. Comprueba la sintaxis de las plantillas, la estructura de los archivos de gráficos y la presencia de campos obligatorios en Chart.yaml.

helm lint ./demo-helm

Salida del comando helm lint

Si modificáramos el valor de name en Chart.yaml de "demo-helm" a "demo_helm", se produciría un problema que helm lint atraparía.

Modificado el "-" por "_"

helm lint lanza mensajes de advertencia

Mediante la linting y las pruebas de nuestros gráficos antes de su despliegue, reducimos el riesgo de lanzamientos fallidos y configuraciones erróneas en producción. Estas prácticas son esenciales para mantener gráficos Helm de alta calidad que se comporten de forma predecible en todos los entornos.

Gestión de versiones y dependencias

A medida que nuestros programas Helm evolucionan y dependen de otros programas, es fundamental gestionar las versiones de forma coherente y realizar un seguimiento preciso de las dependencias. Helm proporciona mecanismos integrados para ello mediante el versionado semántico, el archivo Chart.lock y las dependencias de Chart.yaml.

Helm utiliza el Versionado Semántico para las versiones de los gráficos. La versión de un gráfico se define en Chart.yaml bajo la clave version:

Versión gráfica

El versionado semántico sigue el formato MAJOR.MINOR.PATCH

• MAYORES - cambios de última hora
• MENOR - adiciones de funciones compatibles con versiones anteriores
• PATCH - correcciones de errores compatibles con versiones anteriores

La versión del gráfico debe incrementarse siempre que haya cambios en el propio gráfico, incluyendo sus plantillas, valores o incluso la versión de la aplicación. Al mismo tiempo, la versión de la aplicación refleja la versión de la aplicación real que el gráfico está desplegando, normalmente alineada con la etiqueta de imagen utilizada en el gráfico. Debe actualizarse siempre que cambie la imagen de la aplicación.

Un versionado adecuado ayuda a los equipos a saber si una actualización es segura o requiere precauciones adicionales. También permite a Helm gestionar las rutas de actualización y las dependencias de forma más fiable.

En Helm 3, que es lo que hemos estado utilizando durante todo este artículo, las dependencias se definen directamente en el archivo Chart.yaml, en la sección dependencies. No se incluye por defecto cuando creamos el gráfico. Esto sustituye al archivo requirements.yaml de Helm 2.

Dependencias definidas en Chart.yaml

El archivo Chart.lock se genera automáticamente cuando ejecutas helm dependency update. Actúa como un archivo de bloqueo en muchos gestores de paquetes, registrando las versiones exactas de cada dependencia tal y como se definen en la sección dependencies de Chart.yaml. Esto garantiza construcciones reproducibles y un comportamiento coherente en todos los entornos y equipos.

Contenido en Chart.lock

Si estás familiarizado con Terraform, su concepto es similar al del archivo .terraform.lock.hcl, que bloquea las versiones del proveedor. Aunque los formatos y ecosistemas subyacentes difieren, ambos bloquean las versiones de dependencia para garantizar la estabilidad y la repetibilidad.

Conclusión

Las cartas Helm proporcionan una forma potente y estandarizada de empaquetar, configurar y desplegar aplicaciones en Kubernetes. A lo largo de este artículo, hemos explorado qué es un gráfico Helm, cómo se estructura y cómo simplifica el proceso de despliegue en distintos entornos.

Recorrimos los pasos clave de:

• Crear tu primera carta Helm utilizando helm create.
• Personalizar las configuraciones mediante values.yaml y anulaciones específicas del entorno.
• Despliegue y gestión de versiones utilizando comandos como helm install, helm upgrade, y helm rollback.
• Siguiendo las mejores prácticas como la creación de diagramas, la estructuración de componentes reutilizables, el manejo seguro de secretos y la gestión eficaz de versiones y dependencias.

A medida que vayas ganando confianza trabajando con Helm, tómate tu tiempo para explorar el vasto ecosistemade cartas Helm públicas, alojadas eny tanto comunidades como proveedores. Estos gráficos pueden acelerar tus despliegues y servir como valiosas referencias para tu propio desarrollo.

Por último, considera la posibilidad de aportar tus gráficos a la comunidad. Tanto si se trata de una herramienta interna personalizada como de una versión bien empaquetada de un proyecto de código abierto, tus gráficos pueden ayudar a otros a desplegar de forma más eficiente y coherente en el mundo de Kubernetes.

Helm hace que Kubernetes sea más sencillo: un gráfico cada vez.

• Si piensas obtener una certificación Kubernetes, consulta esteblog en Guía de certificación Kubernetes: Exámenes, consejos y recursos de estudio. 
• Para un programa de aprendizaje estructurado que combine los fundamentos de Docker y Kubernetes, consulta nuestro programa de virtualización y contenedores.
• Refresca tus conocimientos de Git para gestionar mejor los valores y archivos de configuración de Helm con nuestros cursos Introducción a Git y Git Intermedio.