Índice de contenidos
- 1. Introducción
- 2. Resumen de cambios
- 3. Requisitos previos
- 4. Migración con Helm 2to3
- 5. Conclusión
1. Introducción
Cuando escribí el anterior tutorial sobre Helm, prometí escribir uno sobre la migración de Helm 2 a Helm 3 para explicar cómo hacer la migración fácilmente. Estamos en noviembre de 2020 y Helm 2 ha dejado de tener soporte, está marcado como obsoleto (deprecated). Se recomienda actualizar a Helm 3 todos los clusters que lo usen.
Normalmente, cuando se habla de una migración, a la persona encargada de hacerla le entran sudores fríos porque no quiere romper lo que ya está funcionando en la versión antigua al pasar a la versión actual. Se suele retrasar la migración lo máximo posible o buscar otros métodos para hacerlo con total seguridad de no romper nada en el proceso. Por suerte, la comunidad de Helm ha pensado en ello y creó un plugin para Helm llamado helm 2to3 para que sea fácil la migración de Helm 2 a Helm 3.
Gracias a este plugin, con solo ejecutar unos comandos podemos migrar fácilmente de Helm 2 a Helm 3 sin caídas de servicio y en menos de una hora.
2. Resumen de cambios
Vamos a comentar los cambios más importantes de Helm 2 a 3 que cualquier usuario que realice la migración deba conocer:
2.1. Desaparece Tiller (se simplifica el funcionamiento de helm)
- Antes Tiller se encargaba de gestionar toda la información, estado y versionado de cada despliegue y hacer los despliegues contra la API de Kubernetes. Según k8s ha ido evolucionando ha causado problemas porque algunas de las nuevas características de Kubernetes como el manejo de la seguridad RBAC no se llevaban bien con Tiller, haciendo que la comunidad pidiera que se eliminara Tiller.
- Ahora la arquitectura de Helm pasa de ser cliente (Helm) / servidor (Tiller) a solo cliente (el binario de Helm) que se comunica a través de una librería con k8s para hacer los despliegues.
- La seguridad ahora es por usuario (se delega la seguridad a los usuarios de Kubernetes).
- Las versiones y los metadatos que cambian de la versión del cluster ahora se almacenan como secretos dentro del clúster. Las versiones se conservan según el namespace de las versiones y ya no están en el namespace donde esta Tiller.
2.2. Nuevos charts para Helm 3
- Los nuevos charts pensados para desplegar con Helm 3 tendrán el valor de la propiedad apiVersion «v2» y los charts de Helm 2 (apiVersion = v1) se pueden instalar en Helm 3, los v2 no se pueden desplegar con Helm 2.
- Estos nuevos charts tendrán las dependencias en el fichero Chart.yaml en vez en el fichero requirements.yaml, que desaparece.
- Los charts de librería (charts comunes o de ayuda) ahora se pueden agregar como dependencias vinculados dinámicamente.
2.3. Otros cambios
- El comando helm search ahora admite tanto búsquedas en repositorios locales como realizar consultas de búsqueda en Artifact Hub.
- Al no haber Tiller, se simplifica el comando de instalación y actualización de charts y hay menos errores al desplegar (antes Tiller tenía que estar operativo en el cluster para poder desplegar, si no funcionaba no se podía hacer nada).
- Se deja de añadir por defecto los repositorios local o stable, ya que también se han marcado como obsoletos (deprecated).
2.4. Cambios de comandos
- helm delete –purge —-> helm uninstall (se elimina el historial de despliegues).
- helm fetch —-> helm pull.
- helm inspect —–> helm show.
- Al no haber Tiller, ya no hacen falta los siguientes comandos, que se han eliminado: helm init, helm reset, helm serve, helm home.
- helm install pide el nombre del release, igualando el comportamiento de helm upgrade.
- helm upgrade permite añadirle el argumento –history-max para limitar el número máximo de revisiones de cada despliegue.
Si se quiere saber sobre el resto de cambios o más en detalle, se puede consultar aquí.
Importante: si se está usando Helm 2 en un pipeline de integración continua se estará usando el comando helm init –client-only en él. Con la migración el comando helm init desaparece, ya no hace falta para que Helm 3 funcione, con lo que solo hay que borrar el comando y dejar el resto de la integración continua que use Helm igual.
3. Requisitos previos
Partimos de que Helm 2 ya lo tienes, puesto que vamos a migrar de ahí a Helm 3. Recomiendo tener instalado tanto Helm 2 como Helm 3 para manejar el cluster de K8s con Helm en todo el proceso.
Si no sabes la versión de Helm que tienes instalada actualmente, ejecuta:
helm version
Podemos instalar Helm 3 de varias formas:
- Si usas Homebrew en la sección 4.1 Instalando Helm de mi anterior tutorial Desplegar aplicaciones en Kubernetes con Helm lo explico.
- Si no tienes Homebrew, puedes descargarlo directamente de los releases de Helm.
Al instalar Helm 3, tendrás Helm 2 y Helm 3 instalados en el ordenador y puede causar problemas puesto que los binarios tienen el mismo nombre. Para poder utilizar los comandos de ambas versiones, hay que renombrar el binario de una de las dos versiones y guardar el cambio en el path.
En mi caso, como Helm 2 lo voy a dejar de usar y uso Helm 3 a partir de ahora, renombre el binario de Helm 2 de helm a helm2 y lo añadí al path, ya que la referencia de Helm en el path era Helm 3 por ser la última que había instalado. Al tener los 2 binarios en el path, los podremos usar sin problemas.
Un ejemplo de cómo hacer este proceso sería editar el fichero .bash_profile (si usamos bash como terminal) o el fichero .zshrc (si usamos zsh como terminal) y añadir la siguiente línea: export PATH=$PATH:/usr/local/opt/helm@2/bin (sustituir helm@2 y la ruta previa por la ruta/carpeta donde esté la versión 2 de Helm si es distinto). El binario de helm 3 se queda con el nombre de helm tal y como se instaló.
A partir de ahora todos los comandos que empiecen por helm …. usarán Helm 3 y los que empiecen por helm2 …. usarán Helm 2.
4. Migración con Helm 2to3
AVISO: De aquí en adelante cuando aparezca helm, será un comando de Helm 3 y cuando aparezca helm2 será un comando de Helm 2. Si en vuestro caso los nombres de los binarios son distintos, cambiad el comando correspondiente.
El plugin Helm 2to3 para Helm3 se encargará de migrar la configuración, despliegues y borrar toda la configuración, datos de despliegues y demás información solo útil para Helm 2, además de Tiller.
Es muy importante que no se borre sin usar el plugin después de empezar la migración, puesto que podría dejar el cluster en un estado inestable que impida realizar la migración.
4.1. Backup configuración Helm 2
Antes de empezar y para poder volver atrás en caso de necesidad, haremos una copia de seguridad de la configuración de Helm 2 usando el plugin Helm Backup.
Para ello instalamos el plugin ejecutando:
helm2 plugin install https://github.com/maorfr/helm-backup
Con esta herramienta hay que hacer backups de todos los namespaces que haya en el cluster ejecutando el comando:
helm2 backup “nombre namespace” (sustituirlo por el nombre real del namespace)
Para ver todos los namespaces que hay en el cluster de k8s, ejecutad:
kubectl get namespaces
Aviso: Podría darse el caso de que al ejecutar cualquier comando de Helm 2 devuelve un error porque la versión de Helm 2 que tengas instalada sea superior a la versión del servidor (la de Tiller), este problema se soluciona actualizando la versión de Tiller a la que tengas con el comando:
helm2 init --upgrade
Si queremos restaurar alguno de los backups, solo tendríamos que ejecutar con cada namespace a restaurar:
helm2 backup “nombre namespace” --restore
4.2. Instalación Helm 2to3
Una vez hechas todas las copias de seguridad procedemos a instalar en Helm 3 el plugin Helm 2to3 (no lo instaleis en Helm 2):
helm plugin install https://github.com/helm/helm-2to3.git
Si antes de ejecutar cualquier comando de Helm 2to3 queremos antes ver el resultado de ejecución para asegurarnos que todo iría bien, podemos añadir el flag –dry-run.
Para hacer la migración, 2to3 utiliza las carpetas de datos y configuración de Helm 2 predeterminadas. Para sobrescribir la localización de esas carpetas, debe configurar las variables de entorno HELM_V2_HOME, HELM_V3_CONFIG y HELM_V3_DATA apuntando a donde este el home de Helm 2, y las localizaciones donde dejar la configuración y datos de Helm 3. Este paso no es necesario, es una opción de personalización que si no sabéis bien cómo funciona os puede dar problemas en el futuro, recomiendo usar las carpetas por defecto.
4.3. Migración de la configuración
Ejecutamos el comando de migración de la configuración:
helm 2to3 move config
El comando move config creará la configuración y las carpetas de datos de Helm 3 si no existen. El contenido del fichero repositories.yaml se copia a Helm 3. Este fichero contiene referencias a los repositorios agregados en Helm 2. Podemos ver si se han migrado todas las referencias a los repositorios de Helm con el comando:
helm repo list
Los repositorios locales no se copian a Helm 3. Si tienes repositorios locales almacenados en Helm 2 que se hayan podido migrar a Helm 3, hay que eliminarlos de Helm 3 usando:
helm repo remove “nombre repositorio”
Y volver a agregar cuando sea necesario usando:
helm repo add “nombre repositorio”
Esta es una actualización necesaria para alinear las referencias para Helm 3.
Al terminar con la lista de repositorios, actualiza Helm 3 con:
helm repo update
Esto limpia cualquier referencia de caché de Helm 2 en Helm 3.
Hay que verificar que todos los plugins de Helm 2 funcionen bien en Helm 3. Si hay algún problema con un plugin, elimina (helm plugin remove) y vuelve a agregar el plugin (helm plugin install) en Helm 3.
Listamos todos los despliegues actuales de aplicaciones en kubernetes hechos con Helm 2 con el comando:
helm2 list
Veremos una lista como esta:
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION nginx-ingress ingress 1 2020-06-01 13:08:09.84737 +0200 CEST deployed nginx-ingress-1.36.0 0.30.0 nexus cicd 5 2020-06-10 12:18:09.976315 +0200 CEST deployed sonatype-nexus-2.1.0 3.21.2 prometheus-stack monitoring 1 2020-09-28 16:22:49.578139 +0200 CEST deployed kube-prometheus-stack-9.4.1 0.38.1 cluster-autoscaler kube-system 5 2020-09-17 16:49:30.346419 +0200 CEST deployed cluster-autoscaler-chart-1.0.3 1.18.1
Esta lista es necesaria para obtener los nombres de todos los despliegues a migrar.
Hay que usar el campo debajo de name para sustituirlo en el entrecomillado de nombre release del comando 2to3 convert.
4.4. Migración de los despliegues
Ejecutamos el comando de conversión de los despliegues de helm 2 a helm 3 por cada release:
helm 2to3 convert “nombre release”
Importante: Hay que convertir una a una todas las releases que queramos migrar ya desplegadas en Kubernetes. Si no queremos migrar una o varias releases ya que van a ser eliminadas, es mejor borrarlas antes de hacer la migración, para ello hay que ejecutar:
helm2 delete “nombre release” --purge
Todos los despliegues que no se migren o borren se quedarán en el limbo porque habrá desaparecido toda la configuración de Helm 2 que sabía de esos recursos y Helm 3 no los conocerá con lo que no se podrán borrar con comandos de Helm. Es decir, se quedarán los recursos activos y habrá que borrarlos uno a uno con Kubectl en vez de poder cerrarlo de golpe con Helm.
Una vez que se haya completado la migración de todas las releases, hay que proceder a limpiar completamente los recursos de Helm 2. Esta limpieza eliminará toda la configuración de Helm 2 (el fichero home de Helm 2, los datos de despliegue de Helm 2 y Tiller) puesto ya estaría todo migrado a Helm 3.
4.5. Borrado de la configuración de Helm 2
Una vez ejecutado el comando de limpieza se borrarán los datos de despliegue de Helm 2, por lo que la única forma de volver atrás sería restaurando los backups que antes se han hecho. Hasta que no se haya migrado todo de Helm 2 a Helm 3 (con el comando de arriba) no ejecutes el comando puesto que se quedara la migración incompleta y fallaran todos los despliegues que aún no se hayan migrado.
El comando de cleanup usa la carpeta home por defecto de Helm 2.
Si has personalizado la ruta de la carpeta de home de Helm 2, hay que crear la variable de entorno HELM_V2_HOME y apunta con esa variable al path donde este la carpeta home.
Una vez esté todo listo para terminar la migración, ejecutar:
helm 2to3 cleanup
Al terminar este comando de limpieza, los comandos de Helm 2 sobre el cluster migrado dejarán de funcionar y a partir de ese momento ya se ha completado la migración y se puede empezar a usar Helm 3 para manejar el cluster.
5. Conclusión
Como habéis podido comprobar, usando el plugin helm 2to3 la migración es fácil, rápida e indolora, no hay caídas de servicio y de cara al exterior todo funciona igual aunque internamente ahora se maneje con Helm 3 en vez de Helm 2.
Esta migración es importante porque saldremos de una versión obsoleta y volveremos a estar en una versión que tiene soporte, nos beneficiamos de todas las mejoras de rendimiento, estabilidad, parches de seguridad, además de que los futuros despliegues y manejo del cluster con Helm se aprovechara de todas las mejoras futuras.
No hay motivo para alargar más en el tiempo la migración de Helm 2 a Helm 3 y seguir con una versión obsoleta.
Atrévete con ella.
