Soy Òscar Mas y en este artículo os quiero explicar una problemática que existe con Helm. Para quien no lo sepa, Helm es el sistema de empaquetado de aplicaciones más utilizado en Kubernetes.
¿Qué es Helm y por qué es tan importante en Kubernetes?
Tenemos que dar las gracias a la comunidad y a empresas como Red Hat que impulsaron el proyecto. En su momento, Red Hat quería integrar Helm dentro de su sistema OpenShift y el gran cambio que se realizó fue la transición de Helm 2 a Helm 3: se eliminó por fin el polémico componente Tiller (que corría como root), se empezó a utilizar el modelo de seguridad basado en RBAC, y se pulieron muchos otros detalles.
A partir de este punto Helm era perfecto, pero se empezó a utilizar los CRD's y Helm a día de hoy no está a la altura. Aparte de los CRD's quedan muchos temas por pulir.
El problema de los CRD's
Cuando una persona crea un CRD, tiene varias posibilidades de colocar estos CRD's dentro del Helm que está construyendo y en función de dónde los haya colocado, tenemos que trabajar de una forma u otra.
Helm ubicados en la carpeta "/crds"
Si la persona que ha creado el Helm coloca los CRD's en la carpeta "/crds", debemos tener en cuenta los siguientes puntos:
- EL CRD se instalará automáticamente antes que cualquier otra cosa.
- Al actualizar el Helm, no modificará los CRD's por miedo a romper recursos existentes. Esto quiere decir que actualizaremos el Helm, pero no los CRD's y nos podemos encontrar con CRD's obsoletos.
- Si desinstalas el Helm de tu clúster, los CRD's quedarán huérfanos dentro del clúster.
- Helm tiene un comando para omitir esta carpeta y no instalar los CRD's: "--skip-crds"
Este sistema es muy utilizado en entornos de producción.
Helm ubicados en la carpeta "/templates"
Si la persona que ha creado el Helm coloca los CRD's en la carpeta "/templates", debemos tener en cuenta los siguientes puntos:
- Los CRD's se instalan como si fueran cualquier otro tipo de objeto.
- Al actualizar el Helm, actualizará los CRD's como si fueran cualquier otro tipo de objeto.
- No se puede hacer lógica como por ejemplo: "{{ if .Values.enabled }}"
- Si hacemos un Helm rollback, pondrá los CRD's en el estado anterior, ya que los trata como si fueran cualquier otro tipo de objeto.
- Si desinstalas el Helm, eliminarás todos los CRD's.
Este sistema es muy utilizado en entornos de desarrollo.
Situaciones habituales con Helm y CRDs
Aparte de tener claro dónde están ubicados los CRD's en el Helm, debemos tener en cuenta los siguientes puntos:
- Nos podemos encontrar con el caso de que la persona que ha creado el Helm no los haya puesto ni en la carpeta "/crds" ni en la carpeta "/templates". Lo que ha hecho es un Helm para la aplicación (recursos/manifests) y otro Helm para los CRD's.
- Nos podemos encontrar que el Helm que estamos instalando en nuestro clúster de Kubernetes no incluya determinados CRD's para no "ensuciar" el clúster y como consecuencia de ello, hay ocasiones en las que primero se tienen que instalar los CRD's vía "kubectl apply" y después instalar el Helm. Herramientas como Cilium o Istio nos aconsejan primero instalar los CRD's antes que el Helm.
- CRD's compartidos: Si desinstalamos un Helm de la "Herramienta A" y esta tenía los CRD's en la carpeta "/templates", como hemos comentado antes, eliminará todos los CRD's de nuestro clúster y puede llegar a romper la "Herramienta B", que utilizaba CRD's de la "Herramienta A". Esto se llama: Helms anidats.
- Nos podemos encontrar con la situación en la que ya tenemos un Helm instalado en nuestro clúster de Kubernetes y, al querer habilitar una nueva opción (la cual requiere crear un nuevo CRD), al actualizar el Helm, el proceso falla. Para solucionarlo, nos vemos obligados a desinstalar completamente el Helm (helm uninstall) y volver a instalarlo desde cero. El motivo es: Helm no actualiza ni añade CRDs durante un helm upgrade; únicamente los instala la primera vez (helm install).
- Nos podemos encontrar con situaciones totalmente ilógicas que nos vuelven locos. Un ejemplo perfecto es el de Grafana Operator. Imagina que utilizas la versión 5.2.2 (sin "v" minúscula) de la aplicación. Lógicamente, esperarías que las definiciones de tus recursos (CRDs) utilizaran la misma nomenclatura. Pues bien, te encuentras con que el CRD dentro del clúster se ha registrado con el nombre v5.2.2 (con la "v" minúscula inicial).
- En Kubernetes, los CRD's suelen pasar de v1alpha1 (experimental) a v1beta1 (bastante estable) y, finalmente, a v1 (estable y definitiva). El problema llega cuando una herramienta (como Cert-Manager, Prometheus o Traefik) evoluciona y decide que su CRD pasa de Beta (v1beta1) a Estable (v1). Tienes que cambiar todos tus recursos, aunque hay ocasiones en las que ella sola lo hace.
- Nos podemos encontrar CRD's que trabajan única y exclusivamente en un solo NS (entorno aislado) y nos podemos encontrar CRD's que solo funcionan a nivel de Cluster (global).
- Si eliminas un CRD y tienes recursos con el "finalizer", pueden quedarse en estado "Terminating" para siempre, hasta que te conectes al clúster y lo soluciones.
Buenas prácticas para trabajar con Helm y CRDs
Después de ver todos estos casos, es importante revisar siempre cómo gestiona los CRD's el Helm que vamos a instalar, entender si los recursos se despliegan desde la carpeta /crds o /templates, y validar los cambios antes de ejecutar un helm upgrade en entornos de producción. También es recomendable documentar las dependencias entre aplicaciones que comparten CRD's y verificar las notas de versión antes de cualquier actualización importante.
Espero que este artículo os haya servido de ayuda y, como mínimo, os haya resultado útil.