Tutoriel sur les cartes de barre : Un guide étape par étape avec des exemples

Installation et configuration de Helm

Nous allons voir comment installer Helm CLI sur Windows, Mac et Linux.

À ce jour, la dernière version de Helm est la 3.17.2. Les exemples présentés dans cet article utilisent la version 3.17.2. Vous pouvez trouver la dernière version binaire sur les versions officielles de GitHub.

Installation sous Windows

Téléchargez le binaire correspondant à l'architecture de votre système à partir du lien GitHub releases ci-dessus.

Helm binaire pour Windows

Extrayez le fichier ZIP téléchargé. Vous devriez obtenir les fichiers ci-dessous.

Barre binaire

Créez un dossier nommé "helm" dans le répertoire "C:\NProgram Files". Déplacez les trois fichiers ci-dessus à cet endroit.

Déplacez les fichiers dans le dossier "helm" nouvellement créé.

Nous allons maintenant devoir ajouter un chemin dans nos variables d'environnement pour pointer vers le répertoire "C:\NProgram Files" nouvellement créé. Ouvrez le paramètre "Editer les variables d'environnement du système".

Modifiez les variables d'environnement du système

La fenêtre "Propriétés du système" ci-dessous apparaît. Sous l'onglet "Avancé", sélectionnez "Variables d'environnement..."

Propriétés du système

La fenêtre "Variables d'environnement" ci-dessous apparaît. Sous "Variables système", sélectionnez "Chemin". Veillez à ce qu'il soit surligné en bleu. Sélectionnez ensuite "Modifier".

Variables d'environnement

La fenêtre "Modifier la variable d'environnement" apparaît. Sélectionnez "Nouveau", entrez le chemin "C:\NProgram Files" et sélectionnez "OK".

Modifiez la variable d'environnement

Sélectionnez "OK" dans les fenêtres "Variables d'environnement" et "Propriétés du système" pour les fermer. Ouvrez un nouveau terminal et vérifiez que la commande Helm fonctionne.

Vérifiez l'installation de Helm CLI

Installation sur macOS

Nous pouvons installer le CLI Helm sur macOS via Homebrew ou le binaire. Je couvrirai les deux méthodes d'installation.

Installation binaire

Ouvrez le terminal (zsh) et exécutez les commandes suivantes.

# Download the correct binary corresponding to your system’s architecture.
wget https://get.helm.sh/helm-v3.17.2-darwin-arm64.tar.gz

# Extract the binary
tar -zxvf helm-v3.17.2-darwin-arm64.tar.gz

# Move the helm binary to /usr/local/bin
sudo mv darwin-arm64/helm /usr/local/bin/

# Verify Helm CLI
helm version

Installation de Helm via binaire sur macOS

Homebrew

Assurez-vous que Homebrew est installé localement. Pour vérifier, exécutez brew --version. Sinon, vous pouvez vous référer à la page officielle de Homebrew pour les instructions d'installation.

Exécutez les commandes suivantes pour installer le CLI Helm :

# With brew installed, update Homebrew's formulae and cask definitions
brew update

# Install Helm CLI
brew install helm

# Verify the installation
helm version

# Verify the location of the helm binary stored locally
which helm

Installation de Helm via brew sur macOS

Installation sous Linux

Pour démontrer l'installation sur Linux, j'ai démarré un Amazon Linux EC2 avec l'AMI ami-065a492fef70f84b1.

# Switch to superuser
sudo su -

# Download the correct binary corresponding to your system’s architecture.
wget https://get.helm.sh/helm-v3.17.2-linux-amd64.tar.gz

# Extract the binary
tar -zxvf helm-v3.17.2-linux-amd64.tar.gz

# Move the helm binary to /usr/local/bin
mv linux-amd64/helm /usr/local/bin/helm

# Verify Helm CLI
helm version

# Clean-up
rm -rf linux-amd64
rm -f helm-v3.17.2-linux-amd64.tar.gz

Téléchargez, extrayez et déplacez le fichier binaire

Configurer Helm avec votre cluster

De la même manière que kubectl est configuré pour communiquer avec un cluster spécifique, Helm utilise également le fichier ~/.kube/config pour savoir sur quel cluster exécuter les commandes.

# To find out which context (and therefore cluster) is currently being used
kubectl config current-context

# To view the entire ~/.kube/config file
kubectl config view

# If you’re running an EKS cluster on AWS, execute this command to update your .kubeconfig file and set it to the current context.
aws eks update-kubeconfig --name <Name of EKS cluster> --region <region>

# View helm charts installed in all namespaces on the cluster
helm list -A

Sortie des commandes de configuration kubectl

Ajout et mise à jour des dépôts Helm

Les cartes publiques Helm sont stockées dans les dépôts Helm. Avant d'utiliser une carte Helm publique, nous devons ajouter certaines métadonnées de ce référentiel à notre carte locale.

# Adds a Helm repository locally
helm repo add bitnami https://charts.bitnami.com/bitnami

Où la commande helm repo add enregistre-t-elle les informations ? Exécutez helm env.

Sortie de helm repo add et helm env

Le chemin indiqué par HELM_REPOSITORY_CONFIG est l'endroit où les informations du référentiel sont sauvegardées.

Pour obtenir la liste de tous les dépôts ajoutés localement, exécutez la commande helm repo list. Il obtient l'information à partir de la valeur de HELM_REPOSITORY_CONFIG.

Pour ma part, ce sera le dossier ~/Library/Preferences/helm/repositories.yaml.

Pour lister tous les graphiques du référentiel, exécutez helm search repo bitnami.

Sortie de helm repo list et helm search repo

En tant que dépôts publics, ils reçoivent régulièrement des mises à jour de la part des contributeurs respectifs. Pour mettre à jour les graphiques dans le référentiel, il suffit de mettre à jour l'ensemble du référentiel.

