Aller au contenu principal
TechLedger Registre technique
kubernetesHelmKustomizeGitOpsPackaging

Helm et Kustomize, côte à côte : la même application packagée deux fois

La même application packagée deux fois, avec Kustomize et avec Helm 4. Écrire un Helm chart correct, le tester, le signer et le publier, sur un dépôt HTTP comme sur un registre OCI. Puis les mettre en panne des deux façons : patches qui ne s'appliquent pas, templates qui rendent du YAML faux, releases bloquées, conflits de propriété. Chaque écart entre Helm 3 et Helm 4 est signalé.

coolibra09 sept. 202626 vues

Objectifs

  1. Dire ce que Kustomize et Helm résolvent, et ce qu'aucun des 2 ne résout.
  2. Packager une application réelle avec Kustomize : base, overlays, patches, générateurs.
  3. Lire kustomize build comme la seule source de vérité, et savoir pourquoi un patch ne s'applique pas.
  4. Écrire un Helm chart dans les règles : structure, templates, sous-templates, dépendances, et les fonctions qui évitent le YAML faux.
  5. Rendre un chart utilisable par quelqu'un d'autre : values.schema.json, valeurs documentées, NOTES.txt, et ce qu'un chart ne doit jamais imposer.
  6. Éprouver un chart avant de le publier : helm lint, helm template, les tests de chart, et le rendu comparé entre 2 jeux de valeurs.
  7. Publier un chart : versionner selon SemVer, packager, servir un dépôt HTTP, pousser sur un registre OCI, signer et vérifier la provenance.
  8. Comprendre ce qu'est une release, ce que Helm stocke, et ce que helm upgrade fait vraiment.
  9. Connaître les écarts entre Helm 3 et Helm 4, à commencer par le server-side apply activé par défaut.
  10. Diagnostiquer les pannes propres à chaque outil, sur un cluster, avec leur sortie réelle : release bloquée, hook qui ne finit pas, patch qui ne s'applique pas, conflit de propriété.
  11. Combiner les 2 quand c'est justifié, et savoir quand ce ne l'est pas.
  12. Choisir, et défendre le choix devant une équipe.

Chapitres