Garantir la qualité des Helm Charts

Mon, 11 May 2026 14:00:00 +0000

Introduction

En tant que SRE / Platform Engineer, l’une de mes responsabilités est de fournir des Helm charts fiables aux équipes de développement. Ces charts constituent la fondation du déploiement de leurs applications sur nos plateformes Kubernetes. Un chart défaillant, ce sont des d’applications impactées, des heures d’investigation, et une confiance érodée sur les composants mis à disposition.

Le déclencheur de cette réflexion vient d’un incident évitable, avec l’introduction de breaking changes non documentés qui ont cassé tous les déploiements utilisant ce chart, et nous a forcés à nous poser une question fondamentale : comment garantir la qualité des helm charts que nous fournissons ?

Contexte

Le problème

Gérer des Helm charts manuellement et sans validation automatisée présente plusieurs risques :

Breaking changes non documentés : Des modifications incompatibles peuvent être introduites sans que les équipes utilisatrices en soient informées.
Erreurs de syntaxe : Des fautes de frappe ou des erreurs YAML peuvent passer inaperçues jusqu’au déploiement en production.
Templates invalides : Des templates qui ne se rendent pas correctement ou génèrent des manifestes Kubernetes invalides.
Régression fonctionnelle : Des modifications qui cassent des fonctionnalités existantes sans être détectées.
Absence de traçabilité : Difficulté à comprendre l’historique des changements et leur impact.

L’objectif

J’avais donc besoin d’un cadre capable de valider automatiquement chaque modification avant son intégration dans la branche principale, de signaler explicitement les breaking changes, de vérifier la conformité Kubernetes des manifestes générés de tester les comportements attendus et de tracer les évolutions dans un changelog exploitable.

Mais il ne s’agissait pas seulement d’ajouter des outils. La réponse devait aussi être organisationnelle : mieux cadrer la contribution, rendre la collaboration plus lisible, et faire en sorte que la qualité du chart ne repose plus uniquement sur l’attention individuelle.

Composants

Le workflow s’articule autour de plusieurs outils et pratiques :

GitLab CI/CD : Orchestre l’ensemble du pipeline de validation et de publication.
Helm & Plugins : Gestionnaire de packages pour Kubernetes, avec ses outils natifs de validation et ses plugins.
Git Flow : Stratégie de branches et processus de Merge Request.
SemVer : Gestion des versions pour communiquer clairement les types de changements.
Keep a Changelog : Format standardisé pour documenter tous les changements.

Architecture du Pipeline

Le pipeline GitLab CI est organisé en trois stages principaux, chacun avec un objectif spécifique.

Vue d'ensemble du pipeline

Linting

Le premier niveau de validation dans le pipeline vérifie la syntaxe et la structure globale du chart via la commande helm lint native à helm. Elle permet d’avoir un retour rapide et immédiatement compréhensible, bien qu’elle ne couvre pas tous les cas, elle élimine très tôt les erreurs grossières qui ne devraient jamais atteindre les étapes suivantes et évite donc de lancer des validations plus poussées et donc de perdre du temps.

1

helm lint .

📝 Note

Ce que Helm lint vérifie :

Syntaxe YAML correcte

Structure du chart (Chart.yaml, templates/, etc.)

Problèmes de formatage

Warnings sur les bonnes pratiques

Une fois que l’on s’est assuré de la bonne structure du chart, on peut passer aux étapes de validation plus spécifiques.

Validation du templating

Pour répondre à la question : est-ce que le chart se rend réellement correctement avec les valeurs fournies ? J’ai retenu helm template qui va permettre d’effectuer le rendu des templates, c’est souvent à ce niveau que l’on découvre des variables manquantes, des conditions mal écrites, ou des erreurs dans les fonctions Go Template.

Le fonctionnement est simple : Helm interprète les templates et produit les manifestes Kubernetes finaux, sans les appliquer sur un cluster. On obtient donc une vue concrète de ce qui serait déployé, ce qui en fait une étape particulièrement utile pour détecter les erreurs de rendu au plus tôt.

1

helm template .

📝 Note

Ce que Helm template vérifie :

Rendu correct des templates Go (variables, fonctions, pipelines)

Résolution des valeurs et des helpers définis dans _helpers.tpl

