Helm 4.0 Todo lo que necesitas saber sobre la mayor evolución del ecosistema Helm

Helm 4.0 Todo lo que necesitas saber sobre la mayor evolución del ecosistema Helm

Helm es uno de las principales utilidades dentro del ecosistema de Kubernetes y por tanto la release de una nueva version major, como es Helm 4.0 es algo a tener en consideración porqué sin dudas es algo que se va a tener que analizar, valorar y gestionar en los próximos meses.

Debido a eso, veremos muchos comentarios y artículos alrededor de este tema, por lo que vamos a intentar mostrar algo de luz.

Principales novedades de Helm 4.0

Según el propio proyecto en su anuncio, Helm 4 introduce tres grandes bloques de cambios: nuevo sistema de plugins, mejor integración con Kubernetes ** y modernización interna de SDK y rendimiento**.

Nuevo sistema de plugins (incluye WebAssembly)

Se ha rediseñado por completo del sistema de plugins, haciendo un enfoque especial en la seguridad mediante la introducción de un nuevo runtime WebAssembly que si bien es opcional, es recomendado dado que se ejecutan en un modo «sandbox» que ofrece limites y garantías desde el punto de vista de la seguridad

De todos modos, no hay que preocuparse en exceso, ya que los plugins “clásicos” siguen funcionando, pero el mensaje es claro: para seguridad y extensibilidad, la dirección es Wasm.

Server-Side Apply y mejor integración con otros controladores

Desde esta versión Helm 4 a través del flag --server-side se soporta Server-Side Apply (SSA) que ya se ha convertido en estable desde la versión v1.22 de Kubernetes y permite llevar al lado del servidor las actualizaciones sobre los objetos para evitar conflictos entre diferentes controladores que gestionan los mismos recursos.

También incorporar integración con kstatus para asegurar el estado de un componente de na una manera más fiable que lo que ocurre actualmente con el uso del parámetro --wait

Otras Mejoras Adicionales

