Kubernetes : Optimisez le Déploiement de vos Applications avec Helm pour une Gestion Efficace

Découvrez comment Kubernetes et Helm optimisent la gestion de vos déploiements d’applications. Simplifiez les configurations, améliorez la cohérence des déploiements et alignez-vous avec les principes DevOps pour une gestion efficace et agile de vos applications dans Kubernetes.

Kubernetes est aujourd’hui la référence incontournable pour l’orchestration de conteneurs. Il offre une multitude de moyens pour déployer des applications dans un cluster. Bien que l’utilisation de fichiers YAML, ou manifestes, soit souvent la méthode de départ pour les nouveaux utilisateurs de Kubernetes, cette approche peut rapidement se transformer en casse-tête.

Chaque environnement de déploiement nécessite des ajustements spécifiques, rendant la gestion des configurations complexe et propice aux erreurs. De plus, dans une démarche DevOps où l’efficacité et l’automatisation sont des piliers, le partage et la réutilisation des manifestes Kubernetes deviennent des défis majeurs. Chaque développeur ou opérateur doit adapter ces fichiers à leur environnement, ce qui complique la maintenance et freine la collaboration. Cette complexité peut non seulement ralentir les déploiements, mais aussi augmenter le risque d’erreurs coûteuses, contredisant ainsi les principes fondamentaux du DevOps.

Pour surmonter ces défis, Helm s’impose comme une solution clé dans l’écosystème Kubernete pour la gestion de vos applications.

Helm : Qu’est-ce que c’est ?

Helm est un gestionnaire de packages pour Kubernetes, conçu pour simplifier le déploiement et la gestion des applications dans un cluster Kubernetes. En utilisant des “charts”, qui sont des ensembles de fichiers préconfigurés, Helm permet d’automatiser et de standardiser le processus de déploiement, rendant ainsi la gestion des applications conteneurisées plus fluide et moins sujette aux erreurs.

"Helm is the best way to find, share, and use software built for Kubernetes." - https://helm.sh/

Les charts Helm encapsulent toutes les configurations nécessaires, telles que les déploiements, services, et volumes persistants, en un seul paquet réutilisable. Cela permet aux équipes DevOps de partager facilement des configurations, de gérer les versions, et de maintenir la cohérence à travers différents environnements.

En réduisant la complexité des configurations YAML et en facilitant les mises à jour, Helm joue un rôle crucial dans l’efficacité et l’automatisation des pratiques DevOps.

Helm Charts : Qu’est-ce que c’est et comment les utiliser pour Kubernetes ?

Définition d'un Helm Chart

Un Helm Chart est un ensemble de fichiers structurés qui définissent de manière cohérente et reproductible les ressources Kubernetes nécessaires pour déployer une application. Concrètement, un chart contient des fichiers YAML préconfigurés qui décrivent tous les composants de votre application, tels que les déploiements, services, volumes et autres ressources Kubernetes essentielles.

Cette approche modulaire centralise et standardise les configurations tout en offrant une flexibilité considérable pour adapter les déploiements à divers environnements. Un aspect crucial des Helm Charts est leur capacité à être personnalisés grâce au système de templating GoTemplate. Ce moteur de templating intégré permet de créer des modèles dynamiques pour vos fichiers YAML, évitant ainsi la duplication des fichiers pour chaque environnement (développement, staging, production).

En utilisant des variables dans vos templates et en les remplaçant par des valeurs spécifiques définies dans un fichier values.yaml, vous simplifiez la gestion et la personnalisation des déploiements.

Fonctionnement d'un Helm Chart

Pour illustrer l’utilisation de Helm, supposons que vous ayez besoin de déployer NGINX avec différents paramètres pour les environnements de développement et de production.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-nginx
  labels:
    app: nginx
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:{{ .Values.nginxVersion }}
        ports:
        - containerPort: 80
        env:
        - name: CONFIG_SETTING1
          value: {{ .Values.config.setting1 }}
        - name: API_KEY
          valueFrom:
            secretKeyRef:
              name: {{ .Release.Name }}-secret
              key: apiKey