Syntaxe correcte des conditions {{- if }} et des boucles {{- range }}

Absence de variables non définies ou mal référencées

Conformité des schémas

helm template garantit que le rendu fonctionne, mais pas que le résultat soit acceptable pour Kubernetes. C’est précisément pour cette raison que j’ai choisi d’utiliser Kubeconform. Cet outil a été retenu parce qu’il est rapide, simple à intégrer dans une CI, et très efficace pour valider les manifestes contre des schémas connus.

Son principe est de comparer les ressources générées aux schémas Kubernetes attendus. Il ne se contente donc pas de vérifier que le YAML est bien formé : il valide aussi la structure métier du manifeste, les champs autorisés, les types attendus et certaines incompatibilités de version. Avec l’ajout du catalogue de CRDs, il reste utile même dans des environnements Kubernetes enrichis par des opérateurs.

À l’origine, cet outil est un binaire mais un plugin helm a été fait pour pouvoir être intégrer directement dans la CLI de helm.

1
2


helm plugin install https://github.com/jtyr/kubeconform-helm
helm kubeconform .

Configuration de Kubeconform (.kubeconform) :

1
2
3
4
5
6


schema-location:
 - default # Default K8s resources schema
 - https://raw.githubusercontent.com/datreeio/CRDs-catalog/main/{{.Group}}/{{.ResourceKind}}_{{.ResourceAPIVersion}}.json
summary: true
verbose: true
ignore-missing-schemas: true # Don't fail on resources where schema is not found.

📝 Note

Ce que kubeconform vérifie :

Champs invalides ou dépréciés

Types de données incorrects

Valeurs manquantes pour les champs requis

Problèmes de compatibilité avec la version Kubernetes ciblée

Exemple de sortie :

1
2
3
4
5
6
7


stdin - Secret mariadb-cluster is valid
stdin - StatefulSet mariadb-cluster is valid
stdin - Cluster pg-cluster is valid
stdin - MongoDBCommunity mongodb-cluster is valid
...
...
Summary: 17 resources found parsing stdin - Valid: 17, Invalid: 0, Errors: 0, Skipped: 0

Tests unitaires

J’ai ajouté Helm Unittest parce qu’au-delà de la syntaxe et de la conformité, il fallait protéger les comportements fonctionnels du chart. C’est l’outil qui me permet de formaliser des attentes explicites : un nom doit suivre une convention, une ressource doit exister dans un cas donné, une image doit être construite avec telle valeur, etc.

Le principe est proche d’un framework de test classique, mais appliqué au rendu Helm. On décrit un jeu de valeurs d’entrée, puis on exprime des assertions sur le manifeste produit. Cette approche est particulièrement utile pour éviter les régressions silencieuses lorsqu’un chart évolue et commence à gérer plusieurs variantes de configuration.

1
2


helm plugin install https://github.com/helm-unittest/helm-unittest.git
helm unittest .

Les tests unitaires permettent de vérifier les comportements attendus du chart dans différentes configurations.

Exemple de test (tests/deployment_test.yaml) :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


suite: test deployment
templates:
 - deployment.yaml
tests:
 - it: should create a valid deployment
 set:
 image.tag: latest
 asserts:
 - isKind:
 of: Deployment
 - matchRegex:
 path: metadata.name
 pattern: -my-chart$
 - equal:
 path: spec.template.spec.containers[0].image
 value: nginx:latest

📝 Note

Ces tests vérifient :

Les valeurs par défaut produisent des manifestes valides

Les différentes configurations fonctionnent correctement

Les comportements critiques sont préservés (non-régression)

Release Management

La publication n’est déclenchée que lors de la création d’un tag Git sur la branche main. Ce processus garantit que seules les versions taggées sont publiées, permettant d’accumuler plusieurs modifications avant de créer une release.

Point crucial : Le CHANGELOG

Chaque Merge Request doit inclure une mise à jour du CHANGELOG.md. Ce fichier suit le format Keep a Changelog et utilise le Semantic Versioning.

1
2
3
4
5
6
7
8
9


## [1.0.10] - 2026-01-26

### Added
- Resource limits and requests for all containers

### Changed
- Updated default memory limit to 512Mi

[1.0.10]: https://gitlab.com/project/compare/1.0.9...1.0.10