# Update a repository
helm repo update bitnami

Résultat de la mise à jour de la base de données helm

Exploration de la structure d'un diagramme de barre

Pour bien comprendre le fonctionnement des cartes Helm, il est important de se familiariser avec leur structure. 

Un diagramme Helm est plus qu'un simple paquet de fichiers YAML : c'est un répertoire bien organisé qui définit une application Kubernetes en combinant des modèles, une configuration et des métadonnées. 

Dans cette section, je vais décomposer les composants clés, y compris la disposition générale du répertoire chart, le rôle du fichier values.yaml pour la configuration, et comment Helm utilise Go templating pour générer dynamiquement des manifestes Kubernetes.

Structure du répertoire des cartes

Le répertoire des graphiques par défaut est le suivant, où demo-helm est le nom du graphique que j'ai défini. Nous le créerons dans la section suivante. 

Voyons brièvement à quoi sert chaque fichier ou dossier qui s'y trouve.

#    demo-helm/
#    ├── .helmignore   # Contains patterns to ignore when packaging Helm charts.
#    ├── Chart.yaml    # Information about your chart
#    ├── values.yaml   # The default values for your templates
#    ├── charts/       # Charts that this chart depends on
#    └── templates/    # The template files
#        └── tests/    # The test files

• Le fichier .helmignore fonctionne de la même manière que .gitignore ou .dockerignore. Si nous voulons exclure certains fichiers ou répertoires de notre graphique Helm, nous pouvons dresser la liste de leurs modèles dans le fichier .helmignore. Tous les fichiers ou répertoires qui correspondent à ces modèles seront ignorés lors de l'exécution des commandes Helm.
• Chart.yaml contient des métadonnées sur la carte Helm, telles que le nom de la carte, la description, la version de la carte et la version de l'application.
• values.yaml contient les valeurs de configuration par défaut qui transforment les modèles Go de la carte Helm en manifestes Kubernetes. Voici quelques valeurs courantes définies dans ce fichier :
  • Le dépôt d'images et la balise.
  • Indicateurs booléens permettant d'activer ou de désactiver des ressources spécifiques.
  • Numéros de port.
  • Autres paramètres spécifiques à l'application.
• Le répertoire charts/ contient les dépendances de la carte. Si notre carte Helm dépend d'autres cartes (appelées cartes secondaires), elles seront placées ici.
• Le dernier est le dossier templates/, qui contient les fichiers modèles Go utilisés pour générer les manifestes Kubernetes. Ces modèles définissent les ressources qui seront déployées, telles que Deployment, ServiceAccount, Service, Ingress et ConfigMap.

Comprendre values.yaml

Le fichier values.yaml est le fichier de configuration par défaut, fournissant un emplacement central pour définir les valeurs d'entrée que les modèles référencent lors du rendu des manifestes Kubernetes.

Lors de l'installation d'un graphique Helm, Helm lit le fichier values.yaml et injecte son contenu dans les modèles du graphique via le moteur de création de modèles. Cela nous permet de paramétrer la configuration de l'application, comme les versions des images de conteneurs, les limites de ressources, le nombre de répliques, les paramètres d'entrée, et plus encore, sans modifier directement les modèles.

Voici un extrait de la page values.yaml par défaut d'une carte Helm nouvellement créée :

# Default values for demo-helm.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

# This will set the replicaset count more information can be found here: https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/
replicaCount: 1

# This sets the container image more information can be found here: https://kubernetes.io/docs/concepts/containers/images/
image:
  repository: nginx
  # This sets the pull policy for images.
  pullPolicy: IfNotPresent
  # Overrides the image tag whose default is the chart appVersion.
  tag: ""

# This is for the secrets for pulling an image from a private repository more information can be found here: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
imagePullSecrets: []
# This is to override the chart name.
nameOverride: ""
fullnameOverride: ""

# This section builds out the service account more information can be found here: https://kubernetes.io/docs/concepts/security/service-accounts/
serviceAccount:
  # Specifies whether a service account should be created
  create: true
  # Automatically mount a ServiceAccount's API credentials?
  automount: true

Ces valeurs sont référencées dans les fichiers modèles à l'aide de la notation ., telle que {{ .Values.replicaCount }} ou {{ .Values.image.repository }}. Helm permet de modifier ces valeurs par défaut lors de l'installation ou de la mise à jour, en utilisant un fichier de valeurs personnalisé ou en passant des valeurs individuelles en ligne.

# Install a helm chart with the default values from values.yaml
helm install demo-helm ./demo-helm

# Values defined in custom-values.yaml will override those in values.yaml.
# Nonetheless, values in values.yaml not found in custom-values.yaml will still be applied.
# “-f” flag is short for the “--values” flag
helm install demo-helm ./demo-helm -f custom-values.yaml

# Overwrite default values using the  “--set” flag
helm install demo-helm ./demo-helm --set replicaCount=3 --set image.tag=latest

Modélisation avec les modèles Go

L'une des fonctionnalités les plus puissantes de Helm est son moteur de templating, qui permet une configuration dynamique et réutilisable des manifestes Kubernetes. Les modèles Go sont au cœur de cette fonctionnalité, et le même langage de création de modèles est utilisé dans de nombreux autres outils et frameworks basés sur Go, tels que Terraform et Docker.

Au lieu de coder les valeurs directement dans nos fichiers YAML, Helm nous permet de définir des modèles qui font référence à des entrées dynamiques - le plus souvent à partir de values.yaml. Par exemple, dans le modèle deployment ci-dessous :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.name }}
spec:
  replicas: {{ .Values.replicas }}

{{ .Values.name }} et {{ .Values.replicas }} sont des expressions du modèle Go. Où .Values fait référence soit au contenu du fichier values.yaml, soit au fichier défini dans l'indicateur --values, soit à des valeurs passées en ligne. Ces espaces réservés sont remplacés par des valeurs réelles lorsque le graphique est rendu.

