Une introduction à Helm, le gestionnaire de paquets pour Kubernetes

introduction

Le déploiement d’applications sur Kubernetes - le puissant et populaire système d’orchestration de conteneur - peut être complexe. La configuration d'une seule application peut impliquer la création de plusieurs ressources Kubernetes interdépendantes - telles que des pods, des services, des déploiements et des ensembles de réplicas - chacune nécessitant l'écriture d'un fichier manifeste YAML détaillé.

Helm est un gestionnaire de packages pour Kubernetes qui permet aux développeurs et aux opérateurs de mettre en package, configurer et déployer plus facilement des applications et des services sur des clusters Kubernetes.

Helm est désormais un projet officiel de Kubernetes et fait partie deCloud Native Computing Foundation, une organisation à but non lucratif qui soutient des projets open source dans et autour de l'écosystème Kubernetes.

Dans cet article, nous allons donner un aperçu de Helm et des diverses abstractions qu’il utilise pour simplifier le déploiement d’applications sur Kubernetes. Si vous êtes nouveau sur Kubernetes, il peut être utile de lire d'abordAn Introduction to Kubernetes pour vous familiariser avec les concepts de base.

Un aperçu de Helm

La plupart des langages de programmation et des systèmes d'exploitation ont leur propre gestionnaire de paquets qui facilite l'installation et la maintenance des logiciels. Helm fournit le même ensemble de fonctionnalités de base que de nombreux gestionnaires de paquets que vous connaissez peut-être déjà, tels que lesapt de Debian ou lespip de Python.

Helm peut:

  • Installer un logiciel.

  • Installer automatiquement les dépendances logicielles.

  • Mettre à jour le logiciel.

  • Configurez les déploiements de logiciels.

  • Récupérer des packages logiciels depuis des référentiels.

Helm fournit cette fonctionnalité via les composants suivants:

  • Un outil de ligne de commande,helm, qui fournit l'interface utilisateur à toutes les fonctionnalités de Helm.

  • Un composant de serveur compagnon,tiller, qui s'exécute sur votre cluster Kubernetes, écoute les commandes dehelm et gère la configuration et le déploiement des versions logicielles sur le cluster.

  • Le format d'empaquetage Helm, appelécharts.

  • Unofficial curated charts repository avec des graphiques pré-emballés pour les projets de logiciels open source populaires.

Nous étudierons ensuite le format des graphiques plus en détail.

Graphiques

Les packages Helm sont appeléscharts et se composent de quelques fichiers de configuration YAML et de certains modèles qui sont rendus dans des fichiers manifestes Kubernetes. Voici la structure de répertoire de base d'un graphique:

Exemple de répertoire graphique

package-name/
  charts/
  templates/
  Chart.yaml
  LICENSE
  README.md
  requirements.yaml
  values.yaml

Ces répertoires et fichiers ont les fonctions suivantes:

  • charts/: Les dépendances de graphique gérées manuellement peuvent être placées dans ce répertoire, bien qu'il soit généralement préférable d'utiliserrequirements.yaml pour lier dynamiquement les dépendances.

  • templates/: Ce répertoire contient des fichiers modèles qui sont combinés avec des valeurs de configuration (devalues.yaml et de la ligne de commande) et rendus dans les manifestes Kubernetes. Les modèles utilisent lesGo programming language’s template format.

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

  • LICENSE: Une licence en texte clair pour le graphique.

  • README.md: Un fichier readme contenant des informations pour les utilisateurs du graphique.

  • requirements.yaml: Un fichier YAML qui répertorie les dépendances du graphique.

  • values.yaml: Un fichier YAML de valeurs de configuration par défaut pour le graphique.

La commandehelm peut installer un graphique à partir d'un répertoire local ou d'une version packagée.tar.gz de cette structure de répertoires. Ces graphiques packagés peuvent également être automatiquement téléchargés et installés à partir de référentiels de graphiques ou derepos.

Nous examinerons ensuite les référentiels de graphiques.

Dépôts de graphiques

Un référentiel de graphiques Helm est un site HTTP simple qui sert un fichierindex.yaml et des graphiques empaquetés.tar.gz. La commandehelm a des sous-commandes disponibles pour aider à empaqueter les graphiques et créer le fichierindex.yaml requis. Ces fichiers peuvent être servis par n’importe quel serveur Web, service de stockage d’objets ou hôte de site statique tel que GitHub Pages.

