Quiz : Helm

Dans des Secrets du namespace de la release (sh.helm.release.v1.<release>.v<révision>), une par révision. Helm n'a pas de serveur : tout passe par vos droits Kubernetes, et ces Secrets contiennent les valeurs utilisées, donc parfois des données sensibles. Leçons 1 et 3.

Non : Helm ne réconcilie pas. Il agit quand on lance une commande, puis plus rien ne surveille le cluster. C'est le rôle du GitOps (Argo CD, Flux). Leçon 1.

Un seul : les maps se fusionnent, les listes se remplacent. C'est une source fréquente de surprises quand on surcharge un chart tiers. Leçon 2.

--set devine les types (une étiquette 1.10 devient un nombre), découpe sur les virgules et les points, et ne laisse aucune trace relisible. Un fichier de valeurs versionné se relit, se rejoue et se compare. Leçon 2.

Il crée une nouvelle révision avec le contenu d'une ancienne : l'historique avance, il ne recule pas. Une migration de base faite par un hook n'est pas défaite. Leçons 3 et 8.

Elles sont oubliées : sans option, un upgrade qui reçoit au moins une valeur repart des défauts du chart. On rejoue toujours la mise à jour avec le même fichier de valeurs ; --reuse-values et --reset-then-reuse-values existent, mais ont leurs propres pièges. Leçon 3.

version est la version du chart (versionnement sémantique, identifie une publication, immuable une fois publiée) ; appVersion est la version de l'application empaquetée. Un changement de modèle change la première sans toucher à la seconde, et inversement. Leçons 4 et 9.

Le sélecteur d'un Deployment est immuable : s'il contenait la version de l'application ou du chart, chaque mise à jour serait refusée. Les étiquettes de sélection sont stables (nom, instance) ; les étiquettes communes portent en plus la version et le chart. Leçons 4 et 6.

Le modèle produit du texte que Helm relit ensuite comme du YAML : une valeur comme yes, 1.10 ou 08 serait interprétée comme un booléen ou un nombre. quote garantit une chaîne. Leçon 5.

lookup lit le cluster pendant le rendu, mais renvoie une map vide avec helm template, que Argo CD utilise. Le chart se comporterait différemment selon l'outil. Leçons 5 et 10.

Rien : la clé inconnue est ignorée en silence, et le chart utilise la valeur par défaut. Un schéma avec additionalProperties: false rejette la clé (en prévoyant global), et valide types et bornes avant le rendu. Leçon 6.

Un sous-chart partage le cycle de vie de son parent : désinstaller ou recréer l'application toucherait la base. Une base, un opérateur ou tout ce qui installe des CRD vit à part (chez Lyneko, PostgreSQL est un service managé). Leçon 7.

La mise à jour échoue et la release est marquée en échec ; avec --atomic (--rollback-on-failure sous Helm 4), Helm revient en arrière sur les objets. Mais ce que la migration a déjà fait dans la base n'est pas défait : d'où des migrations compatibles avec l'ancienne et la nouvelle version de l'application. Leçon 8.

helm package n'est pas reproductible : deux empaquetages du même chart donnent deux empreintes différentes. On empaquette une fois, et c'est ce fichier, identifié par son empreinte, que l'on signe, pousse et référence jusqu'en production. Leçon 9.

Argo CD rend le chart (helm template) et applique lui-même les manifestes : aucune release Helm n'est créée. Le retour arrière est un revert Git de la version du chart ou des valeurs, que Argo CD synchronise. Leçon 10.