Ce fichier définit les valeurs par défaut si aucun autre n'est spécifié :

replicaCount: 2
nginxVersion: "1.21.0"
config:
  setting1: "default-setting"
secret:
  apiKey: "default-secret-key"
ingress:
  host: example.com
autoscaling:
  minReplicas: 2
  maxReplicas: 5

Le fichier values-dev.yaml va personnaliser les valeurs pour l'environnement de développement :

replicaCount: 1
nginxVersion: "1.21.0"
config:
  setting1: "dev-setting"
secret:
  apiKey: "dev-secret-key"
ingress:
  host: dev.example.com

Le fichier values-prod.yaml va définir la customisation pour l'environnement de production :

replicaCount: 5
nginxVersion: "1.21.0"
config:
  setting1: "prod-setting"
secret:
  apiKey: "prod-secret-key"
ingress:
  host: prod.example.com
autoscaling:
  minReplicas: 3
  maxReplicas: 10

Pour déployer l'application avec Helm, on pourra alors spécifier le bon fichier values à utiliser :

# Environnement de développement
$ helm install nginx ./nginx-chart -f values-dev.yaml
# Environnement de production
$ helm install nginx ./nginx-chart -f values-prod.yaml

Structure d'un Helm Chart

Un Helm Chart est organisé de manière à faciliter la gestion des configurations Kubernetes. Pour comprendre la structure d’un Helm Chart, reprenons l'exemple NGINX précedent. Habituellement, vous auriez plusieurs manifestes différents pour définir les composants Kubernetes nécessaires à votre application :

nginx/
├── configmap.yaml
├── deployment.yaml
├── ingress.yaml
└── service.yaml

Lorsqu’on crée un Helm Chart pour ce déploiement NGINX, la structure du répertoire sera comme suit :

nginx-chart/
│
├── Chart.yaml
├── charts/
├── templates/
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   ├── configmap.yaml
│   ├── ingress.yaml
│   ├── service.yaml
│   └── tests/
│       └── test-connection.yaml
└── values.yaml

• .helmignore : Ce fichier fonctionne comme un .gitignore. C'est à dire qu'il va permettre de définir les fichiers et répertoires à exclure de l’archive du chart lors de la création du paquet Helm. Cela permet de ne pas inclure des fichiers inutiles ou temporaires dans le chart.
• Chart.yaml : Le fichier Chart.yaml contient les métadonnées du chart, telles que le nom, la version, et une description du chart. Par exemple :

apiVersion: v2
name: nginx-chart
description: A Helm chart for deploying Nginx on Kubernetes
version: 1.0.0

• values.yaml : Le fichier values.yaml est utilisé pour définir les valeurs par défaut pour les modèles YAML contenus dans le chart. Vous y spécifiez des paramètres comme le nom de l’image, le nombre de répliques, et d’autres configurations :

replicaCount: 2
image:
  repository: nginx
  tag: "1.21.0"
ingress:
  enabled: true
  host: example.com

• charts/ : Ce répertoire est utilisé pour les dépendances de chart. Si votre chart principal dépend d’autres charts, ceux-ci seront stockés dans ce répertoire. Par défaut, ce répertoire est vide.
• templates/ : Le répertoire templates/ contient les fichiers YAML qui sont utilisés comme modèles pour créer des objets Kubernetes. Ces fichiers utilisent la syntaxe GoTemplate pour injecter des valeurs à partir de values.yaml.
• _helpers.tpl (Facultatif) : Ce fichier contient des fonctions et des sous-modèles réutilisables pour les templates Helm. Par exemple :

{{- define "nginx-chart.fullname" -}}
{{ .Release.Name }}-nginx
{{- end -}}

• NOTES.txt (Facultatif) : Ce fichier est imprimé après la réussite de l’installation du chart. Il peut contenir des instructions ou des informations utiles :

Nginx has been installed successfully!
Access your Nginx application using the following URL:
http://{{ .Values.ingress.host }}

• tests/test-connection.yaml (Facultatif) : Ce fichier permet de définir des tests pour vérifier que votre chart fonctionne comme prévu après l’installation. Par exemple :

