Autor | Adrián Rico, Cloud Architect & DevOps Engineer en ACKstorm
Para desplegar aplicaciones en Kubernetes la forma más básica es creando manifiestos con los objetos necesarios, como por ejemplo un deployment con su service. Pero, ¿qué pasa cuando nuestra aplicación requiere de más componentes? Podríamos llegar a la conclusión de que seguir con esta opción sería correcta, y así es , pero con el tiempo se volvería difícil de mantener cuando empecemos a añadir más complejidad, como diferentes entornos, más aplicaciones, etcétera.
Por ello Kubernetes ofrece también de forma nativa una herramienta de despliegue llamada Kustomize, que soluciona muchos problemas que se pueden llegar a encontrar cuando llegamos a la casuística de los entornos. ¿Cuál sería la solución, repetir los manifiestos cambiando parte del contenido de aquellos que sean necesarios?
Es aquí donde Kustomize nos ofrece una herramienta de despliegue que se basa en generar manifiestos para diferentes entornos, utilizando una metodología de merge entre los ficheros.
Tenemos ficheros base, ficheros de overlay donde están los cambios y ficheros de kustomization, donde se define cómo los ficheros de overlay se fusionan con el base.
A continuación vemos una estructura de carpetas y ficheros:
Debemos puntualizar que no vamos a hacer una comparativa entre Kustomize y Helm, aunque de alguna forma va a ser inevitable, ya que ambas son herramientas de despliegue para Kubernetes y son las más utilizadas.
Conociendo la solución de Helm
El proyecto de Helm fue iniciado en 2015 y ha evolucionado mucho durante los últimos años, pasando por sus versiones v1, v2 y la actual v3.
Helm es un administrador de paquetes para Kubernetes opensource. ¿Qué significa esto? Cuando hablamos de esto podemos pensar como referencia en el de cualquier sistema operativo como podría ser APT o YUM pero en nuestro caso para Kubernetes.
El nombre de Helm es un juego de palabras que hace referencia al timón, al igual que Kubernetes hace referencia al timonel, y en su vocabulario los paquetes se llaman Chart.
Los objetivos principales de la creación de Helm fueron los siguientes:
- Facilitar el paso de “from zero to Kubernetes”
- Proveer de un package manager al igual que tienen los sistemas operativos.
- Enfatizar en la seguridad y la configurabilidad de aplicaciones en Kubernetes.
A pesar de que en este último punto se habla sobre configurabilidad, Helm no fue especialmente diseñado para esta misma labor como ya hacen otros softwares tales como Puppet, Chef o Ansible, que se enfocan en cómo un software está específicamente configurado en un host. Y aunque no fue inicialmente diseñado para esta función, muchas empresas lo utilizan con este propósito.
Pese a que cumple con él a grandes rasgos, hay otras herramientas diseñadas específicamente para ello con grandes funcionalidades, como por ejemplo Helmfile, Flux o Reckoner.
Otra de las virtudes de Helm es que automáticamente guarda las diferentes versiones de nuestras releases de las aplicaciones habilitándonos de forma sencilla a volver a una versión anterior en caso de que haya algún problema.
Helm fue aceptado en la Cloud Native Computing Foundation (CNCF) el 1 de junio de 2018 y tiene el rango de Graduado por el nivel de madurez del proyecto.
Tiene más de 23k estrellas en Github y tiene una frecuencia de release de dos semanas.
Pros y contras de Helm
Pros:
- Rapidez de despliegue.
- Reutilización de los paquetes.
- Personalización de configuración durante el despliegue.
- Gran documentación.
Contras:
- Curva de aprendizaje del templating.
- Nuevo binario.
Alternativas existentes a Helm
- Kustomize: https://helm.sh/es/
- Kpt: https://kpt.dev
- kubes: https://kubes.guru
Conclusiones
Helm es una herramienta muy útil y la más utilizada en el sector a la hora de hacer despliegues, ya sea por su sencillez o por las características que tiene.