Par exemple, le modèle deployment ci-dessous utilise des valeurs telles que replicaCount et image.repository.

Mapping entre values.yaml et deployment.yaml

Le modèle serviceAccount utilise quant à lui serviceAccount.create. La totalité de la ressource serviceAccount sera omise si la valeur est fausse.

Correspondance entre values.yaml et serviceaccount.yaml

Pour illustrer davantage, disons que vous avez la configuration suivante dans votre values.yaml.

replicaCount: 2
image:
  repository: nginx
  tag: "1.21.1"

Votre modèle deployment.yaml (sous templates/deployment.yaml ) pourrait ressembler à ceci :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Release.Name }}
  template:
    metadata:
      labels:
        app: {{ .Release.Name }}
    spec:
      containers:
        - name: nginx
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          ports:
            - containerPort: 80

Lorsque Helm rend le manifeste Kubernetes, soit pendant helm template, helm install, soit pendant helm upgrade, il le fait en injectant les valeurs de values.yaml.

# helm template <release name> <chart name OR path to chart folder>
helm template my-nginx <chart name OR path to chart folder>

Nous obtiendrons alors le manifeste ci-dessous :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-nginx
  template:
    metadata:
      labels:
        app: my-nginx
    spec:
      containers:
        - name: nginx
          image: "nginx:1.21.1"
          ports:
            - containerPort: 80

Création de votre première carte de barre

La façon la plus simple d'apprendre Helm est de construire nous-mêmes une carte. Nous allons parcourir la création d'un diagramme de base, comprendre sa structure et le personnaliser pour déployer notre application sur Kubernetes.

En utilisant helm create

Au lieu d'utiliser les cartes Helm publiques des dépôts Helm, que nous avons abordées plus haut dans la sous-section "Ajouter et mettre à jour les dépôts Helm", créons-en une nous-mêmes.

# Creates a helm chart with the name “demo-helm”
helm create demo-helm

La structure du répertoire sera la suivante :

#    demo-helm/
#    ├── .helmignore   # Contains patterns to ignore when packaging Helm charts.
#    ├── Chart.yaml    # Information about your chart
#    ├── values.yaml   # The default values for your templates
#    ├── charts/       # Charts that this chart depends on
#    └── templates/    # The template files
#        └── tests/    # The test files

Résultat de la commande helm create

Personnalisation des modèles

Explorons le contenu du dossier templates pour mieux le comprendre avant de le modifier.

Contenu du dossier du modèle

Le fichier _helpers.tpl contient des aides de modèle Go réutilisables (semblables à des fonctions) qui peuvent être appelées à partir d'autres modèles dans le diagramme, ce qui favorise la réutilisation et la maintenance du code.

L'image ci-dessous montre comment les sections du fichier _helpers.tpl correspondent au fichier service.yaml.

Mapping entre _helpers.tpl et service.yaml

Nous pouvons exécuter la commande helm template pour obtenir le rendu service.yaml. La commande valide que le graphique ne contient pas d'erreurs et rend les fichiers de manifeste.

# helm template <release name> <chart name OR path to chart folder>
helm template demo-helm ./demo-helm

Sortie de la commande helm template

Nous pouvons compléter ou modifier le contenu du fichier _helpers.tpl ou de l'un des modèles de ressources pour répondre à nos besoins. Par exemple, pour ajouter une étiquette de sélection à la ressource service via le fichier _helpers.tpl:

