Kustomize et Helm : quelle différence ?

En ce qui concerne la gestion et le déploiement des applications Kubernetes, deux outils se démarquent systématiquement : Kustomize et Helm. Si les deux simplifient les déploiements Kubernetes, ils adoptent des approches fondamentalement différentes pour relever le même défi.

Helm est un gestionnaire de paquets pour Kubernetes. Il regroupe tout ce dont l’application a besoin dans un paquet unique et réutilisable appelé « chart » Helm. Kustomize, outil natif de Kubernetes, adopte une approche déclarative qui consiste à utiliser les correctifs et les superpositions pour modifier les configurations de base requérant un langage de modélisation.

Le choix entre ces outils est bien plus qu’une préférence technique car il affecte directement la productivité de l’équipe de développement, les coûts opérationnels et la fiabilité du dimensionnement d’application. Si associer les deux outils profite à de nombreuses entreprises, il est essentiel de savoir quand et pourquoi choisir chacune des approches. Cela vous permettra d’élaborer une stratégie de déploiement et de gestion Kubernetes efficace et évolutive.

Avant de découvrir Kustomize et Helm, il est utile de comprendre la notion de conteneurisation, qui est la base des applications cloud natives modernes.

La conteneurisation dote les applications de tout ce qui est nécessaire à leur exécution (code, bibliothèques et configuration). Ces éléments sont regroupés dans des unités légères et portables appelées conteneurs, qui s’exécutent généralement sur des systèmes basés sur Linux. Ce processus assure la cohérence des logiciels dans divers environnements, des ordinateurs portables utilisés par les développeurs à l’infrastructure cloud de production.

Kubernetes, également connu sous le nom de k8s ou kube, assure l’orchestration des conteneurs (généralement basés sur Docker) à l’échelle. Pour ce faire, il automatise le déploiement, la mise à l’échelle et la gestion des ressources à travers les clusters de machines.

Selon une étude menée en 2024 par la Cloud Native Computing Foundation (CNCF), l’adoption du cloud natif a atteint un niveau record de 89 % au sein des entreprises interrogées, et 93 % d’entre elles utilisent, essaient ou s’intéressent à Kubernetes.¹

Au fur et à mesure que les entreprises délaissent les applications simples au profit des architectures multiservices complexes, les fichiers de configuration requis pour gérer les déploiements Kubernetes gagnent en complexité. Une application d’entreprise classique peut exiger des dizaines de fichiers de configuration, chacun à personnaliser pour s’adapter à différents environnements : développement, mise en scène et production.

 Cette complexité engendre plusieurs défis métier :

• Difficulté à assurer la cohérence des environnements

• Dépenses opérationnelles plus importantes

• Déploiement non automatisé, qui entraîne des erreurs manuelles

• Délai de mise sur le marché plus long pour les nouvelles fonctionnalités

Kustomize et Helm ont tous deux été créés pour relever ces défis, mais ils adoptent des approches très différentes. Helm est entré en premier sur le marché. Lancé par Deis (entreprise rachetée ultérieurement par Microsoft), c’était l’un des premiers outils conçus pour simplifier la gestion des applications Kubernetes. Le projet a vu sa crédibilité grimper lorsque Deis en a fait don à la CNCF en 2018, et sa phase de maturation s’est achevée en 2020.

Parallèlement, Kubernetes a fait le choix d’intégrer Kustomize directement dans l’interface de ligne de commande (CLI) kubectl, avec la sortie de Kubernetes 1.14 en 2019.

Kustomize adopte une approche déclarative de la gestion des configurations. Au lieu de détailler dans des scripts la manière d’atteindre l’état souhaité, les équipes DevOps et autres décrivent la configuration finale qu’ils cherchent à obtenir. 

L’outil s’appuie sur une méthode de type « base et superposition ». Les équipes mettent en place une configuration de base standard, qui reprend les principales caractéristiques de leur application. Ensuite, pour chaque environnement ou variante, elles créent des superpositions qui spécifient uniquement les différences nécessaires au contexte donné.

Prenons l’exemple d’une configuration de base qui définit une application Web avec des exigences standard en matière de ressources et une configuration réseau de base. Une superposition de développement permettra de réduire les limites de ressources, ainsi que la duplication pour faire diminuer les coûts, tandis qu'une superposition de production pourra améliorer les paramètres de sécurité et ajouter des composants de surveillance. Kustomize fusionne ces configurations pour produire des manifestes Kubernetes à des fins de déploiement (fichiers YAML ou JSON), qui décrivent l’état souhaité des ressources Kubernetes.

