Packaging et distribution

Helm : Le gestionnaire de packages pour Kubernetes

Helm est souvent décrit comme le “gestionnaire de packages pour Kubernetes”, similaire à apt pour Ubuntu ou yum pour Red Hat. Il permet de simplifier le déploiement et la gestion d’applications complexes sur Kubernetes.

Pourquoi utiliser Helm ?

• Templating : Helm utilise des templates pour générer des manifestes YAML Kubernetes, permettant de paramétrer les déploiements
• Réutilisabilité : Les Charts Helm peuvent être partagés et réutilisés entre différents environnements
• Gestion des versions : Helm garde un historique des déploiements et permet de faire des rollbacks facilement
• Dépendances : Gestion automatique des dépendances entre les différents composants d’une application

Concepts principaux

• Chart : Un package Helm contenant tous les manifestes Kubernetes nécessaires pour déployer une application
• Release : Une instance d’un Chart déployé sur un cluster Kubernetes
• Values : Fichier de configuration permettant de personnaliser le déploiement

Nous ne pouvons pas parler de Helm, sans évoquer ArtifactHub, qui est un référentiel global contenant de nombreux Charts Helm prêts à être déployés.

Le schéma suivant donne un aperçu du fonctionnement de Helm : plusieurs fichiers source sont utilisés pour générer les manifestes finaux.

Installation et utilisation basique

# Installation d'un Chart depuis un repository
helm install my-release bitnami/nginx

# Mise à jour d'une release
helm upgrade my-release bitnami/nginx

# Rollback vers une version précédente
helm rollback my-release 1

Implication pour la VotingApp

Comme nous l’avons vu précédemment, il est possible de déployer la VotingApp en utilisant une liste de spécifications YAML. Helm rend ce déploiement plus dynamique car il permet d’utiliser un langage de templating qui pourra notamment lire des valeurs de configuration depuis un fichier YAML. Pour packager une application avec Helm, il est nécessaire de respecter une arborescence de répertoires / fichiers.

Kustomize : Configuration sans templates

Kustomize propose une approche différente pour gérer les configurations Kubernetes. Au lieu d’utiliser des templates, il permet de personnaliser des manifestes YAML de base en appliquant des “patches”.

Avantages de Kustomize

• Approche déclarative : Pas de logique de templating complexe
• Intégré à kubectl : Disponible nativement depuis kubectl 1.14
• Composition : Possibilité de composer plusieurs configurations
• Overlay : Système d’overlay pour différents environnements (dev, staging, prod)

Structure typique

├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
└── overlays/
    ├── dev/
    │   └── kustomization.yaml
    └── prod/
        └── kustomization.yaml

Utilisation

# Déploiement avec kustomize
kubectl apply -k overlays/prod/

# Prévisualisation des manifestes générés
kubectl kustomize overlays/prod/

Helm vs Kustomize : Quand utiliser quoi ?

• Helm : Idéal pour des applications complexes avec de nombreux paramètres de configuration, ou quand vous voulez réutiliser des Charts existants de la communauté
• Kustomize : Parfait pour des configurations plus simples, quand vous voulez garder le contrôle total sur vos manifestes YAML, ou pour des équipes qui préfèrent éviter la complexité du templating