Helm est préconfiguré avec un référentiel de graphiques par défaut, appeléstable. Ce dépôt pointe vers un bucket Google Storage àhttps://kubernetes-charts.storage.googleapis.com. La source du repostable se trouve dansthe helm/charts Git repository on GitHub.

Des dépôts alternatifs peuvent être ajoutés avec la commandehelm repo add. Certains référentiels alternatifs populaires sont:

Que vous installiez un graphique que vous avez développé localement ou un référentiel, vous devez le configurer pour votre configuration particulière. Nous examinerons ensuite les configurations.

Configuration du graphique

Un graphique est généralement livré avec des valeurs de configuration par défaut dans son fichiervalues.yaml. Certaines applications peuvent être entièrement déployées avec des valeurs par défaut, mais vous devrez généralement remplacer certaines configurations pour répondre à vos besoins.

Les valeurs exposées pour la configuration sont déterminées par l'auteur du graphique. Certaines sont utilisées pour configurer les primitives Kubernetes et d'autres peuvent être transmises au conteneur sous-jacent pour configurer l'application elle-même.

Voici un extrait de quelques exemples de valeurs:

values.yaml

service:
  type: ClusterIP
  port: 3306

Ce sont des options pour configurer une ressource KubernetesService. Vous pouvez utiliserhelm inspect values chart-name pour vider toutes les valeurs de configuration disponibles pour un graphique.

Ces valeurs peuvent être remplacées en écrivant votre propre fichier YAML et en l'utilisant lors de l'exécution dehelm install, ou en définissant des options individuellement sur la ligne de commande avec l'indicateur--set. Il vous suffit de spécifier les valeurs que vous souhaitez modifier par défaut.

Un graphique Helm déployé avec une configuration particulière est appelérelease. Nous parlerons des versions suivantes.

Communiqués

Lors de l’installation d’un graphique, Helm combine les modèles du graphique avec la configuration spécifiée par l’utilisateur et les valeurs par défaut envalue.yaml. Celles-ci sont rendues dans des manifestes Kubernetes qui sont ensuite déployés via l'API Kubernetes. Cela crée unrelease, une configuration spécifique et un déploiement d'un graphique particulier.

Ce concept de version est important, car vous souhaiterez peut-être déployer la même application plusieurs fois sur un cluster. Par exemple, vous aurez peut-être besoin de plusieurs serveurs MySQL avec des configurations différentes.

Vous voudrez probablement également mettre à niveau différentes instances d'un graphique individuellement. Une application est peut-être prête pour un serveur MySQL mis à jour, mais une autre ne l’est pas. Avec Helm, vous mettez à niveau chaque version individuellement.

Vous pouvez mettre à niveau une version parce que son graphique a été mis à jour ou parce que vous souhaitez mettre à jour la configuration de la version. Dans tous les cas, chaque mise à jour créera un nouveaurevision d'une version et Helm vous permettra de revenir facilement aux révisions précédentes en cas de problème.

Création de graphiques

Si vous ne trouvez pas de graphique existant pour le logiciel que vous déployez, vous pouvez créer le vôtre. Helm peut afficher la structure d'un répertoire de graphiques avechelm create chart-name. Cela créera un dossier avec les fichiers et répertoires dont nous avons parlé dans la sectionCharts ci-dessus.

À partir de là, vous voudrez remplir les métadonnées de votre graphique dansChart.yaml et placer vos fichiers manifestes Kubernetes dans le répertoiretemplates. Vous devrez ensuite extraire les variables de configuration pertinentes de vos manifestes vers lesvalues.yaml, puis les réintégrer dans vos modèles de manifestes à l'aide dethe templating system.

La commandehelm a de nombreuses sous-commandes disponibles pour vous aider à tester, empaqueter et servir vos graphiques. Pour plus d'informations, veuillez lirethe official Helm documentation on developing charts.

Conclusion

Dans cet article, nous avons examiné Helm, le gestionnaire de paquets de Kubernetes. Nous avons aperçu l'architecture Helm et les composants individuelshelm ettiller, détaillé le format des graphiques Helm et examiné les référentiels de graphiques. Nous avons également examiné la manière de configurer un diagramme Helm et la manière dont les configurations et les diagrammes sont combinés et déployés en tant que versions sur des clusters Kubernetes. Enfin, nous avons abordé les bases de la création d’un graphique quand un graphique approprié n’est pas déjà disponible.

Pour plus d'informations sur Helm, jetez un œil àthe official Helm documentation. Pour trouver les charts officiels de Helm, consultezthe official helm/charts Git repository on GitHub.