{{- define "demo-helm.selectorLabels" -}}
app.kubernetes.io/name: {{ include "demo-helm.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/custom: "testing" # Add this line
{{- end }}

Ajouter une étiquette de sélection dans _helpers.tpl

Les guillemets utilisés autour de la valeur testing doivent être des guillemets droits ("testing") et non des guillemets frisés ("testing"). Bien que helm template ne nous envoie pas d'erreur, helm install le fera.

• Enregistrez le fichier _helpers.tpl et exécutez à nouveau la commande helm template. Vous devriez voir le sélecteur ajouté à la ressource de service.

Mise à jour de la sortie de la commande helm template

Remarquez qu'en plus d'être ajouté au sélecteur, il a également été ajouté aux étiquettes de toutes les ressources. En effet, le site {{- define "demo-helm.labels" -}} contient le site {{ include "demo-helm.selectorLabels" . }}. Ainsi, tout ce qui se trouve sur le site selectorLabels sera inclus dans les étiquettes .

Un autre exemple est que nous pouvons modifier le site deployment.yaml pour exposer un autre port sur le conteneur. Par défaut, lorsque nous créons un graphique à partir de la commande helm create, le modèle de déploiement n'expose qu'un port sur le conteneur.

• Ajoutez la configuration suivante au site deployment.yaml.

- name: https
  containerPort: 443
  protocol: TCP

Ajout d'un port au conteneur dans deployment.yaml

Pour des raisons de simplicité, la valeur de containerPort est codée en dur à 443. Dans la sous-section suivante, nous verrons comment utiliser le site values.yaml pour le paramétrer .

• Enregistrez le fichier deployment.yaml et exécutez à nouveau la commande helm template. Le port doit maintenant être ajouté au conteneur dans la ressource de déploiement.

Comme l'indentation est cruciale dans le formatage YAML, le modèle pour les ressources Kubernetes inclut la fonction nindent pour indenter les blocs requis en conséquence.

apiVersion: v1
kind: Service
metadata:
  name: {{ include "demo-helm.fullname" . }}
  labels:
    {{- include "demo-helm.labels" . | nindent 4 }} 
spec:
  type: {{ .Values.service.type }}
  ports:
    - port: {{ .Values.service.port }}
      targetPort: http
      protocol: TCP
      name: http
  selector:
    {{- include "demo-helm.selectorLabels" . | nindent 4 }}

Définition des valeurs par défaut

Maintenant que nous avons couvert la majeure partie du contenu du dossier template, nous sommes prêts à passer à values.yaml.

Répertoire des cartes de barre

Dans la sous-section précédente, nous avons codé en dur la valeur de containerPort à 443. Paramétrons-le. 

• Dans values.yaml, sous la clé service, ajoutez la clé imbriquée https_port avec la valeur 443.

Ajouter une clé imbriquée

• Modifiez le site deployment.yaml pour remplacer le code en dur 443 par {{ .Values.service.port }}.

Paramétrer le numéro de port

• Pour valider et rendre les ressources Kubernetes :

# helm template <release name> <chart name OR path to chart folder>
helm template demo-helm ./demo-helm

Vous devriez voir que la valeur 443 est correctement définie sur le site containerPort.

Valeur du port https rendu

Si d'autres endroits du tableau de bord nécessitent la valeur de ce containerPort, utilisez simplement {{ .Values.service.https_port }}.

Déploiement et gestion des versions

Maintenant que nous avons créé notre propre diagramme Helm, l'étape suivante consiste à le déployer sur un cluster Kubernetes. 

Helm gère le cycle de vie des ressources Kubernetes déployées en tant que version. Dans cette section, nous allons explorer comment Helm gère les déploiements, les mises à niveau, les retours en arrière et le suivi de l'historique des versions, ce qui nous donne un contrôle et une visibilité puissants sur nos charges de travail Kubernetes.

Qu'est-ce qu'une libération ?

Dans Helm, une version est une instance spécifique d'une carte Helm qui a été déployée dans un cluster Kubernetes.

Chaque fois que nous installons un graphique à l'aide de helm install, Helm crée une nouvelle version avec son propre nom, sa propre configuration et sa propre version. De même, lorsque nous mettons à niveau une version à l'aide de helm upgrade, Helm crée une nouvelle révision de cette version avec le même nom, mais la configuration et la version peuvent être différentes. Essentiellement, une version est une nouvelle version de la même version avec des paramètres ou un contenu graphique mis à jour.

Ainsi, lorsque nous disons "installer une carte Helm", nous faisons en réalité référence à la "création d'une version Helm".

Illustration visuelle des rejets - image de l'auteur.

Bien que seule la révision la plus récente d'une version soit activement déployée dans le cluster, Helm conserve l'historique complet des révisions précédentes. Cela signifie que nous pouvons facilement revenir à un état antérieur en utilisant helm rollback.

Lorsque nous effectuons un rollback, Helm ne restaure pas l'ancienne version telle quelle, mais crée une nouvelle révision qui reproduit la configuration de la version précédente sélectionnée. Chaque révision est numérotée et les retours en arrière incrémentent le numéro de révision, ce qui permet de conserver un historique cohérent et vérifiable.

Installation d'une carte avec helm install

Voyons comment déployer une version de Helm sur un cluster Kubernetes. Nous allons installer deux diagrammes Helm : celui que nous avons créé dans la section précédente et le diagramme bitnami/apache du dépôt public Bitnami que nous avons déjà ajouté à notre configuration Helm locale.

Tableau Helm bitnami/apache

Lors de l'installation d'une carte, nous devons spécifier un nom de publication - qui peut être n'importe quoi et ne doit pas nécessairement correspondre au nom de la carte. Toutefois, il est recommandé d'utiliser un nom étroitement lié au graphique afin de permettre aux utilisateurs de comprendre plus facilement ce que le communiqué représente en un coup d'œil.

• Tout d'abord, pour la carte Helm que nous avons créée :

# Install the helm chart (in other words, create a helm release) into the default namespace
# helm install <release name> <chart name OR path to chart folder>
helm install datacamp-demo-helm ./demo-helm
# OR
helm upgrade --install datacamp-demo-helm ./demo-helm

# If installing to a specific namespace, add the -n flag
# Install the chart to the “app” namespace
helm install my-amazing-helm-demo ./demo-helm -n app

Déployer un graphique Helm personnalisé

# To validate the Kubernetes resources
# Get pods, service, and serviceaccount resources in the default namespace
kubectl get pods,svc,sa

Valider les ressources déployées à partir de la carte Helm personnalisée

• Deuxièmement, pour le graphique bitnami/apache:

# Install the helm chart into the default namespace
helm install apache bitnami/apache
# OR
helm upgrade --install apache bitnami/apache

Résultat de l'installation de helm

Sortie de helm upgrade --install

Pour afficher les versions de Helm qui ont été déployées :

# List all helm releases in all namespaces
helm list -A

Liste de tous les communiqués de Helm

Mise à niveau du gouvernail

Après le déploiement initial d'une carte Helm, les mises à jour sont inévitables, qu'il s'agisse de changer la balise de l'image, d'ajuster le nombre de répliques, d'activer ou de désactiver des ressources optionnelles ou de modifier les valeurs de configuration.

Helm propose la commande helm upgrade pour appliquer ces changements à une version existante sans avoir à la redéployer à partir de zéro. Cette commande nous permet de mettre à jour notre application en cours d'exécution en re-rendant les modèles avec la nouvelle configuration et en appliquant les changements au cluster Kubernetes, en gérant de manière transparente les mises à jour avec un minimum d'interruption.

L'application déployée via notre diagramme de barre personnalisé exécute une image nginx avec la balise 1.16.0. Nous pouvons déterminer la balise en exécutant la commande helm get manifest.

# Output the rendered Kubernetes manifest that was installed by the helm chart
# helm get manifest <release name>
helm get manifest datacamp-demo-helm

Dans le manifeste de la ressource deployment, vous devriez voir ce qui suit :

Valeur de l'image

D'où vient l'étiquette 1.16.0? Notre valeur image.tag in values.yaml est vide.

Examinez le modèle deployment.yaml: la clé image a pour valeur "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}". Lorsque le image.tag n'est pas défini dans le values.yaml, Helm obtiendra la valeur du appVersion définie dans le Charts.yaml.

appVersion dans Chart.yaml

• Mettons à jour l' adresse values.yaml de notre graphique personnalisé, et mettons à jour l' adresse image.tag en "1.26".

Mise à jour de image.tag de "" à "1.26"

• Ensuite, exécutez la commande helm upgrade.

# helm upgrade <release name> <chart name or path to chart>
helm upgrade datacamp-demo-helm ./demo-helm

# Alternatively, you can update the value via the --set flag
helm upgrade datacamp-demo-helm ./demo-helm --set 

La sortie de la commande helm upgrade

Examinez la ressource de déploiement ; la balise image doit être 1.26. En coulisses, lors d'une mise à niveau, Helm effectue les opérations suivantes :

1. Rendu des modèles: Helm redessine les modèles du graphique en utilisant les valeurs (mises à jour) transmises avec la commande.
2. Déterminer les changements: Helm compare les nouveaux manifestes rendus avec les manifestes actuels dans le cluster. Dans la dernière section de l'article, nous étudierons la possibilité de vérifier les modifications avant de les appliquer.
3. Mise à jour sélective: Seules les ressources qui ont changé (comme deployment, configmaps ou secrets ) sont mises à jour.
4. Suivi de l'historique des versions: Helm enregistre la nouvelle version et la configuration, ce qui nous permet de revenir en arrière si nécessaire.

# To view the release history. It also shows the revision numbers.
# helm history <release name>
helm history datacamp-demo-helm

Sortie de la commande helm history

Retour en arrière avec helm rollback

Nous venons de mettre à jour une version de Helm, mais peu de temps après, nous avons remarqué que l'application ne se comportait pas comme prévu. Bien que le dépannage soit important, dans un environnement de production, la priorité immédiate est souvent de stabiliser le système. C'est là qu'intervient la fonction de retour en arrière de Helm. 

Helm permet de revenir facilement à une version précédente, dont la qualité est connue, à l'aide d'une seule commande, ce qui nous permet de récupérer rapidement les déploiements qui ont échoué et de minimiser les temps d'arrêt. 

• Nous allons annuler la mise à niveau effectuée ci-dessus.

# The first argument of the rollback command is the name of a release, and the second is a revision (version) number. If this argument is omitted or set to 0, it will roll back to the previous release.
# helm rollback <release name> <revision number>
helm rollback datacamp-demo-helm 0

La sortie de la commande helm rollback

Examinez le déploiement datacamp-demo-helm, et vous devriez voir l'image nginx renvoyée à 1.16.0.

kubectl get deploy datacamp-demo-helm -oyaml

Désinstallation d'une version

Pour désinstaller la version Helm, en d'autres termes, pour supprimer toutes les ressources Kubernetes déployées à partir de la version, exécutez la commande helm uninstall.

# helm uninstall <release name>
helm uninstall datacamp-demo-helm
helm uninstall apache

Résultat de la commande helm uninstall

Pour découvrir comment Helm prend en charge les pipelines CI/CD évolutifs, en particulier pour les flux de travail ML, explorez le cours CI/CD pour l'apprentissage automatique.

Personnalisation des tableaux de bord pour différents environnements

L'un des principaux atouts de Helm est sa flexibilité. Qu'il s'agisse d'un déploiement en développement, en staging ou en production, Helm permet de personnaliser facilement le comportement de notre graphique par le biais de la configuration. 

Dans cette section, nous verrons comment adapter un diagramme Helm à différents environnements à l'aide d'outils tels que values.yaml, de dérogations spécifiques à l'environnement et des drapeaux --set et -f de Helm.

Utilisation de plusieurs fichiers values.yaml

Helm offre un moyen flexible de gérer les configurations spécifiques à l'environnement à l'aide de plusieurs fichiers values.yaml .

Au lieu de maintenir un site values.yaml unique et complexe qui tente de prendre en compte tous les paramètres possibles pour dev, staging et production, ou des instructions conditionnelles complexes dans nos modèles pour prendre en compte les différents environnements, nous pouvons les répartir dans des fichiers distincts, chacun adapté à un environnement spécifique.

Par exemple, notre répertoire de graphiques peut comprendre les éléments suivants

my-chart/
├── values.yaml                    # default values
├── values-dev.yaml           # development-specific overrides
├── values-staging.yaml    # staging-specific overrides
└── values-prod.yaml          # production-specific overrides

Remplacer les valeurs au moment de l'installation

Helm nous permet de remplacer les valeurs par défaut définies dans values.yaml en utilisant soit le drapeau --set pour les remplacements en ligne, soit le drapeau -f pour fournir un fichier de valeurs externe. Le drapeau -f est l'abréviation du drapeau --values.

Pour installer ou mettre à jour notre version de Helm avec l'option -f :

# For installing on dev
helm install <release name> <chart name or path to chart> -f values-dev.yaml

# For upgrading on dev
helm upgrade <release name> <chart name or path to chart> -f values-dev.yaml

# For installing on staging
helm install <release name> <chart name or path to chart> -f values-staging.yaml

# For upgrading on staging
helm upgrade <release name> <chart name or path to chart> -f values-staging.yaml

Pour installer ou mettre à jour notre version de Helm avec le drapeau --set:

# For installation
helm install <release name> <chart name or path to chart> --set image.tag=1.26

# For upgrading
helm upgrade <release name> <chart name or path to chart> --set image.tag=1.26

Si --set et -f sont tous deux utilisés lors de l'installation (ou de la mise à jour), Helm applique les valeurs dans l'ordre suivant :

1. La base values.yaml (si présente)
2. Valeurs du fichier spécifié avec -f
3. Les valeurs en ligne transmises avec --set

Cela signifie que si la même clé apparaît à la fois dans le fichier -f et dans l' indicateur --set, c'est la valeur de --set qui prévaut .

Par exemple, si nous avons défini image.tag comme étant 1.22 dans values-dev.yaml, mais que nous avons défini image.tag comme étant 1.26 via le drapeau --set, la valeur image.tag qui sera utilisée pour rendre le manifeste Kubernetes sera 1.26.

# E.g. we defined image.tag to be 1.22 in values-dev.yaml
helm install <release name> <chart name OR path to chart> --set image.tag=1.26 -f values-dev.yaml

Gestion des secrets

Lorsque vous déployez des applications sur Kubernetes à l'aide de Helm, la manipulation de données sensibles, telles que les clés API, les identifiants de base de données ou les certificats TLS, nécessite une attention particulière. Bien que Helm prenne en charge la ressource Kubernetes Secret, les valeurs de la ressource secrète sont simplement encodées en base64, ce qui peut être décodé par n'importe qui.

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  namespace: default
type: Opaque
data:
  key1: c3VwZXJzZWNyZXQ=  # ← This is base64 encoded
  key2: dG9wc2VjcmV0          # ← This is base64 encoded

# Decode the value of key1
echo "c3VwZXJzZWNyZXQ=" | base64 -d

# Decode the value of key2
echo "dG9wc2VjcmV0" | base64 -d

Le stockage de secrets directement dans un fichier values.yaml ou en texte brut dans notre tableau n'est pas sécurisé et doit être évité, en particulier lorsque les fichiers sont soumis à un contrôle de version.

Pour gérer les secrets en toute sécurité dans les diagrammes Helm dans différents environnements, envisagez d'utiliser des outils spécialement conçus à cet effet. Deux solutions largement adoptées sont les secrets scellés et les secrets externes.

Secrets scellés

Sealed Secrets est un projet open-source développé par Bitnami qui aide à gérer les données sensibles dans Kubernetes de manière sécurisée et adaptée à GitOps. Il introduit une définition de ressource personnalisée (CRD) appelée SealedSecret, qui nous permet de chiffrer les secrets avant de les déposer dans un dépôt Git.

Contrairement aux ressources Kubernetes secrets ordinaires, qui stockent les données en codage base64 et ne sont pas chiffrées, les ressources SealedSecret contiennent des valeurs chiffrées qui ne peuvent être déchiffrées que par le contrôleur Sealed Secrets s'exécutant dans le cluster Kubernetes cible. Cela signifie que les secrets chiffrés peuvent être stockés en toute sécurité dans des systèmes de contrôle de version tels que Git.

Pour configurer notre cluster et notre environnement local afin d'utiliser Sealed Secrets :

• Installez le CRD SealedSecret et le contrôleur côté serveur (qui fonctionne comme un pod) dans l' espace de noms kube-system.

kubectl apply -f https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.29.0/controller.yaml
#OR
helm install sealed-secret bitnami/sealed-secrets -n kube-system

Installez SealedSecret sur notre cluster via kubectl

Installez SealedSecret sur notre cluster via Helm

• Vérifiez les ressources :

Vérifier les ressources en installant les secrets scellés

• Installez le CLI kubeseal sur notre système local.

# Linux x86_64:
curl -OL "https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.29.0/kubeseal-0.29.0-linux-amd64.tar.gz"
tar -xvzf kubeseal-0.29.0-linux-amd64.tar.gz kubeseal
sudo install -m 755 kubeseal /usr/local/bin/kubeseal

# macOS
brew install kubeseal

Pour créer la ressource SealedSecret CRD:

# Pass the secret manifest to kubeseal for it to generate the SealedSecret CRD resource containing the encrypted secrets. Saves the SealedSecret CRD manifest in sealed-mysecret.yaml.
kubectl create secret generic mysecret --dry-run=client --from-literal key1=supersecret --from-literal key2=topsecret --output json | kubeseal | tee sealed-mysecret.yaml

# Or if you have the secret manifest saved in a JSON file
kubeseal -f mysecret.yaml -w sealed-mysecret.yaml

Générer et enregistrer la ressource CRD SealedSecret

Appliquez le fichier sealed-mysecret.yaml. Lorsqu'une ressource SealedSecret est créée dans le cluster, le contrôleur déchiffre automatiquement les données scellées et crée une ressource Kubernetes secrets standard à partir de celles-ci.

Créer la ressource CRD SealedSecret

Cette approche garantit que les informations sensibles restent sécurisées tout au long du pipeline CI/CD.

Opérateur de Secrets Externes (OSE)

External Secrets Operator (ESO) est un opérateur Kubernetes qui nous permet de récupérer et d'injecter en toute sécurité dans Kubernetes Secrets des secrets provenant de systèmes de gestion de secrets externes, tels que AWS Secrets Manager, HashiCorp Vault, Google Secret Manager, Azure Key Vault, et d'autres. 

Au lieu de créer ou de mettre à jour manuellement les secrets Kubernetes, ESO récupère les dernières valeurs secrètes de ces fournisseurs externes via leurs API et s'assure que notre cluster Kubernetes dispose toujours d'informations d'identification ou de données sensibles à jour.

L'ESO introduit un ensemble de ressources personnalisées -ExternalSecret et ClusterSecretStore- qui font abstraction des complexités liées à l'interaction avec des backends secrets externes. Ces ressources définissent les secrets à récupérer et leur provenance, ce qui facilite la gestion des cycles de vie des secrets d'une manière déclarative et native pour Kubernetes.

Pour cet exemple, nous allons récupérer un secret à partir d'AWS Secrets Manager. 

• Tout d'abord, créez un rôle IAM qui sera utilisé par le pod external-secrets pour récupérer le secret dans AWS Secrets Manager.

Rôle IAM pour le pod external-secrets

La politique d'autorisation des rôles IAM est la suivante :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ESO",
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetSecretValue"
            ],
            "Resource": "*"
        }
    ]
}