Kustomize fonctionne directement avec les fichiers manifestes YAML natifs (comme déploiement.yaml), qui contiennent des champs Kubernetes standard comme apiVersion. Cette approche élimine la nécessité d’utiliser un langage de modélisation et facilite donc l’adoption, puisque les équipes n’ont plus besoin d’apprendre une syntaxe de codage en plus des configurations YAML standard de Kustomize. Par conséquent, elles peuvent rapidement mettre en œuvre une gestion de configuration avancée, tout en utilisant la syntaxe YAML Kubernetes qu’elles connaissent déjà.

Helm, le gestionnaire de paquets Kubernetes le plus utilisé, fait office de magasin d’applications Kubernetes, qui facilite la gestion et l’installation des applications préconfigurées. Selon plusieurs études récentes réalisées par la CNCF, Helm est le gestionnaire de paquets Kubernetes préféré, avec un taux d’adoption de 75 % parmi les entreprises qui utilisent Kubernetes.²

Helm regroupe les applications dans des « charts Helm », à savoir des collections de ressources Kubernetes préconfigurées que les équipes peuvent installer, mettre à niveau et gérer en tant qu’unité unique. Chaque chart comprend des fichiers de configuration (comme chart.yaml) et s’appuie sur des templates Go pour permettre une configuration dynamique, basée sur des valeurs d’entrée.

L’avantage de Helm réside dans son moteur de templates et ses capacités de gestion de paquets. Au lieu de gérer plusieurs versions de configurations similaires, Helm permet aux équipes de créer des charts avec des espaces réservés et d’utiliser des fichiers de valeurs distincts (comme values.yaml) pour remplir ces espaces réservés pendant le déploiement. Les équipes peuvent utiliser le template helm pour prévisualiser la configuration finale avant de l'appliquer au cluster Kubernetes.  

Outre les templates, Helm propose des fonctionnalités complètes de gestion du cycle de vie, notamment la possibilité d’annuler les déploiements, de suivre l’historique de ces derniers et de gérer les versions. Ces capacités font de Helm un outil précieux pour les entreprises disposant de portefeuilles d’application complexes et pour lesquelles les fonctions d’orchestration et d’annulation s’avèrent donc indispensables.

Par exemple, une entreprise de commerce électronique peut utiliser un chart pour sa boutique en ligne et le personnaliser pour ses différents environnements (moins de serveurs pour les tests, plus de serveurs pour la production), le tout sans créer de fichiers de configuration distincts.

Pour déployer ces charts, les équipes utilisent la commande helm install, qui applique automatiquement toutes les ressources au cluster cible par le biais de l’interface de programmation d’application (API) Kubernetes. Helm gère automatiquement les versions et les dépendances pour garantir la cohérence et la fiabilité des déploiements.

Le choix entre Kustomize et Helm dépend des défis en matière de déploiement et des objectifs de chaque entreprise. En général, Kustomize profite le plus aux entreprises qui personnalisent la même application pour l’adapter à différents environnements. Helm convient davantage à celles qui gèrent plusieurs applications ou qui ont besoin de contrôles de déploiement avancés.

La section suivante détaille les cas d’utilisation de chaque solution.

La plupart des entreprises déploient la même application dans leurs environnements de développement, de mise en scène et de production, avec des différences subtiles mais non moins importantes. Kustomize est parfaitement adapté à ce scénario puisqu’il permet aux équipes de conserver une source d’information unique, tout en appliquant des modifications spécifiques à chaque environnement.

Les environnements de développement peuvent exiger une réduction des limites de ressources pour faire diminuer les coûts, tandis que les environnements de production requièrent des paramètres de sécurité améliorés, des ConfigMaps différentes et des composants de surveillance. Kustomize permet aux entreprises de définir ces différences sans dupliquer des fichiers de configuration entiers.

Chaque déploiement exige généralement ses propres politiques de sécurité ou mesures de conformité. Kustomize permet aux équipes de superposer ces exigences aux configurations de base, et ce sans avoir à créer des jeux de configurations complètement différents. Cette fonctionnalité s’avère particulièrement utile aux entreprises présentes dans plusieurs régions ou secteurs, dont les exigences réglementaires varient.