apiVersion: v1
kind: Pod
metadata:
  name: test-connection
spec:
  containers:
  - name: curl
    image: curlimages/curl:latest
    command: ['curl']
    args: ['http://{{ .Release.Name }}-nginx:80']

Cette structure vous permet de gérer vos configurations Kubernetes de manière modulaire et réutilisable, tout en facilitant le déploiement et la maintenance de vos applications.

Créer un Helm Chart à partir de Zéro

Pour gagner du temps et partir d'une bonne base, il est possible de générer une base de Helm chart avec la commande Helm :

$ helm create nginx
Creating nginx

La commande helm create va générer une structure de base. Celle-ci va comprendre les fichiers essentiels tel que Chart.yaml, values.yaml et un dossier templates/ pour vos fichiers de configurations Kubernetes.

Voici la structure que génère la commande :

.
├── Chart.yaml
├── charts
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   ├── hpa.yaml
│   ├── ingress.yaml
│   ├── service.yaml
│   ├── serviceaccount.yaml
│   └── tests
│       └── test-connection.yaml
└── values.yaml

Chart.yaml

apiVersion: v2
name: nginx
description: A Helm chart for Kubernetes

# A chart can be either an 'application' or a 'library' chart.
#
# Application charts are a collection of templates that can be packaged into versioned archives
# to be deployed.
#
# Library charts provide useful utilities or functions for the chart developer. They're included as
# a dependency of application charts to inject those utilities and functions into the rendering
# pipeline. Library charts do not define any templates and therefore cannot be deployed.
type: application

# This is the chart version. This version number should be incremented each time you make changes
# to the chart and its templates, including the app version.
# Versions are expected to follow Semantic Versioning (https://semver.org/)
version: 0.1.0

# This is the version number of the application being deployed. This version number should be
# incremented each time you make changes to the application. Versions are not expected to
# follow Semantic Versioning. They should reflect the version the application is using.
# It is recommended to use it with quotes.
appVersion: "1.16.0"

templates

La commande helm create génère automatiquement des manifestes YAML de base que vous pouvez utiliser comme modèle. Vous avez la possibilité de les personnaliser et d’ajouter d’autres fichiers en fonction des besoins spécifiques de votre application.

values.yaml

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

replicaCount: 1

image:
  repository: nginx
  pullPolicy: IfNotPresent
  # Overrides the image tag whose default is the chart appVersion.
  tag: ""

imagePullSecrets: []
nameOverride: ""
fullnameOverride: ""

serviceAccount:
  # Specifies whether a service account should be created
  create: true
  # Automatically mount a ServiceAccount's API credentials?
  automount: true
  # Annotations to add to the service account
  annotations: {}
  # The name of the service account to use.
  # If not set and create is true, a name is generated using the fullname template
  name: ""

podAnnotations: {}
podLabels: {}

podSecurityContext: {}
  # fsGroup: 2000

securityContext: {}
  # capabilities:
  #   drop:
  #   - ALL
  # readOnlyRootFilesystem: true
  # runAsNonRoot: true
  # runAsUser: 1000

service:
  type: ClusterIP
  port: 80

ingress:
  enabled: false
  className: ""
  annotations: {}
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  hosts:
    - host: chart-example.local
      paths:
        - path: /
          pathType: ImplementationSpecific
  tls: []
  #  - secretName: chart-example-tls
  #    hosts:
  #      - chart-example.local

resources: {}
  # We usually recommend not to specify default resources and to leave this as a conscious
  # choice for the user. This also increases chances charts run on environments with little
  # resources, such as Minikube. If you do want to specify resources, uncomment the following
  # lines, adjust them as necessary, and remove the curly braces after 'resources:'.
  # limits:
  #   cpu: 100m
  #   memory: 128Mi
  # requests:
  #   cpu: 100m
  #   memory: 128Mi

livenessProbe:
  httpGet:
    path: /
    port: http
readinessProbe:
  httpGet:
    path: /
    port: http

autoscaling:
  enabled: false
  minReplicas: 1
  maxReplicas: 100
  targetCPUUtilizationPercentage: 80
  # targetMemoryUtilizationPercentage: 80

