El fin de vida de Helm 3, explicado

El fin de vida de Helm 3 es la fecha a partir de la cual el proyecto Helm deja de publicar cualquier versión de Helm 3, incluidas las correcciones de seguridad. Esa fecha es el 10 de febrero de 2027, según el anuncio de fin de vida del proyecto Helm. Muchas guías todavía dicen noviembre de 2026, la fecha del plan original. Los equipos que usan Helm 3 en scripts y pipelines tienen unos tres meses para pasarse a Helm 4.

Helm es el gestor de paquetes de Kubernetes, el sistema que ejecuta contenedores en muchos servidores. Un chart de Helm es un paquete de plantillas para una aplicación. Instalar un chart crea un release, y cada actualización añade una revisión numerada al historial de ese release.

Esta guía cubre el calendario, lo que cambia Helm 4 y una prueba práctica de Helm 4.3.1 con releases creados por Helm 3.22.1.

Cómo funciona el fin de vida de Helm 3

Helm 3 se retira en dos pasos, según el anuncio de fin de vida que George Jenkins escribió para el proyecto el 2 de junio de 2026.

• Las correcciones de errores terminaron el 9 de septiembre de 2026. La versión de ese día fue la última versión con funciones de Helm 3. Solo añadió bibliotecas cliente de Kubernetes actualizadas. Así Helm 3 podía comunicarse con versiones más nuevas de Kubernetes.
• Las correcciones de seguridad terminan el 10 de febrero de 2027. Si se encuentra un fallo antes, el proyecto todavía publica un parche. Después de esa fecha, Helm 3 no recibe más actualizaciones, "incluidas la biblioteca cliente de Kubernetes y los parches de seguridad", según el anuncio.

Las notas de la versión v3.22.0 confirman que 3.22 es la última versión menor de Helm 3. El parche más reciente, 3.22.1, salió el 15 de octubre de 2026.

El fin de vida no apaga nada. Un binario de Helm 3 sigue funcionando después del 10 de febrero de 2027, como señala Private DevOps en su guía de migración. Simplemente deja de recibir correcciones de seguridad y soporte para nuevas versiones de Kubernetes.

Qué cambió y cuándo

El calendario original venía de HIP-0012, una propuesta de mejora de Helm. Prometía correcciones de seguridad para Helm 3 durante un año después de Helm 4.0.0, es decir, hasta noviembre de 2026. En junio, los mantenedores añadieron tres meses.

Fecha	Qué pasó
12 de noviembre de 2025	Sale Helm 4.0.0 en la KubeCon, la primera versión mayor nueva de Helm en seis años
2 de junio de 2026	Helm extiende tres meses las correcciones de seguridad de Helm 3
9 de septiembre de 2026	Última versión con funciones de Helm 3 (3.22); terminan las correcciones de errores
15 de octubre de 2026	Salen Helm 3.22.1 y Helm 4.3.1, las versiones más recientes al 8 de noviembre
13 de enero de 2027	Helm 4.4.0 previsto, según la página de versiones
10 de febrero de 2027	Terminan las correcciones de seguridad de Helm 3; no habrá más versiones de Helm 3

El consejo del anuncio es directo: "Recomendamos encarecidamente a todos los usuarios migrar a Helm 4 antes de esa fecha".

Qué cambia Helm 4 para los usuarios de Helm 3

Según el proyecto Helm, Helm 4 "debería ser compatible con la mayoría de los charts, releases y flujos de trabajo de Helm 3 existentes". Los charts en el formato v2 actual funcionan sin cambios, y un nuevo formato de chart v3 sigue siendo experimental. La descripción general de Helm 4 enumera los cambios que importan:

