Una vez que existe un chart, el trabajo diario con Helm consiste casi por completo en gestionar releases: instalarlos, actualizarlos a medida que cambian el chart o sus valores y, ocasionalmente, revertir uno. Esta guía cubre ese ciclo de vida de principio a fin.

Los comandos principales

Comando	Qué hace
helm install NAME CHART	Crea un release nuevo a partir de un chart.
helm upgrade NAME CHART	Aplica cambios a un release existente.
helm upgrade --install NAME CHART	Instala si el release aún no existe, actualiza si existe.
helm list	Lista los releases del namespace actual (-A para todos los namespaces).
helm status NAME	Muestra el estado actual de un release y vuelve a mostrar su NOTES.txt.
helm rollback NAME REVISION	Revierte un release a una revisión anterior.
helm uninstall NAME	Elimina un release y sus recursos.

helm upgrade --install merece una mención aparte: es el patrón que casi todos los pipelines de CI/CD usan en realidad, porque significa “asegúrate de que este release existe con esta configuración” sin que el script necesite saber o comprobar si es un primer despliegue o el centésimo.

Cada cambio es una revisión numerada

helm install web ./webapp
helm list

Una instalación nueva es la revisión 1. Cada upgrade posterior añade el siguiente número, y rollback también añade uno, ya que un rollback no es una máquina del tiempo, es una revisión nueva cuyo contenido coincide con una anterior:

Operación	Revisión resultante
helm install	1
helm upgrade	2
helm upgrade	3
helm rollback web 1	4 (el contenido coincide con la revisión 1, pero el número sigue subiendo)

helm history web

lista cada revisión con su estado, versión del chart y versión de la aplicación, que es lo que leen rollback y los comandos de inspección de abajo.

Revierte cuando una actualización sale mal

helm rollback web 2
kubectl rollout status deployment/web

Revertir a un número de revisión concreto es el caso habitual. helm rollback web sin número revierte a la inmediatamente anterior. Como el rollback crea una revisión nueva, revertir y luego volver a revertir te devuelve a donde empezaste, no deshace el propio rollback; consulta helm history para estar seguro de a qué revisión estás realmente volviendo.

Inspecciona un release sin cambiarlo

helm status web
helm get values web
helm get manifest web
helm diff upgrade web ./webapp -f values-prod.yaml   # requiere el plugin helm-diff

get values muestra lo que realmente se proporcionó para este release, útil cuando un release en ejecución no coincide con lo que sugiere un archivo de valores en disco. get manifest muestra el YAML exacto de Kubernetes que Helm aplicó, después de aplicar las plantillas, que es la verdad de base cuando depuras una discrepancia entre el código fuente del chart y lo que está en vivo. helm diff no viene incorporado, es un plugin de la comunidad muy utilizado (helm plugin install https://github.com/databus23/helm-diff), y conviene tenerlo antes de ejecutar una actualización de la que no estés seguro, ya que muestra exactamente qué cambiaría sin aplicar nada.

Desinstala, y conserva o descarta el historial

helm uninstall web
helm uninstall web --keep-history

Por defecto, desinstalar elimina tanto los recursos del release como su historial. --keep-history elimina los recursos pero conserva el registro del release, de modo que helm history web y helm rollback siguen funcionando después, por si necesitas restablecerlo o simplemente quieres un rastro de auditoría de lo que solía ejecutarse. helm list no mostrará un release desinstalado incluso con --keep-history a menos que añadas -a/--all.

Qué cambió en Helm 4

Si usas Helm 4, ten en cuenta una diferencia de comportamiento: las instalaciones nuevas usan por defecto el server-side apply de Kubernetes en lugar del client-side apply que usaba Helm 3, que gestiona de forma más predecible la propiedad de campos y los conflictos entre herramientas. Las actualizaciones y rollbacks de un release creado con Helm 3 siguen usando client-side apply a menos que pases --server-side explícitamente, de modo que los flujos de trabajo con versiones mixtas no cambiarán de comportamiento de repente por debajo. Esto no cambia ninguno de los comandos anteriores, solo cómo se aplica el manifiesto resultante.