Sommaire

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 ...