Lors du déploiement des changements de configuration dans un vaste portefeuille d’applications, Kustomize permet aux équipes d’apporter des modifications incrémentielles sans perturber l’ensemble de la structure de configuration. Cette approche réduit les risques et facilite l’identification et la résolution de problèmes tels que les erreurs de configuration et les échecs de déploiement.

L’un des principaux avantages de Helm réside dans ses capacités de création de paquets, particulièrement utiles aux entreprises qui créent des plateformes ou qui cherchent à standardiser le déploiement d’applications.

Les équipes peuvent créer des graphiques réutilisables, qui illustrent les bonnes pratiques et les normes de l’entreprise, puis les distribuer au sein de cette dernière.

Les applications exigeant une orchestration des déploiements avancée (par exemple, rollouts multi-étapes, gestion des dépendances et capacités d’annulation), sont bien adaptées aux fonctionnalités de gestion de version de Helm. En cas de problème, Helm peut revenir instantanément à la version précédente, ce qui réduit l’impact sur les utilisateurs.

Pour faciliter l’intégration des applications open source ou des solutions fournisseurs les plus connues, le vaste référentiel de charts Helm fournit des paquets prédéfinis qui permettent d’accélérer considérablement la mise en œuvre.

Au lieu de créer des configurations en partant de zéro, les équipes peuvent tirer parti des charts gérés par la communauté pour leurs bases de données, systèmes de surveillance, pipelines d’intégration ou de livraison continues (CI/CD) et autres composants classiques de l’infrastructure informatique.

Les plateformes SaaS s’appuient souvent sur Helm pour gérer les déploiements d’applications spécifiques à chaque client. La même application est déployée plusieurs fois, avec des configurations différentes dans des espaces de noms distincts. Cette approche fournit le degré d’isolation et de personnalisation nécessaire aux architectures multilocataire.

Kustomize offre plusieurs avantages pour la gestion des configurations Kubernetes :

Les entreprises choisissent Helm pour les avantages suivants.

Au lieu de voir en Kustomize et Helm deux solutions concurrentes, de nombreuses entreprises font le choix gagnant de les associer. Cette approche hybride exploite les points forts de chaque outil, tout en atténuant ses limites.

Voici quelques cas d’utilisation courants :

• Déploiement initial et personnalisation de l’environnement

• Applications tierces avec configurations personnalisées

• Environnements multi-équipes

Un schéma d’utilisation conjointe classique consiste à mettre en œuvre Helm pour l’empaquetage et le déploiement initiaux de l’application, puis à s’appuyer sur Kustomize pour personnaliser chaque environnement. Cette approche permet de bénéficier des capacités de gestion des paquets et de publication de Helm, tout en préservant la simplicité et la transparence qu’offre Kustomize pour assurer la gestion continue des configurations.

Par exemple, les entreprises peuvent choisir d’utiliser un chart Helm pour déployer une application de microservices avec toutes ses dépendances. L’étape suivante consiste à utiliser les superpositions Kustomize pour ajouter des politiques de sécurité en production ou configurer différentes règles Ingress dans Kubernetes pour assurer la mise en scène.

Les entreprises utilisent souvent Helm pour déployer des applications tierces à partir de son riche référentiel de charts, et choisissent Kustomize pour les applications personnalisées, dont elles veulent pouvoir contrôler davantage la configuration.

Cette combinaison permet aux équipes d’utiliser les charts gérés par la communauté pour les outils courants, comme les systèmes de surveillance et les files d’attente de messages, tout en conservant un contrôle total sur leurs applications propriétaires.

Au sein des grandes entreprises disposant de plusieurs équipes de développement, les équipes chargées des plateformes créent des charts Helm standardisés, qui comprennent bonnes pratiques et exigences de conformité. Ces charts sont associés à des outils d’infrastructure en tant que code (IaC), comme Terraform, pour gérer l’ensemble du pipeline de déploiement.

Les différentes équipes de développement utilisent ensuite Kustomize pour personnaliser ces charts en fonction de leurs applications et environnements respectifs, sans modifier les charts de base. Cette approche permet une séparation nette, qui s’intègre parfaitement aux outils GitOps comme ArgoCD pour gérer les workflows de déploiement automatisés.

Une gestion efficace des configurations Kubernetes exige une stratégie flexible, qui s’adapte à l’évolution des besoins applicatifs.

Comprendre les différences entre Helm et Kustomize, et savoir les intégrer efficacement, permet de réduire la complexité et de garantir la cohérence. Cette alliance stratégique permet au final d’obtenir des environnements Kubernetes plus faciles à gérer et plus évolutifs.