• Ensuite, créez un secret dans AWS Secrets Manager.

AWS Secrets Manager secret

Pour configurer notre cluster afin d'utiliser ESO :

helm repo add external-secrets https://charts.external-secrets.io


# Replace the ARN of the IAM role
helm install external-secrets external-secrets/external-secrets \
    -n external-secrets \
    --create-namespace \
    --version 0.15.1 \
    --set serviceAccount.annotations."eks\.amazonaws\.com/role-arn"="<ARN of IAM Role>"

Résultat de l'installation des secrets externes

• Vérifiez l'installation :

kubectl get pods,crd -n external-secrets

Vérifier les ressources provenant de l'installation de l'OEN

• Ensuite, pour déployer la ressource ClusterSecretStore, enregistrez ce qui suit dans cluster-secret-store.yaml et créez la ressource.

apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: "cluster-secret-store"
spec:
  provider:
    aws:
      service: SecretsManager
      region: ap-southeast-1
      auth:
        jwt:
          serviceAccountRef:
            name: "external-secrets"
            namespace: "external-secrets"

kubectl create -f cluster-secret-store.yaml
kubectl get ClusterSecretStore

La ressource personnalisée ClusterSecretStore est un SecretStore à l'échelle du cluster qui peut être référencé par ExternalSecrets à partir de n'importe quel espace de noms. Il fait référence à l' adresse external-secrets serviceAccount pour s'authentifier auprès d'AWS Secrets Manager.