# Additional volumes on the output Deployment definition.
volumes: []
# - name: foo
#   secret:
#     secretName: mysecret
#     optional: false

# Additional volumeMounts on the output Deployment definition.
volumeMounts: []
# - name: foo
#   mountPath: "/etc/foo"
#   readOnly: true

nodeSelector: {}

tolerations: []

affinity: {}

Valider le Helm Chart

Pour valider un Helm Chart avant de le déployer dans un cluster Kubernetes, vous pouvez utiliser plusieurs méthodes pour vous assurer qu’il est correctement configuré et qu’il fonctionnera comme prévu.

La première étape est d’utiliser helm lint pour effectuer une vérification statique de votre Chart. Cette commande analyse le Chart pour détecter les erreurs courantes, comme des fichiers manquants ou des erreurs de syntaxe.

$ helm lint nginx
==> Linting nginx
[INFO] Chart.yaml: icon is recommended

1 chart(s) linted, 0 chart(s) failed

Pour vérifier si votre chart est correct, vous pouvez générer les fichiers YAML à partir des valeurs présentes dans values.yaml :

$ helm template nginx

Pour un test plus poussé, vous pouvez utiliser la commande helm install avec l’option --dry-runpour simuler l’installation de votre Chart sans réellement créer les ressources dans Kubernetes. Cela génère les manifestes Kubernetes basés sur vos templates et vos valeurs, et vous permet de voir ce qui serait déployé dans un cas réel :

$ helm install nginx nginx --dry-run --debug
install.go:222: [debug] Original chart version: ""
install.go:239: [debug] CHART PATH: /tmp/nginx

NAME: nginx
LAST DEPLOYED: Fri Aug 16 10:07:23 2024
NAMESPACE: default
STATUS: pending-install
REVISION: 1
USER-SUPPLIED VALUES:
{}

COMPUTED VALUES:
affinity: {}
autoscaling:
  enabled: false
  maxReplicas: 100
  minReplicas: 1
  targetCPUUtilizationPercentage: 80
fullnameOverride: ""
image:
  pullPolicy: IfNotPresent
  repository: nginx
  tag: ""
imagePullSecrets: []
ingress:
  annotations: {}
  className: ""
  enabled: false
  hosts:
  - host: chart-example.local
    paths:
    - path: /
      pathType: ImplementationSpecific
  tls: []
livenessProbe:
  httpGet:
    path: /
    port: http
nameOverride: ""
nodeSelector: {}
podAnnotations: {}
podLabels: {}
podSecurityContext: {}
readinessProbe:
  httpGet:
    path: /
    port: http
replicaCount: 1
resources: {}
securityContext: {}
service:
  port: 80
  type: ClusterIP
serviceAccount:
  annotations: {}
  automount: true
  create: true
  name: ""
tolerations: []
volumeMounts: []
volumes: []

HOOKS:
---
# Source: nginx/templates/tests/test-connection.yaml
apiVersion: v1
kind: Pod
metadata:
  name: "nginx-test-connection"
  labels:
    helm.sh/chart: nginx-0.1.0
    app.kubernetes.io/name: nginx
    app.kubernetes.io/instance: nginx
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
  annotations:
    "helm.sh/hook": test
spec:
  containers:
    - name: wget
      image: busybox
      command: ['wget']
      args: ['nginx:80']
  restartPolicy: Never
MANIFEST:
---
# Source: nginx/templates/serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: nginx
  labels:
    helm.sh/chart: nginx-0.1.0
    app.kubernetes.io/name: nginx
    app.kubernetes.io/instance: nginx
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
automountServiceAccountToken: true
---
# Source: nginx/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    helm.sh/chart: nginx-0.1.0
    app.kubernetes.io/name: nginx
    app.kubernetes.io/instance: nginx
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
spec:
  type: ClusterIP
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: nginx
    app.kubernetes.io/instance: nginx
