Introduction à Helm avec Kubernetes

Helm (gouvernail en français) est le gestionnaire de packages pour Kubernetes. Il vous aide à piloter Kubernetes à l’aide de cartes de navigation, appelés Charts en anglais.

Le rôle principal de Helm est de permettre de définir, d’installer et de mettre à jour des applications Kubernetes complexes. Helm est maintenu par la CNCF en collaboration avec Microsoft, Google, Bitnami et la communauté Helm.

Découvrez les avantages de Helm, sont fonctionnement et comment créer des Charts dans cet article.

1. Quels sont les avantages de l’utilisation de Helm avec Kubernetes ?

Helm nous permet de créer un Framework pour des micro services clairement définis. Il gère les besoins d’évolutivité (scalability), facilite l’ajout de nœuds et pods au cluster Kubernetes en fonction des besoins. Au lieu de travailler avec une image holistique et d’augmenter les ressources, vous exécutez uniquement un ensemble d’images nécessaire et vous les faites évoluer indépendamment.

Les bénéfices de Helm sont : 

• Déploiement plus rapide : en exécutant simplement une commande Helm, vous pouvez effectuer les opérations suivantes sur un Chart : installer, mettre à jour, désinstaller, revenir à une autre version, lister tous les Charts déployés. Helm fait le nécessaire en contactant l’API de Kubernetes, vous évitant ainsi d’avoir à entrer dans les détails techniques.
• Pour déployer des applications dans Kubernetes avec Helm il existe le concept de Chart. L’utilisation des charts Helm officiels vous garantira le bon fonctionnement de votre déploiement, sans pour autant avoir besoin de revenir sur les différents paramètres de configuration.  Cela ne signifie pas pour autant qu’il n’est pas possible de modifier les différents paramètres de votre déploiement. Une lecture attentive de la documentation associée au Chart vous permettra d’adapter les différents paramètres à vos besoins si nécessaire.
• Il existe des centaines de packages disponibles dans son dépôt officiel, prêts à être installés sur votre cluster avec une seule commande.
• Ces packages sont entièrement personnalisables, afin de pouvoir les adapter à votre environnement, aux particularités de votre cluster ou à votre cas d’utilisation.
• Il y’a de plus en plus de créateurs de contenu original. Parmi eux, nous notons la présence de fournisseur officiel provenant d’entreprise fournissant : des services de base de données, des serveurs web, des outils Devops, etc. Cette grande diversité et cette participation officielle des différents acteurs a permis à Helm de s’imposer comme standard pour la distribution d’applications sur Kubernetes.
• Le suivi des applications assurées par les entreprises et fournisseurs officiels permet de rassurer quant à la pérennité et la sécurité des applications.

2. Les versions de Helm

Actuellement, la dernière version majeure de Helm est Helm 3. Cette version présente des différences substantielles avec Helm 2 et elles ne sont pas entièrement compatibles.

Par conséquent les clusters Kubernetes qui utilisent Helm 2 devront migrer vers Helm 3, car à partir de novembre 2020, Helm 2 ne sera plus pris en charge.

3. Helm : comment ça marche ?

Le client Helm est utilisé pour installer, mettre à jour et créer des charts, ainsi que pour les compiler et les envoyer à une API Kubernetes sous une forme acceptable.

La version précédente avait une architecture client-serveur, utilisant un programme exécuté sur un cluster avec Kubernetes, appelé Tiller. Ce logiciel était responsable de la durée de vie du déploiement. Mais cette approche a conduit à des problèmes de sécurité, ce qui est l’une des raisons pour lesquelles toutes les fonctions sont désormais gérées par le client.

L’installation de Helm 3 est nettement plus facile que la version précédente, car seul le client doit être installé. Il est disponible pour Windows, MacOs et Linux. Vous pouvez installer le programme à partir de versions binaires, Homebrew ou via un script d’installation configuré.

Source : developer.ibm.com

4. Que sont les charts Helm et quels sont ses composants ?

Helm utilise un format de packaging appelé Charts. Un Chart est un ensemble de fichiers qui décrivent un ensemble connexe de ressources Kubernetes.

Les Charts Helm aident à définir un cadre commun pour l’utilisation de base de l’application et tous les paramètres possibles.

Un seul Chart peut être utilisé pour implémenter quelque chose de simple, comme un pod Memcached, ou quelque chose de complexe, comme une pile complète d’applications Web avec des serveurs HTTP, des bases de données, des caches, etc.

1. La structure de répertoire de base d’un chart

Les charts sont regroupés dans les répertoires avec les fichiers sous l’arborescence suivante. Ce répertoire sera empaqueté dans un fichier versionné prêt à être déployé. Le nom du dossier est le nom du chart (sans les informations de version). Par conséquent, un chart décrivant Memcached sera stocké dans le répertoire memcached/.

Dans ce répertoire, Helm attendra une structure qui correspond à ceci :