Valider la création de la ressource ClusterSecretStore

• Enfin, pour extraire le secret demo-datacamp-ESO d'AWS Secrets Manager, déployez la ressource personnalisée ExternalSecret. Nous allons extraire la valeur de la clé password. Enregistrez ce qui suit sur external-secret.yaml et créez la ressource.

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: demo-datacamp-secret
  namespace: default  # Change to your target namespace
spec:
  refreshInterval: 1h # How often to refresh the secret
  secretStoreRef:
    name: cluster-secret-store # This references your ClusterSecretStore
    kind: ClusterSecretStore
  target:
    name: demo-datacamp-k8s-secret # The name of the resulting Kubernetes Secret
    creationPolicy: Owner # ESO manages lifecycle of the K8s secret
  data:
    - secretKey: password # Key name in the Kubernetes Secret
      remoteRef:
        key: demo-datacamp-ESO # AWS Secrets Manager secret name
        property: password # Key in the AWS secret JSON object

kubectl create -f external-secret.yaml
kubectl get externalsecrets
kubectl get secrets

Vérifier que le secret a été récupéré avec succès

L'image ci-dessus montre que la valeur top_secret_password de la clé password a été récupérée avec succès dans AWS Secrets Manager et qu'un secret Kubernetes contenant cette valeur a été créé.