---
# Source: nginx/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    helm.sh/chart: nginx-0.1.0
    app.kubernetes.io/name: nginx
    app.kubernetes.io/instance: nginx
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: nginx
      app.kubernetes.io/instance: nginx
  template:
    metadata:
      labels:
        helm.sh/chart: nginx-0.1.0
        app.kubernetes.io/name: nginx
        app.kubernetes.io/instance: nginx
        app.kubernetes.io/version: "1.16.0"
        app.kubernetes.io/managed-by: Helm
    spec:
      serviceAccountName: nginx
      securityContext:
        {}
      containers:
        - name: nginx
          securityContext:
            {}
          image: "nginx:1.16.0"
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
          livenessProbe:
            httpGet:
              path: /
              port: http
          readinessProbe:
            httpGet:
              path: /
              port: http
          resources:
            {}

NOTES:
1. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=nginx,app.kubernetes.io/instance=nginx" -o jsonpath="{.items[0].metadata.name}")
  export CONTAINER_PORT=$(kubectl get pod --namespace default $POD_NAME -o jsonpath="{.spec.containers[0].ports[0].containerPort}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl --namespace default port-forward $POD_NAME 8080:$CONTAINER_PORT

Déployer le Helm Chart

Pour déployer ou mettre à jour votre Chart de manière idempotente, utilisez la commande suivante :

$ helm upgrade --install nginx nginx
Release "nginx" does not exist. Installing it now.
NAME: nginx
LAST DEPLOYED: Fri Aug 16 10:10:20 2024
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
1. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=nginx,app.kubernetes.io/instance=nginx" -o jsonpath="{.items[0].metadata.name}")
  export CONTAINER_PORT=$(kubectl get pod --namespace default $POD_NAME -o jsonpath="{.spec.containers[0].ports[0].containerPort}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl --namespace default port-forward $POD_NAME 8080:$CONTAINER_PORT

Suite au déploiement, une release de l'application a été créee dans le cluster Kubernetes :

$ helm list
NAME 	NAMESPACE	REVISION	UPDATED                              	STATUS  	CHART      	APP VERSION
nginx	default  	1       	2024-08-17 19:02:47.734937 +0200 CEST	deployed	nginx-0.1.0	1.16.0

Après avoir exécuté la commande helm upgrade --install, vérifiez que tout s’est bien passé en utilisant la commande helm status :

$ helm status nginx
NAME: nginx
LAST DEPLOYED: Fri Aug 16 10:10:20 2024
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
1. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=nginx,app.kubernetes.io/instance=nginx" -o jsonpath="{.items[0].metadata.name}")
  export CONTAINER_PORT=$(kubectl get pod --namespace default $POD_NAME -o jsonpath="{.spec.containers[0].ports[0].containerPort}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl --namespace default port-forward $POD_NAME 8080:$CONTAINER_PORT

Cette commande vous donne un aperçu de l’état actuel de votre release, confirmant que le déploiement ou la mise à jour s’est déroulé correctement.

Upgrade & Rollback avec Helm

Helm facilite la gestion des mises à jour (upgrades) et des retours en arrière (rollbacks) de vos applications Kubernetes. Cela vous permet de déployer des changements de manière contrôlée et de revenir facilement à une version antérieure en cas de problème.

Upgrade d'une Release avec Helm

Lorsqu’il s’agit de mettre à jour une application déjà déployée, Helm simplifie le processus avec la commande helm upgrade. Cette commande applique les modifications à la configuration existante sans interrompre le service.

$ helm upgrade nginx-release nginx-chart --set image.tag=1.21.1 --set replicaCount=4
Release "nginx" has been upgraded. Happy Helming!
NAME: nginx
LAST DEPLOYED: Fri Aug 16 10:12:18 2024
NAMESPACE: default
STATUS: deployed
REVISION: 2
NOTES:
1. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=nginx,app.kubernetes.io/instance=nginx" -o jsonpath="{.items[0].metadata.name}")
  export CONTAINER_PORT=$(kubectl get pod --namespace default $POD_NAME -o jsonpath="{.spec.containers[0].ports[0].containerPort}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl --namespace default port-forward $POD_NAME 8080:$CONTAINER_PORT

$ kubectl get pods
NAME                                READY   STATUS    RESTARTS        AGE
nginx-995856cf5-2twbw               1/1     Running   0               9s
nginx-995856cf5-bbtz4               1/1     Running   0               15s
nginx-995856cf5-fsp7x               1/1     Running   0               10s
nginx-995856cf5-wjm4t               1/1     Running   0               15s

Pour garantir que la release est créée si elle n’existe pas déjà, utilisez l’option --install avec helm upgrade :

$ helm upgrade --install nginx-release nginx-chart --set image.tag=1.21.1 --set replicaCount=4

Rollback d'une Release avec Helm

En cas de problème après une mise à jour, Helm permet de revenir facilement à une version précédente grâce à la commande helm rollback.

$ helm list
NAME 	NAMESPACE	REVISION	UPDATED                              	STATUS  	CHART      	APP VERSION
nginx	default  	5       	2024-08-16 10:15:49.454452 +0200 CEST	deployed	nginx-0.1.0	1.16.0

$ helm history nginx
REVISION	UPDATED                 	STATUS    	CHART      	APP VERSION	DESCRIPTION
1       	Fri Aug 16 10:16:46 2024	superseded	nginx-0.1.0	1.16.0     	Install complete
2       	Fri Aug 16 10:17:05 2024	deployed  	nginx-0.1.0	1.16.0     	Upgrade complete

$ kubectl get pods
NAME                                READY   STATUS    RESTARTS      AGE
nginx-995856cf5-5ll8l               1/1     Running   0             18s
nginx-995856cf5-bzlgs               1/1     Running   0             18s
nginx-995856cf5-lj5pb               1/1     Running   0             19s
nginx-995856cf5-qjb84               1/1     Running   0             19s

$ helm rollback nginx 1
Rollback was a success! Happy Helming!

$ helm history nginx
REVISION	UPDATED                 	STATUS    	CHART      	APP VERSION	DESCRIPTION
1       	Fri Aug 16 10:16:46 2024	superseded	nginx-0.1.0	1.16.0     	Install complete
2       	Fri Aug 16 10:17:05 2024	superseded	nginx-0.1.0	1.16.0     	Upgrade complete
3       	Fri Aug 16 10:17:39 2024	deployed  	nginx-0.1.0	1.16.0     	Rollback to 1

$ kubectl get pods
NAME                                READY   STATUS    RESTARTS      AGE
nginx-bbb8c4694-d8zc6               1/1     Running   0             27s

$ helm plugin install https://github.com/databus23/helm-diff

$ helm history nginx
REVISION	UPDATED                 	STATUS    	CHART      	APP VERSION	DESCRIPTION
1       	Fri Aug 16 10:16:46 2024	superseded	nginx-0.1.0	1.16.0     	Install complete
2       	Fri Aug 16 10:17:05 2024	superseded	nginx-0.1.0	1.16.0     	Upgrade complete
3       	Fri Aug 16 10:17:39 2024	deployed  	nginx-0.1.0	1.16.0     	Rollback to 1

$ helm diff revision nginx 2 3
default, nginx, Deployment (apps) has changed:
  # Source: nginx/templates/deployment.yaml
  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: nginx
    labels:
      helm.sh/chart: nginx-0.1.0
      app.kubernetes.io/name: nginx
      app.kubernetes.io/instance: nginx
      app.kubernetes.io/version: "1.16.0"
      app.kubernetes.io/managed-by: Helm
  spec:
-   replicas: 4
+   replicas: 1
    selector:
      matchLabels:
        app.kubernetes.io/name: nginx
        app.kubernetes.io/instance: nginx
    template:
      metadata:
        labels:
          helm.sh/chart: nginx-0.1.0
          app.kubernetes.io/name: nginx
          app.kubernetes.io/instance: nginx
          app.kubernetes.io/version: "1.16.0"
          app.kubernetes.io/managed-by: Helm
      spec:
        serviceAccountName: nginx
        securityContext:
          {}
        containers:
          - name: nginx
            securityContext:
              {}
-           image: "nginx:1.21.1"
+           image: "nginx:1.16.0"
            imagePullPolicy: IfNotPresent
            ports:
              - name: http
                containerPort: 80
                protocol: TCP
            livenessProbe:
              httpGet:
                path: /
                port: http
            readinessProbe:
              httpGet:
                path: /
                port: http
            resources:
              {}

Désinstaller la Release Helm

Pour désinstaller une release Helm, utilisez la commande helm uninstall :

$ helm uninstall nginx

Cette commande supprime la release nginx-release de votre cluster Kubernetes, y compris toutes les ressources associées comme les Pods, Services, ConfigMaps, etc.

Après avoir exécuté la commande de désinstallation, vous pouvez vérifier que toutes les ressources ont été supprimées en utilisant kubectl :

$ kubectl get all -l app.kubernetes.io/instance=nginx

Si la désinstallation a été effectuée avec succès, cette commande ne devrait retourner aucune ressource.

Packager le Helm Chart

Pour distribuer votre Helm Chart et le rendre facilement installable, il est essentiel de le packager correctement. Le packaging permet de regrouper tous les fichiers nécessaires dans une archive tarball (.tgz), simplifiant ainsi la distribution et l’installation de votre application Kubernetes.

Utilisez la commande Helm suivante pour créer un package :

$ helm package nginx
Successfully packaged chart and saved it to: /tmp/nginx-0.1.0.tgz

Pour vérifier que le package est correctement formé, vous pouvez lister son contenu avec :

$ tar -tzf nginx-0.1.0.tgz
nginx/Chart.yaml
nginx/values.yaml
nginx/templates/NOTES.txt
nginx/templates/_helpers.tpl
nginx/templates/deployment.yaml
nginx/templates/hpa.yaml
nginx/templates/ingress.yaml
nginx/templates/service.yaml
nginx/templates/serviceaccount.yaml
nginx/templates/tests/test-connection.yaml
nginx/.helmignore

Une fois le package créé, vous pouvez le publier sur un repository Helm public ou privé. Les repositories Helm permettent aux utilisateurs de trouver et d’installer facilement des charts. Pour ajouter votre chart à un repository, utilisez les commandes suivantes :

helm repo index [chemin_vers_votre_dossier] --url [url_de_votre_repository]

Bonnes Pratiques avec Helm

Helm est un outil puissant pour la gestion des applications Kubernetes, mais pour en tirer le meilleur parti, il est essentiel de suivre certaines bonnes pratiques décrites dans le lien ci-dessous :

Best Practices

Helm - The Kubernetes Package Manager.

Helm

Conclusion

L’adoption de Helm dans votre boîte à outil va marquer un tournant dans la façon dont vous gérer vos applications dans Kubernetes. En nous plongeant les fonctionnalités de Helm, nous avons vu comment il facilite la configuration, le déploiement et la maintenance des applications. Helm apporte une structure modulaire et standardisée qui simplifie l'adaptattion des configurations entres les environnements.

Les Helm charts encapsulent les ressources nécessaires sous forme de fichiers YAML préconfigurés. En comprenant leur structure, nous avons vu comment ces charts permettent une gestion plus cohérente des configurations, tout en offrant la flexibilité nécessaire pour personnaliser les déploiements selon les besoins. La capacité de Helm à intégrer des variables et des templates dynamiques permet d’éviter les duplications inutiles et de gérer les configurations de manière plus efficace.

Nous avons également couvert les aspects pratiques du travail avec Helm, depuis la création de charts jusqu’à leur déploiement et mise à jour. L’utilisation de la commande helm create pour générer des charts de base, la gestion des mises à jour, le débogage avec des outils comme helm lint et helm template, ainsi que le processus de rollback en cas de problème. Cela vous démontre la flexibilité et le contrôle que Helm offre dans le cycle de vie des applications Kubernetes.

En conclusion, Helm s’impose comme une solution incontournable pour optimiser la gestion des déploiements Kubernetes. Il permet non seulement de centraliser et de standardiser les configurations mais aussi de rendre le processus de déploiement plus agile et moins sujet aux erreurs. En adoptant Helm, vous vous alignez avec les meilleures pratiques DevOps, favorisant ainsi une gestion des applications plus efficace, fiable et adaptée aux besoins dynamiques de votre infrastructure.