Présentation de Helm

1. Pourquoi faire appel à Helm ?

Helm a été introduit par la communauté afin de répondre à un besoin de simplification de l’installation des logiciels dans un cluster Kubernetes. Avant l’arrivée de ce mécanisme, l’administrateur devait gérer lui-même le cycle de vie des fichiers YAML, leur personnalisation ainsi que l’intégration des produits en eux-mêmes.

Un cluster Kubernetes fonctionne à l’aide de nombreux produits (Elasticsearch, Prometheus, Grafana, Nginx, etc.). Les maîtriser tous peut être chronophage.

Les charts Helm sont une aide précieuse pour s’affranchir des problématiques d’installation initiale.

On parle de chart Helm dans le cas des packages Helm.

2. Principe de fonctionnement

En version 2, Helm est composé de deux briques : le client Helm (écrit en Go) et la partie serveur en charge de la gestion des paquets (Tiller). Dans la version 3, la partie serveur n’existe plus. Tiller

Le client est installé en local sur le poste de l’administrateur et prend en charge le déploiement du contrôleur dans le cluster Kubernetes (pour Helm 2). Ce contrôleur prendra en charge le déploiement des packages dans le cluster. Avec Helm 3, ce contrôleur n’existe plus.

Avec Helm 2, le déploiement du service Tiller peut constituer en lui-même une faille de sécurité (du fait des droits très...

Pour consulter la suite, découvrez le livre suivant :
couv_EPKUB.png
60-signet.svg
En version papier
20-ecran_lettre.svg
En version numérique
41-logo_abonnement.svg
En illimité avec l'abonnement ENI
130-boutique.svg
Sur la boutique officielle ENI
Précédent
Objectifs du chapitre et prérequis
Suivant
Déploiement de Helm