Chart-memcached (https://github.com/bitnami/charts/tree/master/bitnami/memcached/)

• templates/ : ce répertoire contient les fichiers de modèle combinés avec les valeurs de configuration (à partir de + values.yaml + et de la ligne de commande) et restitués dans les manifestes Kubernetes. Les modèles utilisent le format de modèle du langage de programmation Go.

• Charts/ : facultative, les dépendances de diagramme gérées manuellement peuvent être placées dans ce répertoire, bien qu’il soit généralement préférable d’utiliser + Requirements.yaml + pour lier dynamiquement les dépendances.

• crds : facultative, Kubernetes Custom Resource Definitions

• Chart.yaml : un fichier YAML avec des métadonnées sur le chart, telles que le nom et la version du chart, des informations sur le responsable, un site Web pertinent et des mots clés de recherche.

• README.md : un fichier Lisez-moi contenant des informations pour les utilisateurs du chart.

• LICENSE : une licence en texte clair pour la carte.

• values.yaml : un fichier YAML contenant les valeurs de configuration par défaut du chart.

Helm se réserve l’utilisation des répertoires charts/, crds/ et temples/ en plus des fichiers nommés ci-dessus. Le reste des fichiers ou répertoires qui peuvent être dans le chart ne sera pas utilisé par Helm.

# – Fichier Chart.yaml

Ce fichier contient de nombreuses valeurs optionnelles telles que les dépendances de ce chart avec d’autres charts ou encore les personnes qui sont en charge de la maintenance du chart (utile pour les charts dans les dépôts publics maintenus par la communauté).

Nous allons ignorer ces valeurs et nous concentrer sur les valeurs obligatoires que nous verrons toujours dans le fichier. Ceux-ci sont :

• apiVersion: version API du chart (obligatoire).

• name : nom du chart (obligatoire).

• version : version du chart. Suivez les règles du versionnage sémantique 2.0.0 (obligatoire).

• description : description d’une ligne de projet(facultative).

• appVersion : la version de l’application qui contient ce chart. (facultative).

Le champ apiVersion aura la valeur v2 si le chart a besoin de Helm 3 et v1 si le chart peut être utilisé avec les versions précédentes de Helm, y compris Helm 3.

Le champ appVersion n’a rien à voir avec le champ version. Par exemple, si le chart contient elasticsearch, vous pouvez spécifier qu’il utilise la version 7.6.1 d’elasticsearch même si la version du chart est 1.2.3.

# – Dossier Templates

Les modèles de charts Helm sont écrits dans le langage de modèle Go, avec l’ajout de 50 fonctions de modèles supplémentaires de la bibliothèque Sprig et d’autres fonctions spéciales.

Tous les fichiers du modèle sont stockés dans ce répertoire. Lorsque Helm traite les charts, il transmet tous les fichiers de ce répertoire via le moteur de création de modèles.

Les valeurs des modèles sont fournies de deux manières :

1. Les développeurs de charts peuvent fournir un fichier appelé values.yaml dans le chart. Ce fichier contient les valeurs par défaut.
2. Les utilisateurs de chats peuvent fournir un ou plusieurs fichiers YAML contenant des valeurs. Ces fichiers peuvent être fournis avec un flag sur la ligne de commande Helm lors de l’installation ou de la mise à jour d’un chart.

Lorsqu’un utilisateur fournit des valeurs personnalisées, ces valeurs remplacent les valeurs par défaut dans le fichier values.yaml du chart.

Exemple Chart memcached

# – Fichier Values.yaml

Les valeurs de ce fichier dépendent exclusivement des variables Helm que nous avons utilisées dans les fichiers du répertoire Templates.

Values.yaml doit contenir toutes les valeurs nécessaires pour ces variables, de manière que le chart puisse être utilisé sans besoin de modifier aucune variable.

2. Gestion des versions des charts

Chaque chart doit avoir un numéro de version. Toutes les versions doivent suivre les règles de la norme de versionnage sémantique 2.0.0 (SemVer 2 -).

Helm utilise les numéros de version comme indicateur des déploiements. Les packages dans les dépôts sont identifiés par leur nom plus la version.

Par exemple, un chart memcached dont la version est 2.0.4, une fois compressé, aura le nom suivant : memcached-2.0.4.tgz

Comment créer mes propres charts ?

Pour développer vos propres charts, vous pouvez suivre le Guide des meilleures pratiques pour les charts Helm dans la documentation officielle.

Le dépôt GitHub pour les charts Helm officiels est également une source importante d’informations pour le développement.

Il est important de comprendre que les charts Helm peuvent être totalement privés. Rien ne nous oblige à les rendre publics dans les référentiels existants.

Il est possible de créer notre propre référentiel privé. Mais de la part de toute l’équipe Syloé nous recommandons fortement l’utilisation, la diffusion et le partage de l’open source.

Dans les prochaines semaines vous pourrez retrouver dans votre blog open source la deuxième partie de l’article dans laquelle nous installerons Helm, nous verrons les commandes les plus utilisées et nous déploierons une application.

Faites-vous accompagner par un expert !

Syloé vous accompagne et vous conseille dans la supervision de vos serveurs, vos applications métiers et systèmes. Contactez l’un de nos experts  pour plus d’informations.