Adicionalmente hay otro listado de mejores que siendo de menor calado son saltos cualitativos de importancia como puede ser los siguiente:

  • Instalación por digest en registries OCI: (helm install myapp oci://...@sha256:<digest>)
  • Valores multi-document: puedes pasar varios YAML de values en un único fichero multi-doc, facilitando entornos / overlays complejos.
  • Nuevo argumento --set-json que permite de una manera sencilla pasar estructuras complejas comparado con la solución actual mediante uso del parámetro --set

¿Por qué una major (v4) y no otra minor de la 3.x?

Tal y como explican en la entrada oficial de lanzamiento había features que el equipo no podía introducir en v3 sin romper APIs públicas del SDK y arquitectura interna:

  • Cambio fuerte en el sistema de plugins (WebAssembly, nuevos tipos, integración profunda con el core).
  • Reestructuración de paquetes Go y establecimiento de un SDK estable en helm.sh/helm/v4, incompatible a nivel de código con v3.
  • Introducción y futura evolución de Charts v3, que requieren que el SDK soporte múltiples versiones de API de charts.

Con todo esto, seguir en la rama 3.x habría violado SemVer: el cambio de número mayor está básicamente “pagando” la deuda técnica acumulada para poder avanzar.

Adicionalmente se espera en el futuro una nueva evolución de las charts, pasando de una v2 a una futura v3 que aun no esta completamente definida y actualmente las charts v2 se ejecutan correctamente en esta nueva versión.

¿Tengo que migrar a esta nueva versión?

La respuesta corta es: si. Y posiblemente la respuesta larga sea: sí, y rápido. En el anuncio oficial de Helm 4 especifican el calendario de soporte de Helm 3:

  • Bugfixes de Helm 3 hasta el 8 de julio de 2026.
  • Security fixes de Helm 3 hasta el 11 de noviembre de 2026.
  • No se backportearán nuevas features a Helm 3 durante ese periodo; únicamente se actualizarán librerías de cliente de Kubernetes para soportar nuevas versiones de K8s.

Traducción práctica:

  • Tienes ~1 año para planificar migración tranquila a Helm 4 con soporte de bugs.
  • Después de noviembre de 2026, seguir usando Helm 3 será cada vez más arriesgado desde el punto de vista de seguridad y compatibilidad.

Buenas prácticas para migración

Para realizar la migración hay que recordar que es perfectamente posible y factible tener instaladas ambas versiones en un misma máquina o agente, por lo que se puede hacer una migración «paulatina» para asegurar que se llega al final del soporte de la versión v3 con todo migrado correctamente, y para eso se recomiendan lo siguientes pasos:

  • Realizar un análisis de todos los comandos y uso de Helm tanto desde el punto de vista de pipelines de integración, scripts de upgrade o incluso la importación de librerías cliente de helm en desarrollos basados en Helm.
  • Especialmente revisar con cautela todos los usos de --post-renderer, helm registry login, --atomic, --force.
  • Posteriormente al análisis empezar a probar Helm 4 primero en entornos no productivos, reutilizando los mismos charts y values, revirtiendo a Helm 3 en caso de que se detecte un problema hasta que este sea sub
  • Si tienes plugins críticos, probarlos explícitamente con Helm 4 antes de hacer el cambio global.

Desbloqueando la Flexibilidad y Reutilización: Aprovechando el Poder de los Subgráficos de Múltiples Instancias de Helm

Desbloqueando la Flexibilidad y Reutilización: Aprovechando el Poder de los Subgráficos de Múltiples Instancias de Helm

El uso de subgráficos de múltiples instancias de Helm como parte de tu gráfico principal podría ser algo que, desde el principio, puede sonar extraño. Ya comentamos sobre los subgráficos y dependencias de los gráficos de helm en el blog porque el caso de uso habitual es así:

Tengo un gráfico que necesita otro componente, y lo «importo» como un subgráfico, lo que me da la posibilidad de desplegar el mismo componente y personalizar sus valores sin necesidad de crear otra copia del gráfico y, como puedes imaginar, simplificando mucho la gestión de los gráficos, un ejemplo puede ser así:

Descubre cómo múltiples subgráficos pueden revolucionar tus despliegues de Helm. Aprende a aprovechar el poder de la reutilización y personalización, permitiéndote desplegar componentes idénticos con configuraciones únicas. Mejora la flexibilidad y simplifica la gestión con esta avanzada característica de Helm. Desbloquea todo el potencial de tu arquitectura de microservicios y toma el control de despliegues de aplicaciones complejas. Sumérgete en el mundo de múltiples subgráficos y eleva tus gráficos de Helm al siguiente nivel.

Entonces, creo que eso está totalmente claro, pero ¿de qué estamos hablando ahora? El caso de uso es tener el mismo subgráfico definido dos veces. Así que, imagina este escenario, estamos hablando de eso en lugar de esto:

# Chart.yaml
dependencies:
- name: nginx
  version: "1.2.3"
  repository: "https://example.com/charts"
- name: memcached
  version: "3.2.1"
  repository: "https://another.example.com/charts"

Estamos teniendo algo como esto

# Chart.yaml
dependencies:
- name: nginx
  version: "1.2.3"
  repository: "https://example.com/charts"
- name: memcached-copy1
  version: "3.2.1"
  repository: "https://another.example.com/charts"
- name: memcached-copy2
  version: "3.2.1"
  repository: "https://another.example.com/charts"

Así que tenemos la opción de definir más de una «instancia» del mismo subgráfico. Y supongo que, en este momento, puedes empezar a preguntarte: «¿Cuáles son los casos de uso donde podría necesitar esto?»

Porque eso es bastante comprensible, a menos que lo necesites nunca te darás cuenta de eso. Es lo mismo que me pasa a mí. Así que hablemos un poco sobre posibles casos de uso para esto.

 Casos de Uso para Dependencia de Múltiples Instancias de Helm

Imagina que estás desplegando un gráfico de helm para un conjunto de microservicios que pertenecen al ámbito de la misma aplicación y cada uno de los microservicios tiene la misma base tecnológica, que puede ser TIBCO BusinessWorks Container Edition o pueden ser microservicios Golang. Así que todos ellos tienen la misma base por lo que pueden usar el mismo gráfico «bwce-microservice» o «golang-microservices» pero cada uno de ellos tiene su propia configuración, por ejemplo:

  • Cada uno de ellos tendrá su propio nombre de imagen que diferirá de uno a otro.
  • Cada uno de ellos tendrá su propia configuración que diferirá de uno a otro.
  • Cada uno de ellos tendrá sus propios puntos de conexión que diferirán y probablemente incluso se conectarán a diferentes fuentes como bases de datos o sistemas externos.

Así que, este enfoque nos ayudaría a reutilizar el mismo gráfico de helm tecnológico, «bwce» e instanciarlo varias veces, para que podamos tener cada uno de ellos con su propia configuración sin la necesidad de crear algo «personalizado» y manteniendo los mismos beneficios en términos de mantenibilidad que el enfoque de dependencia de helm nos proporciona.

 ¿Cómo podemos implementar esto?

Ahora que tenemos claro el caso de uso que vamos a soportar, el siguiente paso es sobre cómo podemos hacer esto una realidad. Y, para ser honesto, esto es mucho más simple de lo que puedes pensar desde el principio, comencemos con la situación normal cuando tenemos un gráfico principal, llamémoslo un «programa», que ha incluido una plantilla «bwce» como una dependencia como puedes ver aquí:

name: multi-bwce
description: Helm Chart para Desplegar una Aplicación TIBCO BusinessWorks Container Edition
apiVersion: v1
version: 0.2.0
icon: 
appVersion: 2.7.2

dependencies:
- name: bwce
  version: ~1.0.0
  repository: "file:///Users/avazquez/Data/Projects/DET/helm-charts/bwce"

Y ahora, vamos a movernos a un enfoque de múltiples instancias donde requeriremos dos microservicios diferentes, llamémoslos serviceA y serviceB, y ambos usarán el mismo gráfico de helm bwce.

Así que lo primero que modificaremos es el Chart.yaml de la siguiente manera:

name: multi-bwce
description: Helm Chart para Desplegar una Aplicación TIBCO BusinessWorks Container Edition
apiVersion: v1
version: 0.2.0
icon: 
appVersion: 2.7.2

dependencies:
- name: bwce
  alias: serviceA
  version: ~0.2.0
  repository: "file:///Users/avazquez/Data/Projects/DET/helm-charts/bwce"
- name: bwce
  alias: serviceB
  version: ~0.2.0
  repository: "file:///Users/avazquez/Data/Projects/DET/helm-charts/bwce"

La parte importante aquí es cómo declaramos la dependencia. Como puedes ver en el nombre seguimos manteniendo el mismo «nombre» pero tienen un campo adicional llamado «alias» y este alias es lo que nos ayudará a identificar más tarde las propiedades para cada una de las instancias según lo requiramos. Con eso, ya tenemos nuestra definición de instancia de serviceA y serviceB y podemos comenzar a usarlo en el values.yml de la siguiente manera:

# Este es un archivo con formato YAML.
# Declara variables para ser pasadas a tus plantillas.

serviceA:
  image: 
    imageName: 552846087011.dkr.ecr.eu-west-2.amazonaws.com/tibco/serviceA:2.5.2
    pullPolicy: Always
serviceB:  
  image: 
    imageName: 552846087011.dkr.ecr.eu-west-2.amazonaws.com/tibco/serviceB:2.5.2
    pullPolicy: Always
  

 Conclusión

El principal beneficio de esto es que mejora las opciones de usar gráficos de helm para aplicaciones «complejas» que requieren diferentes instancias del mismo tipo de componentes y al mismo tiempo.

Eso no significa que necesites un gráfico de helm enorme para tu proyecto porque esto iría en contra de todas las mejores prácticas del enfoque de contenedorización y microservicios, pero al menos te dará la opción de definir diferentes niveles de abstracción como desees, manteniendo todos los beneficios desde una perspectiva de gestión.

Consejos y trucos avanzados de Helm: Comandos y banderas poco comunes para una mejor gestión de Kubernetes

Consejos y trucos avanzados de Helm: Comandos y banderas poco comunes para una mejor gestión de Kubernetes

Gestionar los recursos de Kubernetes de manera efectiva puede a veces parecer abrumador, pero Helm, el gestor de paquetes de Kubernetes, ofrece varios comandos y banderas que hacen el proceso más fluido e intuitivo. En este artículo, profundizaremos en algunos comandos y banderas menos conocidos de Helm, explicando sus usos, beneficios y ejemplos prácticos.

1. helm get values: Recuperando Valores del Chart Desplegado

El comando helm get values es esencial cuando necesitas ver los valores de configuración de un chart de Helm desplegado. Esto es particularmente útil cuando tienes un chart desplegado pero no tienes acceso a su archivo de configuración original. Con este comando, puedes lograr un enfoque de «Infraestructura como Código» capturando el estado actual de tu despliegue.

Uso:

helm get values <release-name> [flags]
  • <release-name>: El nombre de tu release de Helm.

Ejemplo:

Para obtener los valores de un chart desplegado llamado my-release:

helm get values my-release --namespace my-namespace

Este comando muestra los valores actuales utilizados para el despliegue, lo cual es valioso para la documentación, replicar el entorno o modificar despliegues.

2. Entendiendo las Banderas de helm upgrade: --reset-values, --reuse-values, y --reset-then-reuse

El comando helm upgrade se utiliza típicamente para actualizar o modificar un release de Helm existente. Sin embargo, el comportamiento de este comando puede ajustarse finamente usando varias banderas: --reset-values, --reuse-values, y --reset-then-reuse.

  • --reset-values: Ignora los valores previos y utiliza solo los valores proporcionados en el comando actual. Usa esta bandera cuando quieras sobrescribir completamente la configuración existente.

Escenario de Ejemplo: Estás desplegando una nueva versión de tu aplicación y quieres asegurarte de que no se retengan valores antiguos.

  helm upgrade my-release my-chart --reset-values --set newKey=newValue
  • --reuse-values: Reutiliza los valores del release anterior y los fusiona con cualquier nuevo valor proporcionado. Esta bandera es útil cuando quieres mantener la mayor parte de la configuración antigua pero aplicar algunos ajustes.

Escenario de Ejemplo: Necesitas agregar una nueva variable de entorno a un despliegue existente sin afectar las otras configuraciones.

  helm upgrade my-release my-chart --reuse-values --set newEnv=production
  • --reset-then-reuse: Una combinación de los dos. Se restablece a los valores originales y luego se fusionan los valores antiguos, permitiéndote comenzar con una hoja limpia mientras retienes configuraciones específicas.

Escenario de Ejemplo: Útil en entornos complejos donde quieres asegurarte de que el chart esté usando la configuración predeterminada original pero retener algunos valores personalizados.

  helm upgrade my-release my-chart --reset-then-reuse --set version=2.0

3. helm lint: Asegurando la Calidad del Chart en Pipelines CI/CD

El comando helm lint verifica los charts de Helm en busca de errores de sintaxis, mejores prácticas y otros problemas potenciales. Esto es especialmente útil al integrar Helm en un pipeline CI/CD, ya que asegura que tus charts sean confiables y se adhieran a las mejores prácticas antes del despliegue.

Uso:

helm lint <chart-path> [flags]
  • <chart-path>: Ruta al chart de Helm que deseas validar.

Ejemplo:

helm lint ./my-chart/

Este comando escanea el directorio my-chart en busca de problemas como campos faltantes, estructura YAML incorrecta o uso obsoleto. Si estás automatizando despliegues, integrar helm lint en tu pipeline ayuda a detectar problemas temprano.

Integrando helm lint en un Pipeline CI/CD:

En un pipeline de Jenkins, por ejemplo, podrías agregar la siguiente etapa:

pipeline {
  agent any
  stages {
stage('Lint Helm Chart') {
  steps {
    script {
      sh 'helm lint ./my-chart/'
    }
  }
}
// Otras etapas como build, test, deploy
  }
}

Al agregar esta etapa, aseguras que cualquier problema de sintaxis o estructura se detecte antes de proceder a las etapas de construcción o despliegue.

4. helm rollback: Revertir a un Release Anterior

El comando helm rollback te permite revertir un release a una versión anterior. Esto puede ser increíblemente útil en caso de una actualización o despliegue fallido, ya que proporciona una forma de restaurar rápidamente un estado conocido como bueno.

Uso:

helm rollback <release-name> [revision] [flags]
  • <release-name>: El nombre de tu release de Helm.
  • [revision]: El número de revisión al que deseas revertir. Si se omite, Helm revertirá al release anterior por defecto.

Ejemplo:

Para revertir un release llamado my-release a su versión anterior:

helm rollback my-release

Para revertir a una revisión específica, digamos la revisión 3:

helm rollback my-release 3

Este comando puede ser un salvavidas cuando un cambio reciente rompe tu aplicación, permitiéndote restaurar rápidamente la continuidad del servicio mientras investigas el problema.

5. helm verify: Validando un Chart Antes de Usarlo

El comando helm verify verifica la integridad y validez de un chart antes de que sea desplegado. Este comando asegura que el archivo del paquete del chart no haya sido manipulado o corrompido. Es particularmente útil cuando estás obteniendo charts de repositorios externos o usando charts compartidos entre varios equipos.

Uso:

helm verify <chart-path>
  • <chart-path>: Ruta al archivo del chart de Helm (.tgz file).

Ejemplo:

Para verificar un chart descargado llamado my-chart:

helm verify ./my-chart.tgz

Si el chart pasa la verificación, Helm mostrará un mensaje de éxito. Si falla, verás detalles de los problemas, que podrían ir desde archivos faltantes hasta discrepancias en el checksum.

Conclusión

Aprovechar estos comandos y banderas avanzados de Helm puede mejorar significativamente tus capacidades de gestión de Kubernetes. Ya sea que estés recuperando configuraciones de despliegue existentes, ajustando tus actualizaciones de Helm o asegurando la calidad de tus charts en un pipeline CI/CD, estos trucos te ayudan a mantener un entorno de Kubernetes robusto y eficiente.

Comprendiendo los Hooks de Helm: Una Guía para Usar Hooks en tus Charts de Helm

Comprendiendo los Hooks de Helm: Una Guía para Usar Hooks en tus Charts de Helm

Helm, el gestor de paquetes para Kubernetes, es una herramienta poderosa para gestionar aplicaciones complejas de Kubernetes. Una de sus características avanzadas son los hooks de Helm. Los hooks te permiten intervenir en diferentes puntos de una operación de Helm, como antes o después de una instalación, actualización o eliminación. En este artículo, profundizaremos en los hooks disponibles, exploraremos cómo definirlos en tus charts de Helm y proporcionaremos casos de uso para cada uno.

¿Qué son los Hooks de Helm?

Los hooks de Helm son anotaciones especiales que se pueden agregar a los recursos en un chart de Helm. Estos hooks desencadenan acciones específicas durante el ciclo de vida de la liberación de un chart de Helm. Permiten a los desarrolladores realizar tareas como configurar requisitos previos, limpiar después de una operación o validar un despliegue.

Hooks de Helm Disponibles y Casos de Uso

Helm proporciona varios hooks que se pueden usar en diferentes etapas de una operación de Helm. Aquí hay un desglose de los hooks disponibles:

1. pre-install

Momento de Ejecución: Después de que las plantillas se renderizan pero antes de que se creen recursos en Kubernetes.
Casos de Uso: Imagina que necesitas crear un ConfigMap o secreto del que depende tu aplicación pero que no forma parte del chart principal. El hook pre-install puede crear este recurso antes de que se despliegue el resto del chart.

apiVersion: v1
kind: Job
metadata:
  name: setup-config
  annotations:
"helm.sh/hook": pre-install
spec:
  template:
spec:
  containers:
    - name: config-creator
      image: busybox
      command: ['sh', '-c', 'echo "config data" > /config/config.txt']

2. post-install

Momento de Ejecución: Después de que todos los recursos se crean en Kubernetes.
Casos de Uso: Si tu aplicación requiere que se carguen algunos datos iniciales en una base de datos después de que esté en funcionamiento, un hook post-install podría usarse para ejecutar un trabajo que pueble estos datos.

apiVersion: batch/v1
kind: Job
metadata:
  name: init-database
  annotations:
"helm.sh/hook": post-install
spec:
  template:
spec:
  containers:
    - name: db-init
      image: busybox
      command: ['sh', '-c', 'init-db-command']

3. pre-delete

Momento de Ejecución: En una solicitud de eliminación, antes de que se eliminen recursos de Kubernetes.
Casos de Uso: Usa un hook pre-delete para apagar servicios de manera ordenada o para respaldar datos importantes antes de eliminar una liberación de Helm.

apiVersion: batch/v1
kind: Job
metadata:
  name: backup-before-delete
  annotations:
"helm.sh/hook": pre-delete
spec:
  template:
spec:
  containers:
    - name: backup
      image: busybox
      command: ['sh', '-c', 'backup-command']

4. post-delete

Momento de Ejecución: Después de que se han eliminado todos los recursos de la liberación.
Casos de Uso: Un hook post-delete podría usarse para limpiar recursos externos a Kubernetes que fueron creados por el chart de Helm, como recursos en la nube o entradas de bases de datos.

apiVersion: batch/v1
kind: Job
metadata:
  name: cleanup
  annotations:
"helm.sh/hook": post-delete
spec:
  template:
spec:
  containers:
    - name: cleanup
      image: busybox
      command: ['sh', '-c', 'cleanup-command']

5. pre-upgrade

Momento de Ejecución: En una solicitud de actualización, después de que las plantillas se renderizan, pero antes de que se actualicen los recursos.
Casos de Uso: Supón que necesitas validar algunas condiciones previas antes de aplicar una actualización. Un hook pre-upgrade puede ejecutar un trabajo para verificar el entorno o validar la nueva configuración.

apiVersion: batch/v1
kind: Job
metadata:
  name: pre-upgrade-check
  annotations:
"helm.sh/hook": pre-upgrade
spec:
  template:
spec:
  containers:
    - name: upgrade-check
      image: busybox
      command: ['sh', '-c', 'upgrade-check-command']

6. post-upgrade

Momento de Ejecución: Después de que todos los recursos han sido actualizados.
Casos de Uso: Después de una actualización exitosa, un hook post-upgrade podría usarse para desencadenar un trabajo que verifique la funcionalidad de la aplicación o migre datos a un nuevo esquema.

apiVersion: batch/v1
kind: Job
metadata:
  name: post-upgrade-verify
  annotations:
"helm.sh/hook": post-upgrade
spec:
  template:
spec:
  containers:
    - name: verification
      image: busybox
      command: ['sh', '-c', 'verify-upgrade']

7. pre-rollback

Momento de Ejecución: En una solicitud de reversión, después de que las plantillas se renderizan, pero antes de que se reviertan los recursos.
Casos de Uso: Este hook puede usarse para preparar el sistema para la reversión, como respaldar datos o notificar a otros sistemas sobre la reversión inminente.

apiVersion: batch/v1
kind: Job
metadata:
  name: pre-rollback-backup
  annotations:
"helm.sh/hook": pre-rollback
spec:
  template:
spec:
  containers:
    - name: backup
      image: busybox
      command: ['sh', '-c', 'rollback-backup']

8. post-rollback

Momento de Ejecución: Después de que todos los recursos han sido modificados por la reversión.
Casos de Uso: Usa un hook post-rollback para verificar el estado de la aplicación después de una reversión o para notificar a sistemas externos sobre la finalización de la reversión.

apiVersion: batch/v1
kind: Job
metadata:
  name: post-rollback-verify
  annotations:
"helm.sh/hook": post-rollback
spec:
  template:
spec:
  containers:
    - name: verify
      image: busybox
      command: ['sh', '-c', 'verify-rollback']

9. test

Momento de Ejecución: Se ejecuta cuando se invoca el subcomando helm test.
Casos de Uso: Este hook es ideal para ejecutar pruebas contra una liberación de Helm para verificar que funcione como se espera.

apiVersion: batch/v1
kind: Job
metadata:
  name: test-application
  annotations:
"helm.sh/hook": test
spec:
  template:
spec:
  containers:
    - name: test
      image: busybox
      command: ['sh', '-c', 'run-tests']

Anotaciones en Hooks de Helm

Además de definir hooks, Helm te permite controlar la ejecución de hooks usando anotaciones:

  • helm.sh/resource-policy: Previene que los recursos sean eliminados después de que el hook se ejecute. Valor posible:
  • keep: Mantiene el recurso después de que el hook se ejecute, útil para depuración o retención de registros.
  • helm.sh/hook-weight: Especifica el orden en el que los hooks deben ejecutarse. Los hooks con pesos más bajos se ejecutan antes que aquellos con pesos más altos.
  • helm.sh/hook-delete-policy: Controla cuándo deben eliminarse los recursos del hook. Los valores posibles incluyen:
  • hook-succeeded: Elimina el recurso si la ejecución del hook es exitosa.
  • hook-failed: Elimina el recurso si la ejecución del hook falla.
  • before-hook-creation: Elimina recursos de hooks anteriores antes de crear nuevos, asegurando que solo una instancia del hook esté activa.

Conclusión

Los hooks de Helm son herramientas poderosas que proporcionan un control detallado sobre el ciclo de vida de despliegue de tus aplicaciones en Kubernetes. Al entender y aprovechar estos hooks, puedes asegurar que tus despliegues de Helm sean tanto robustos como confiables. Asegúrate de usar las anotaciones apropiadas para afinar aún más el comportamiento de tus hooks, optimizándolos para tu caso de uso específico.

Helm v3.17 introduce take-ownership: Qué resuelve y cuándo usarlo

Helm v3.17 introduce take-ownership: Qué resuelve y cuándo usarlo

Helm ha sido durante mucho tiempo el estándar para gestionar aplicaciones de Kubernetes utilizando gráficos empaquetados, aportando un nivel de reproducibilidad y automatización al proceso de implementación. Sin embargo, algunas tareas operativas, como renombrar una versión o migrar objetos entre gráficos, tradicionalmente han requerido soluciones complicadas. Con la introducción del flag --take-ownership en Helm v3.17 (lanzado en enero de 2025), finalmente se aborda un punto de dolor de larga data, al menos parcialmente.

En esta publicación, exploraremos:

  • Qué hace el flag --take-ownership
  • Por qué era necesario
  • Las advertencias y limitaciones
  • Casos de uso del mundo real donde ayuda
  • Cuándo no usarlo

Entendiendo la Propiedad de Objetos en Helm

Cuando Helm instala o actualiza un gráfico, inyecta metadatos—etiquetas y anotaciones—en cada objeto de Kubernetes gestionado. Estos incluyen:

app.kubernetes.io/managed-by: Helm
meta.helm.sh/release-name: my-release
meta.helm.sh/release-namespace: default

Estos metadatos cumplen un papel importante: Helm los utiliza para rastrear y gestionar recursos asociados con cada versión. Como medida de seguridad, Helm no permite que otra versión modifique objetos que no posee y cuando intentas hacerlo verás mensajes como el siguiente:

Error: Unable to continue with install: Service "provisioner-agent" in namespace "test-my-ns" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must equal "dp-core-infrastructure11": current value is "dp-core-infrastructure"

Si bien esto protege a los usuarios de sobrescrituras accidentales, crea limitaciones para casos de uso avanzados.

Por Qué Se Necesitaba --take-ownership

Supongamos que quieres:

  • Renombrar una versión existente de Helm de api-v1 a api.
  • Mover un ConfigMap o Service de un gráfico a otro.
  • Reconstruir el estado durante la reconciliación de GitOps cuando los metadatos anteriores de Helm se han desviado.

Anteriormente, tu única opción era:

  1. Desinstalar la versión existente.
  2. Reinstalar con el nuevo nombre.

Este enfoque introduce tiempo de inactividad, y en sistemas de producción, eso a menudo no es aceptable.

Qué Hace el Flag

helm upgrade my-release ./my-chart --take-ownership

Cuando se pasa este flag, Helm:

  • Omitirá la validación de propiedad para objetos existentes.
  • Sobrescribirá las etiquetas y anotaciones para asociar el objeto con la versión actual.

En la práctica, esto te permite reclamar la propiedad de recursos que anteriormente pertenecían a otra versión, permitiendo transferencias sin problemas.

⚠️ Lo Que No Hace

Este flag no:

  • Limpia referencias de la versión anterior.
  • Te protege de futuras desinstalaciones de la versión original (que aún podrían eliminar recursos compartidos).
  • Te permite adoptar recursos de Kubernetes completamente no gestionados (aquellos no creados inicialmente por Helm).

En resumen, es un mecanismo para eludir las verificaciones de propiedad de Helm, no un gestor de ciclo de vida completo.

Casos de Uso del Mundo Real

Veamos escenarios comunes donde esta característica es útil.

✅ 1. Renombrar una Versión Sin Tiempo de Inactividad

Antes:

helm uninstall old-name
helm install new-name ./chart

Ahora:

helm upgrade new-name ./chart --take-ownership

✅ 2. Migrar Objetos Entre Gráficos

Estás refactorizando un gráfico grande en otros más pequeños y modulares y necesitas reasignar ciertos objetos Service o Secret.

Este flag permite que la nueva versión tome control del objeto sin eliminarlo o recrearlo.

✅ 3. Reconciliación de Desviaciones en GitOps

Si los objetos fueron desplegados fuera de banda o sus metadatos cambiaron sin intención, las herramientas de GitOps que usan Helm pueden recuperarse sin intervención manual usando --take-ownership.

Mejores Prácticas y Recomendaciones

  • Usa este flag intencionalmente, y documenta dónde se aplica.
  • Si es posible, elimina la versión anterior después de la migración para evitar confusiones.
  • Monitorea de cerca el comportamiento de Helm al gestionar objetos compartidos.
  • Para recursos no gestionados por Helm, continúa usando kubectl annotate o kubectl label para alinear manualmente los metadatos.

Conclusión

El flag --take-ownership es una adición bienvenida al arsenal de la CLI de Helm. Aunque no es una solución universal, suaviza muchas de las asperezas que enfrentan los desarrolladores y SREs durante la evolución de versiones y la adopción de GitOps.

Aporta una mejora sutil pero poderosa, especialmente en entornos complejos donde la propiedad de los recursos no es estática.

Mantente actualizado con las versiones de Helm, y considera este flag como tu nuevo aliado en la ingeniería avanzada de versiones.