• Flags renombrados. --atomic ahora es --rollback-on-failure, y --force ahora es --force-replace. Los nombres antiguos siguen funcionando, pero muestran una advertencia.
• Los post-renderers son plugins. Un post-renderer edita la salida de Helm antes de que llegue al clúster. --post-renderer ahora recibe el nombre de un plugin instalado, no la ruta a un script.
• El inicio de sesión en el registro usa un nombre de host. helm registry login solo acepta un dominio, no una URL.
• Server-side apply para instalaciones nuevas. Con server-side apply, el propio Kubernetes fusiona cada cambio y registra qué herramienta es dueña de cada campo. Las actualizaciones y las reversiones mantienen el método que el release ya usaba. Por eso, los releases creados por Helm 3 se quedan con el método antiguo del lado del cliente. El flag --server-side cambia esto.
• Un sistema de plugins nuevo. Los plugins existentes siguen funcionando. También pueden ejecutarse en un runtime de WebAssembly opcional, que el proyecto recomienda por seguridad.

Probado: Helm 4.3.1 con releases creados por Helm 3

En una prueba de Tech AI Wire del 8 de noviembre de 2026, un clúster k3s con Kubernetes 1.36.6 se ejecutó en Docker 28.4.0 sobre macOS 26.6.2. Los dos binarios de Helm vinieron de get.helm.sh, y sus sumas de comprobación SHA-256 coincidieron. Helm 3.22.1 instaló el chart de ejemplo que escribe helm create. Después, Helm 4.3.1 trabajó sobre el mismo release. A continuación, los dos binarios se llaman helm3 y helm4.

helm3 install web ./demo --wait
helm4 upgrade web ./demo --atomic --set replicaCount=2
helm4 registry login https://ghcr.io -u test -p test
helm4 template web ./demo --post-renderer ./pr.sh
helm4 get metadata web

Prueba	Resultado
Helm 4 lee el release de Helm 3	Sí: helm list y helm history lo mostraron
upgrade --atomic	Funcionó, con "Flag --atomic has been deprecated, use --rollback-on-failure instead"
upgrade --force	Funcionó, con "Flag --force has been deprecated, use --force-replace instead"
registry login https://ghcr.io	Falló: invalid reference: invalid registry "https://ghcr.io"
--post-renderer ./pr.sh, un script de shell	Falló: plugin no encontrado; Helm 3.22.1 ejecutó el mismo script
Método de aplicación del release de Helm 3 tras actualizar con Helm 4	"client-side apply (defaulted)"
Método de aplicación de una instalación nueva con Helm 4	"server-side apply"
Helm 3 después de las actualizaciones con Helm 4	Leyó las cuatro revisiones y volvió a la revisión 1

Los propios registros de Kubernetes coincidieron. El Deployment del release de Helm 3 se escribió con una operación "Update", y el nuevo release de Helm 4 con un "Apply".

Un resultado no aparece en la documentación. --server-side=true pasó el release de Helm 3 a server-side apply. Una actualización posterior con Helm 3.22.1 hizo que Helm 4 lo volviera a reportar como del lado del cliente, con la marca "(defaulted)". Si el binario antiguo y el nuevo se turnan en un release, una migración puede deshacerse sin avisar.

Qué significa esto para los desarrolladores

• Arreglar primero los dos fallos totales. Buscar en los scripts de CI helm registry login con https:// y --post-renderer que apunte a un script. Ambos detienen un pipeline de Helm 4, mientras que los flags renombrados solo muestran advertencias.
• Renombrar --atomic y --force ya. Todavía funcionan, pero Helm 4 los marca como obsoletos y muestra una advertencia en cada ejecución.
• Un solo binario por release. Durante la migración, un release que Helm 4 ya tocó solo debe actualizarse con Helm 4. Si no, el método de aplicación puede volver atrás.
• Elegir server-side apply a propósito. Los releases creados por Helm 3 siguen del lado del cliente hasta que alguien pase --server-side. Probar el cambio en un clúster de staging antes de producción.
• Fijar la versión de Helm en la CI y probar las reversiones. Private DevOps recomienda listar cada llamada a Helm y probar Helm 4 fuera de producción primero.
• No esperar al 10 de febrero. Después de esa fecha, un fallo de seguridad de Helm 3 queda sin parche, y las versiones nuevas de Kubernetes no tienen soporte en el cliente de Helm 3.