Soc Òscar Mas i en aquest article us vull explicar una problemàtica que existeix amb Helm. Pel que no ho sàpiga, Helm és el sistema d'empaquetatge d'aplicacions més utilitzat en Kubernetes.
Què és Helm i per què és tan important a Kubernetes?
Hem de donar gràcies a la comunitat i a empreses com Red Hat que van impulsar el projecte. En el seu moment, Red Hat volia integrar Helm dins del seu sistema OpenShift i el gran canvi que es va fer es la transició de Helm 2 a Helm 3: es va eliminar per fi el polèmic component Tiller (que corria com a root), es va començar a fer servir el model de seguretat basat en RBAC, i es van polir molts altres detalls.
A partir d'aquest punt Helm era perfecte, però es va començar a fer servir els CRD's i Helm ara com ara no està a l'altura. A part dels CRD's queden molts temes a polir.
El problema dels CRD's
Quan una persona fa un CRD, té diverses possibilitats de posar aquests CRD's dintre del Helm que està construint i en funció d'on els ha posat, hem de treballar d'una manera o altra.
Helm ubicats a la carpeta "/crds"
Si la persona que ha fet el Helm, posa el CRD's en la carpeta "/crds", hem de tenir en compte els següents punts:
- EL CRD s'instal·larà automàticament abans que qualsevol altra cosa
- En actualitzar el Helm, no modificarà els CRD's per por de trencar recursos existents. Això vol dir que actualitzarem el Helm, però no els CRD's i ens podem trobar amb CRD's obsolets.
- Si desinstal·les el Helm del teu clúster, els CRD's quedaran orfes dintre del clúster
- Helm te una comanda per obviar aquesta carpeta i no instal·lar els CRD's: "--skip-crds"
Aquest sistema és molt utilitzat en entorns de producció.
Helm ubicats a la carpeta "/templates"
Si la persona que ha fet el Helm, posa el CRD's en la carpeta "/templates", hem de tenir en compte els següents punts:
- Els CRD's s'instal·len com si fos qualsevol altre tipus d'objecte
- En actualitzar el Helm, actualitzarà els CRD's com si fos qualsevol altre tipus d'objecte
- No es pot fer lògica com per exemple: "{{ if .Values.enabled }}"
- Si fem un Helm rollback, posarà els CRD's a l'estat anterior, ja que els tracta com si fos qualsevol altre tipus d'objecte.
- Si desinstal·les el Helm, eliminaràs tots els CRD's
Aquest sistema és molt utilitzat en entorns de desenvolupament.
Situacions habituals amb Helm i CRDs
A part de tenir clar on estan ubicats els CRD's en el Helm, hem de tenir en compte els següents punts:
- Ens podem trobar en el cas, que la persona que ha fet el helm, no els ha posat ni en la carpeta "/crds" ni en la carpeta "/templates". El que ha fet és un Helm per l'aplicació (recursos/manifests) i un altre Helms pels CRD's
- Ens podem trobar que el Helm que estem instal·lant en el nostre clúster de Kubernetes, no inclogui determinats CRD's per no "embrutar" el clúster i a conseqüència d'això, hi ha cops que primer s'han d'instal·lar els CRD's via "kubectl apply" i després instal·lar el Helm. Eines com Cilium o Istio, ens aconsellen primer instal·lar els CRD's abans que el Helm.
- CRD's compartits: Si desinstal·lem un Helm de l'"Eina A" i aquesta tenia els CRD's en la carpeta "/templates", com hem comentat abans, eliminarà tots els CRD's del nostre cluster i pot arribar a trencar l'"Eina B", que feina servir CRD's de l'"Eina A". Això es diu: Helms anidats
- Ens podem trobar amb la situació en què ja tenim un Helm instal·lat al nostre cluster de Kuberetes i, en voler habilitar una nova opció (la qual requereix crear un nou CRD ), al actuloitzar el helm, el procés falla. Per solucionar-ho, ens veiem obligats a desinstal·lar completament el Helm (helm uninstall) i a tornar-la a instal·lar de zero. El motiu és: Helm no actualitza ni afegeix CRDs durant un helm upgrade; només els instal·la la primera vegada (helm install).
- Ens podem trobar amb situacions totalment il·lògiques que ens tornen bojos. Un exemple perfecte és el de Grafana Operator. Imagina que utilitzes la versió 5.2.2 (sense "v" minúscula) de l'aplicació. Lògicament, esperaries que les definicions dels teus recursos (CRDs) fessin servir la mateixa nomenclatura. Doncs bé, et trobes que el CRD dins del clúster s'ha registrat amb el nom v5.2.2 (amb la "v" minúscula inicial).
- A Kubernetes, els CRD's acostumen a passar de v1alpha1 (experimental) a v1beta1 (bastant estable) i, finalment, a v1 (estable i definitiva). El problema arriba quan una eina (com el Cert-Manager, Prometheus o Traefik) evoluciona i decideix que el seu CRD's passa de Beta (v1beta1) a Estable (v1). Has de canviar tots els teus recursos, encara que hi ha cops que ho fa ella sola.
- Ens podem trobar CRD's que treballes unica i exclusivament en un sol NS (entorn aïllat) i ens podem trobar CRD's que només funcionen a nivell de Cluster (global).
- Si elimines un CRD i tens recursos amb el "finalizer", es poden quedar en l'estat "Terminating" de per vida, fins que et connectes al clúster i ho soluciones.
Bones pràctiques per treballar amb Helm i CRDs
Després de veure tots aquests casos, és important revisar sempre com gestiona els CRD's el Helm que instal·larem, entendre si els recursos es despleguen des de la carpeta /crds o /templates, i validar els canvis abans d'executar un helm upgrade en entorns de producció. També és recomanable documentar les dependències entre aplicacions que comparteixen CRD's i verificar les notes de versió abans de qualsevol actualització important.
Espero que aquest article us hagi servit d'ajuda i si més no, us hagi estat útil.