Catégories disponibles :

Added : Nouvelles fonctionnalités
Changed : Modifications dans les fonctionnalités existantes
Fixed : Corrections de bugs
Removed : Fonctionnalités supprimées

📌 Important

Si une modification introduit un breaking change, cela doit être :

Clairement indiqué dans le CHANGELOG

Expliqué dans la description de la Merge Request

Accompagné d’un guide de migration si nécessaire

Semantic Versioning

Nous suivons strictement le Semantic Versioning (MAJOR.MINOR.PATCH) :

MAJOR : Breaking changes (incompatibilité avec les versions précédentes)
MINOR : Nouvelles fonctionnalités rétrocompatibles
PATCH : Corrections de bugs rétrocompatibles

Exemple :

1.0.9 → 1.0.10 : Ajout de resource limits (rétrocompatible) → MINOR
1.0.10 → 2.0.0 : Changement de structure du values.yaml (breaking) → MAJOR

Bénéfices Observés

Depuis la mise en place de ce workflow, on a pu constater :

Qualité

Zéro breaking change non documenté depuis 6 mois
Réduction de 90% des erreurs de déploiement liées aux charts
Détection précoce des problèmes (avant la revue de code)

Collaboration

Processus clair pour tous les contributeurs (juniors et seniors)
Revues de code plus efficaces (focus sur la logique, pas la syntaxe)
Traçabilité complète des changements via le CHANGELOG

Confiance

Les équipes de développement ont confiance dans la stabilité des charts
Les updates sont moins redoutées car le processus est transparent
Les rollbacks sont facilités par le versioning clair

Productivité

Réduction du temps de validation manuelle
Automatisation de tâches répétitives
Focus sur la valeur ajoutée plutôt que sur la vérification de syntaxe

Diagramme de Séquence

Diagramme de séquence complet

Points d’Attention

Quelques leçons apprises lors de la mise en place :

Tests Unitaires Complets

Ne testez pas uniquement les cas nominaux. Incluez :

Les configurations par défaut
Les cas limites
Les différentes combinaisons de valeurs
Les scénarios de mise à jour

Documentation du CHANGELOG

Le CHANGELOG est le contrat avec les utilisateurs. Il doit être :

Complet : Tous les changements doivent être documentés
Clair : Langage compréhensible, pas de jargon technique inutile
Actionnable : Pour les breaking changes, indiquer quoi faire

Protection de la Branche Main

La protection de main doit être stricte :

Pas de commit direct
Pipeline obligatoire
Approbation obligatoire
Le CHANGELOG doit être à jour avant le merge

Tags Protégés

Restreindre la création de tags aux Maintainers pour éviter les publications accidentelles.

Communication

Lors d’un breaking change, même bien documenté :

Notifier les équipes en avance
Fournir un guide de migration
Offrir du support pendant la transition

Améliorations Futures

Nous envisageons d’ajouter :

Tests de non-régression : Comparer les manifestes générés entre versions avec helm diff
Security scanning : Intégrer des outils comme Trivy pour détecter les vulnérabilités
Policy enforcement : Utiliser des tools comme OPA ou Kyverno pour valider les policies de sécurité
Monitoring des déploiements : Suivre l’adoption des nouvelles versions

Conclusion

La mise en place d’un pipeline de validation rigoureux pour nos Helm charts a transformé notre manière de travailler. L’incident qui nous a poussés à implémenter ce workflow est désormais impossible grâce aux multiples niveaux de validation.

Ce processus garantit non seulement la qualité technique des charts, mais établit également un contrat clair avec les équipes de développement : elles peuvent faire confiance aux charts que nous fournissons, et lorsqu’un breaking change est nécessaire, il est clairement documenté et communiqué.

Pour une équipe SRE, fournir une plateforme fiable est primordial. Ce workflow nous permet de tenir cette promesse tout en gardant la capacité d’évoluer et d’améliorer continuellement nos charts.

Si vous gérez des Helm charts pour une plateforme Kubernetes, je vous encourage vivement à mettre en place un processus similaire. L’investissement initial est rapidement rentabilisé par la réduction des incidents et l’amélioration de la collaboration.

Ressources utiles :

GitLab CI on Matteo ZINUTTI