Meilleures pratiques pour le développement des cartes Helm

Au fur et à mesure que nous utilisons Helm au-delà de l'installation de cartes de base, il est important de suivre les meilleures pratiques qui favorisent la maintenabilité, la réutilisation et la fiabilité. 

Cette section couvre les pratiques de développement clés, telles que l'utilisation des plugins Helm pour étendre les fonctionnalités, la structuration des graphiques pour la réutilisation, la validation de nos graphiques à l'aide d'outils d'analyse et la gestion efficace des versions et des dépendances.

Plugins Helm

Les plugins Helm sont un moyen puissant d'étendre les fonctionnalités de base de Helm et de les adapter à votre flux de travail. Ils nous permettent d'ajouter des commandes personnalisées et d'intégrer des outils externes sans modifier Helm lui-même.

Les plugins peuvent être installés à partir d'un dépôt Git, d'une archive ou d'un répertoire local. Une fois installés, ils se comportent comme les commandes natives de Helm. Les plugins Helm sont installés localement sur notre machine, et non sur le cluster Kubernetes. Cela signifie qu'ils améliorent les capacités de notre CLI Helm local et ne nécessitent aucun changement ou déploiement sur le cluster Kubernetes. Chaque utilisateur ou système utilisant Helm doit installer les plugins souhaités indépendamment.

Un plugin commun qui est largement utilisé, en particulier sur les pipelines CI/CD, est helm-diff. Il compare une version Helm à une carte Helm et montre les changements qui seraient appliqués. Cette fonction est particulièrement utile pour prévisualiser les mises à niveau.

# Install the plugin
helm plugin install https://github.com/databus23/helm-diff

# List installed plugins
helm plugin list

# View the changes for an upgrade
helm diff upgrade datacamp-demo-helm ./demo-helm --set image.tag="1.26"

Sortie des commandes du plugin helm

Sortie de la commande helm diff

Structurer des graphiques réutilisables

Au fur et à mesure que notre utilisation de Helm augmente, il devient crucial de structurer nos graphiques pour qu'ils puissent être réutilisés. Un diagramme Helm bien structuré favorise la cohérence, simplifie la maintenance et permet des modèles de déploiement modulaires entre les projets. Voici deux conseils :

Utiliser des modèles et des aides

Comme le montre la sous-section "Personnalisation des modèles" de la section "Création de votre premier graphique à barre", nous avons exploité le fichier _helpers.tpl pour ajouter un sélecteur supplémentaire à la ressource deployment et des étiquettes à toutes les ressources. L'utilisation de modèles d'aide permet d'éviter les doublons et fournit ainsi une source unique de vérité pour les extraits couramment réutilisés. Cela améliore la cohérence de votre tableau et facilite la maintenance - toutes les modifications futures ne doivent être effectuées qu'à un seul endroit.

Diviser les grands graphiques en sous-groupes

Si notre application est constituée de plusieurs composants faiblement couplés (par exemple, une application web, une base de données et Redis), envisagez de diviser le diagramme en sous-groupes. Placez-les dans le dossier charts/ et gérez-les comme des dépendances via Chart.yaml.

