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