La gestión del ciclo de vida de las aplicaciones en Kubernetes mediante Helm requiere una comprensión profunda de cómo se aplican los cambios a través de helm upgrade. A diferencia de una simple instalación, la actualización implica comparar el estado deseado con el estado actual para minimizar la interrupción del servicio. Este documento explora los mecanismos internos de actualización, la evolución hacia la estrategia de fusión de tres vías (three-way merge) y el comportamiento específico de los recursos configurables como ConfigMaps.

Mecánica Básica de Upgrade y Revisión de Manifests

Cuando se ejecuta un comando de actualización, Helm no recrea necesariamente todos los recursos desde cero. En su lugar, calcula las diferencias entre el manifiesto generado por la nueva versión del Chart y el manifiesto almacenado en el registro de releases de Helm. Para ilustrar este flujo, consideremos un release existente llamado app-service desplegado en el namespace production.

Primero, verificamos el estado actual del release:

helm list -n production --filter "app-service"
# Salida esperada:
# NAME          NAMESPACE       REVISION        UPDATED                                 STATUS      CHART               APP VERSION
# app-service   production      1               2023-10-27 10:00:00.000000000 +0000 UTC deployed    app-service-1.0.0   v1.0.0

Supongamos que el Deployment asociado tiene actualmente una configuración de réplicas definida en el archivo values.yaml:

# values.yaml (Inicial)
replicaCount: 1
image:
  repository: my-app
  tag: "1.0"

Al modificar el valor de replicaCount a 3 y ejecutar la actuallización, Helm regenera el manifiesto del Deployment. El comando subyacente es similar al siguiente:

helm upgrade app-service ./charts/app-service \
  --namespace production \
  --set replicaCount=3

Helm procesa estos cambios, genera el nuevo YAML y lo envía a la API de Kubernetes. Si observamos el manifiesto resultante en el clúster, veremos que solo los campos modificados han cambiado, manteniendo la integridad de otros parámetros gestionados por el sistema o manualmente si no fueron sobrescritos explícitamente:

# Manifiesto Resultante (Extracto)
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: app-container
        image: my-app:1.0

El historial de revisiones permite volver atrás. Cada ejecución de upgrade incrementa el número de revisión. Para revertir a la configuración anterior (revisión 1), se utiliza:

helm rollback app-service 1 --namespace production

Es crucial notar que helm upgrade también puede detectar cambios en la estructura del Chart mismo, no solo en los valores. La lógica interna compara los objetos Kubernetes generados antes y después para determinar qué acciones de patching o recreación son necesarias.

Evolución Estratégica: Del Overwrite al Three-Way Merge

En versiones anteriores de Helm (v2), la estrategia de actualización era más primitiva. Se basaba principalmente en aplicar el nuevo manifiesto sobre el antiguo. Esto presentaba problemas significativos cuando se realizaban cambios externos al proceso de despliegue de Helm. Por ejemplo, si un administrador escalaba manualmente un Deployement a 0 réplicas fuera de Helm, y luego se ejecutaba un rollback, Helm podría no restaurar correctamente el estado porque no tenía conocimiento de esa intervención externa.

Helm 3 introdujo la estrategia de Fusión de Tres Vías (Three-Way Merge). Esta técnica compara tres fuentes de información:

1. El manifiesto de la versión anterior del Release (almacenado en Helm).
2. El manifiesto de la nueva versión del Release (generado por Helm).
3. El estado actual real del recurso en el clúster de Kubernetes.

Este enfoque permite resolver conflictos de manera inteligente. Consideremos el siguiente escenario:

• Paso 1: Desplegar my-release con 2 réplicas.
• Paso 2: Escalar manualmente el Deployment a 0 réplicas usando kubectl scale.
• Paso 3: Ejecutar helm rollback my-release 1.

Con la estrategia antigua, el rollback podría fallar en restaurar las 2 réplicas si Helm asumía que el estado local ya coincidía con el objetivo. Con la fusión de tres vías, Helm detecta la discrepancia entre el estado del clúster (0 réplicas) y el estado deseado en la revisión 1 (2 réplicas), generando un parche que fuerza la restauración correcta. Esto asegura que las operaciones de actualización y reversión sean idempotentes y predecibles, incluso ante intervenciones humanas externas.

Gestión de Configuraciones Dinámicas: El Caso de ConfigMap

Un aspecto crítico en las actualizaciones es el manejo de datos de configuración inyectados en los Pods, comúnmente a través de ConfigMaps o Secrets. Un error frecuente es asumir que actualizar el ConfigMap en el clúster provocará automáticamente la recarga de la aplicación dentro del Pod.

Por defecto, los volúmenes montados desde ConfigMaps en Kubernetes sí reflejan cambios posteriores, pero esto depende de la implementación específica de la aplicación para releer esos archivos. Sin embargo, desde la perspectiva de Helm, hay una distinción importante:

Si el contenido del ConfigMap cambia como parte de un helm upgrade (por ejemplo, modificando values.yaml que alimenta la plantilla del ConfigMap), Helm actualizará el objeto ConfigMap en Kubernetes. No obstante, esto no reinicia los Pods automáticamente a menos que se configure específicamente para ello.

Para garantizar que las nuevas configuraciones surtan efecto inmediatamente tras una actualización de Helm, se recomienda utilizar checksum annotations en el pod template. Esto fuerza a Kubernetes a reconocer que el manifiesto del Deployment ha cambiado estructuralmente (debido a la nueva anotación), disparando así un rollout de nuevos Pods.

Ejemplo de implementación en la plantilla del Deployment (deployment.yaml):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}
spec:
  template:
    metadata:
      annotations:
        # Calcula un hash basado en el contenido del ConfigMap referenciado
        checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}
    spec:
      containers:
      - name: app
        volumeMounts:
        - name: config-volume
          mountPath: /etc/config
      volumes:
      - name: config-volume
        configMap:
          name: {{ .Release.Name }}-config

De esta forma, cuando se ejecuta helm upgrade y el contenido del ConfigMap cambia, el hash en la anotación también cambia. Kubernetes interpreta esto como una modificación al template del Pod, iniciando un nuevo conjunto de réplicas que cargan la configuración actualizada. Sin esta anotación, los Pods existentes continuarían utilizando la caché local del volumen o no detectarían el cambio hasta un reinicio manual, independientemente de que el objeto ConfigMap en el API Server haya sido actualizado por Helm.

Además, es vital entender que durante un rollback, Helm revierte tanto el Deployment como el ConfigMap a sus estados previos. Gracias a la estrategia de tres vías, Helm asegurará que el ConfigMap vuelva a tener el contenido exacto de la revisión anterior, y si se usa la anotación de checksum, los Pods se reemplazarán para consumir esa configuración revertida.