dependencies:
  - name: redis
    version: 17.1.2
    repository: https://charts.bitnami.com/bitnami

Lancez l'application helm dependency update pour extraire ces sous-graphiques. Cela permet de gérer chaque composant de manière indépendante et favorise la réutilisation dans différents projets.

Mise en place d'une chartreuse et validation des graphiques

Avant de déployer un graphique Helm sur un cluster Kubernetes, il est important de s'assurer que le graphique est bien structuré, syntaxiquement correct et logique. Helm fournit des outils intégrés pour nous aider à détecter rapidement les problèmes par le biais de linting et de tests.

La commande helm lint analyse notre tableau pour y déceler les erreurs courantes et les violations des meilleures pratiques. Il vérifie la syntaxe des modèles, la structure des fichiers graphiques et la présence de champs obligatoires dans Chart.yaml.

helm lint ./demo-helm

Sortie de la commande helm lint

Si nous modifions la valeur de name dans Chart.yaml de "demo-helm" à "demo_helm", il y aura un problème où helm lint sera bloqué.

Modification du "-" en "_"

helm lint : envoi de messages d'avertissement

En lignant et en testant nos diagrammes avant de les déployer, nous réduisons le risque d'échec des versions et de mauvaises configurations en production. Ces pratiques sont essentielles pour maintenir des diagrammes Helm de haute qualité qui se comportent de manière prévisible dans tous les environnements.

Gestion des versions et des dépendances

Au fur et à mesure que nos cartes Helm évoluent et dépendent d'autres cartes, il devient essentiel de gérer les versions de manière cohérente et de suivre les dépendances avec précision. Helm fournit des mécanismes intégrés pour prendre en charge cela grâce au versionnage sémantique, au fichier Chart.lock et aux dépendances Chart.yaml.

Helm utilise le Semantic Versioning pour les versions des cartes. La version d'une carte est définie dans Chart.yaml sous la clé version:

Version graphique

Le versionnage sémantique suit le format : MAJOR.MINOR.PATCH

• Changements majeurs
• MINOR - ajouts de fonctionnalités rétrocompatibles
• PATCH - corrections de bogues rétrocompatibles

La version du graphique doit être incrémentée chaque fois que des modifications sont apportées au graphique lui-même, y compris à ses modèles, à ses valeurs ou même à la version de l'application. Parallèlement, la version de l'application reflète la version de l'application réelle déployée par le graphique, généralement alignée sur la balise d'image utilisée dans le graphique. Il doit être mis à jour chaque fois que l'image de l'application est modifiée.

Une bonne gestion des versions permet aux équipes de savoir si une mise à niveau est sûre ou si elle nécessite des précautions supplémentaires. Il permet également à Helm de gérer les chemins de mise à niveau et les dépendances de manière plus fiable.

Dans Helm 3, que nous utilisons depuis le début de cet article, les dépendances sont définies directement dans le fichier Chart.yaml, dans la section dependencies. Il n'est pas inclus par défaut lorsque nous créons le graphique. Il remplace le fichier requirements.yaml de Helm 2.

Dépendances définies dans Chart.yaml

Le fichier Chart.lock est automatiquement généré lorsque vous exécutez helm dependency update. Il agit comme un fichier de verrouillage dans de nombreux gestionnaires de paquets, en enregistrant les versions exactes de chaque dépendance telle que définie dans la section dependencies de Chart.yaml. Cela garantit des constructions reproductibles et un comportement cohérent entre les environnements et les équipes.

Contenu de Chart.lock

Si vous connaissez Terraform, le concept est similaire au fichier .terraform.lock.hcl, qui verrouille les versions des fournisseurs. Bien que les formats et les écosystèmes sous-jacents diffèrent, tous deux verrouillent les versions des dépendances afin de garantir la stabilité et la reproductibilité.

Conclusion

Les cartes Helm offrent un moyen puissant et standardisé de packager, configurer et déployer des applications sur Kubernetes. Tout au long de cet article, nous avons exploré ce qu'est un diagramme Helm, comment il est structuré et comment il simplifie le processus de déploiement dans différents environnements.

Nous avons passé en revue les principales étapes :

• Création de votre premier graphique Helm en utilisant helm create.
• Personnalisation des configurations à l'aide de values.yaml et de paramètres spécifiques à l'environnement.
• Déployer et gérer les versions à l'aide de commandes telles que helm install, helm upgrade, et helm rollback.
• Suivre les meilleures pratiques telles que les diagrammes de linting, la structuration de composants réutilisables, le traitement sécurisé des secrets et la gestion efficace des versions et des dépendances.

Au fur et à mesure que vous prenez de l'assurance en travaillant avec Helm, prenez le temps d'explorer le vaste écosystème de cartes Helm publiques, hébergées parpar des communautés et des fournisseurs. Ces tableaux peuvent accélérer vos déploiements et servir de références précieuses pour votre propre développement.

Enfin, envisagez d'apporter vos graphiques à la communauté. Qu'il s'agisse d'un outil interne personnalisé ou d'une version bien packagée d'un projet open-source, vos graphiques peuvent aider les autres à se déployer plus efficacement et de manière plus cohérente dans le monde Kubernetes.

Helm simplifie Kubernetes - une carte à la fois.

• Si vous envisagez de passer une certification Kubernetes, consultez ceblog sur Kubernetes Certification Guide : Examens, conseils et ressources d'étude. 
• Pour un parcours d'apprentissage structuré qui combine les fondamentaux de Docker et de Kubernetes, consultez notre cursus sur la conteneurisation et la virtualisation.
• Améliorez vos compétences Git pour mieux gérer les valeurs et les fichiers de configuration de Helm grâce à nos cours Introduction à Git et Intermédiaire Git.