Kustomize : Factorisez vos manifestes Kubernetes

Mise à jour : 17/02/2025

Gérer les manifests Kubernetes peut vite devenir un casse-tête. Entre les environnements (développement, staging, production), les configurations spécifiques et les mises à jour des applications, il est tentant de dupliquer des fichiers YAML à l’infini. Pourtant, cette approche devient vite ingérable. C’est là qu’intervient Kustomize.

Qu’est-ce que Kustomize ?

Kustomize est un outil natif intégré à Kubectl qui permet de personnaliser des fichiers YAML sans utiliser de templates. Contrairement à Helm, qui repose sur un système de chartes avec des valeurs dynamiques, Kustomize utilise des patches et des overlays pour modifier des configurations existantes.

L’idée principale est simple : au lieu de dupliquer des fichiers YAML, on applique des modifications ciblées à une base commune. Cela permet de gérer plusieurs environnements sans complexifier la maintenance des manifests.

Pourquoi utiliser Kustomize ?

Avec Kustomize, vous pouvez :

Éviter la duplication (DRY) des fichiers YAML en réutilisant une base commune.
Personnaliser les déploiements en appliquant des overlays spécifiques à chaque environnement.
Gérer les secrets et les ConfigMaps sans les inclure directement dans mes manifests.
Modifier facilement les images et les labels d’un déploiement Kubernetes.

Différences entre Kustomize et Helm

Voici un tableau comparatif des différences entre Kustomize et Helm :

Critère	Kustomize	Helm
Approche	Patch des fichiers YAML	Templates avec valeurs dynamiques
Complexité	Simple et natif	Plus puissant mais plus complexe
Gestion des dépendances	Pas de gestion intégrée	Support des chart dependencies
Utilisation avec `kubectl`	Oui (intégré depuis v1.14)	Non, nécessite `helm`
Apprentissage	Facile pour débutants	Peut être complexe

Si je veux juste modifier mes manifests existants sans apprendre un nouvel outil, Kustomize est la solution idéale. Pour des déploiements plus avancés avec gestion des dépendances, Helm reste plus adapté.

Installation de Kustomize

Kustomize est intégré à kubectl depuis la version 1.14. Vous n’avez donc pas besoin de l’installer séparément.

Concepts de Kustomize

Pour gérer efficacement les configurations Kubernetes, il est essentiel de comprendre les concepts fondamentaux de Kustomize. Cet outil offre une approche structurée pour personnaliser et déployer des ressources Kubernetes sans dupliquer les fichiers YAML.

Le fichier `kustomization.yaml`

Au cœur de Kustomize se trouve le fichier kustomization.yaml. Ce fichier définit comment assembler et personnaliser les ressources Kubernetes. Voici les principaux champs que l’on peut y trouver :

resources : liste des fichiers ou répertoires contenant les manifests à inclure.
patches : modifications à appliquer aux ressources existantes.
configMapGenerator et secretGenerator : pour générer des ConfigMaps et Secrets à partir de fichiers ou de littéraux.
labels et annotations : labels et annotations à ajouter à toutes les ressources.

Bases et Overlays

Kustomize utilise une hiérarchie de configurations :

Base : ensemble de ressources communes à plusieurs environnements.
Overlay : personnalisation spécifique à un environnement (développement, staging, production) qui s’appuie sur une base.

Cette structure permet de réutiliser les configurations et de les adapter selon les besoins sans duplication.

Générateurs et Transformateurs

Kustomize propose des outils pour créer et modifier des ressources :

Générateurs : créent des ConfigMaps et des Secrets à partir de sources externes.
Transformateurs : modifient les ressources existantes, par exemple en ajoutant des labels ou en changeant les noms.

Patches

Les patches permettent d’appliquer des modifications ciblées aux ressources.

Exemple simple d’utilisation de Kustomize

Nous commençons par un exemple simple pour comprendre comment Kustomize fonctionne. Nous allons créer un deployement et le personnaliser pour deux environnements : dev et prod.

Voici l’arborescence de notre projet :

kustomize-example/
├── base/
│   ├── kustomization.yaml
│   ├── deployement.yaml
├── overlays/
│   ├── dev/
│   │   ├── kustomization.yaml
│   │   ├── deployement-patch.yaml
│   ├── prod/
│   │   ├── kustomization.yaml
│   │   ├── deployement-patch.yaml

Création de la base

Commencer par créer le répertoire base/ dans le dossier de votre projet :

mkdir base

Dans ce répertoire, déposer le fichier principal de la déclaration du namespace deployment.yaml :

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

On définit ensuite la configuration de base dans le fichier base/kustomization.yaml :

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - deployment.yaml

On déclare la ressource deployment.yaml dans le fichier kustomization.yaml.

Création des overlays pour Dev et Prod

Nous allons maintenant définir des overlays pour personnaliser le Namespace selon l’environnement.

Commencez par créer les répertoires dev/ et prod/ dans le dossier overlays/.

mkdir -p overlays/{dev,prod}

Créez ensuite les fichiers namespace-patch.yaml dans les répertoires dev/ et prod/. Pour le dev, nous allons renommer le namespace en my-app-dev, et pour le prod, en my-app-prod.

Le fichier deployment-patch.yaml pour dev :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 1

Ici on modifie le nombre de réplicas et on ajoute un label env: dev.

Maintenant passons au fichier deployment-patch.yaml pour la prod :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3

On créé ensuite les fichiers kustomization.yaml dans les répertoires dev/ et prod/ pour appliquer les patches :

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - ../../base

patches:
  - path: deployment-patch.yaml

Teste de la configuration

On peut maintenant tester Kustomize en générant les fichiers YAML. On commence par le dev :

kubectl kustomize overlays/dev/

Résultat produit :

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

Pour la prod :

kubectl kustomize overlays/prod/

Résultat attendu :

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

Vous remarquerez que le nombre de réplicas est différent pour dev et prod, et que les labels sont adaptés à chaque environnement.

Comment gérer les namespaces avec Kustomize ?

Pour gérer les namespaces avec Kustomize, il suffit d’ajouter dans le fichier kustomization.yaml de chaque overlay le champ namespace :

namespace: my-app-dev

Pour le dev et :

namespace: my-app-prod

Pour la prod.

Lançons à nouveau la commande kubectl kustomize overlays/prod/ pour voir le résultat.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: my-namespace-prod
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - image: nginx:latest
        name: my-app
        ports:
        - containerPort: 80

Le namespace est bien pris en compte dans le manifest du déploiement.

Plus de personnalisation avec Kustomize

Kustomize permet de personnaliser les ressources Kubernetes de plusieurs manières sans modifier directement les fichiers YAML d’origine. Ces customisations sont définies dans le fichier kustomization.yaml.

Ajout d’un préfixe (`namePrefix`)

On peut ajouter un préfixe à toutes les ressources définies dans un kustomization.yaml :

namePrefix: dev-

Une ressource Deployment nommée web-app deviendra dev-web-app.

Ajout d’un suffixe (`nameSuffix`)

De la même manière, on peut ajouter un suffixe :

nameSuffix: -v1

Une ressource web-app deviendra web-app-v1.

Ajouter une annotation commune (`commonAnnotations`)

On peut aussi ajouter une annotation :

commonAnnotations:
  owner: "admin@company.com"

Toutes les ressources auront cette annotation.

Créer une `ConfigMap` avec `configMapGenerator`

Au lieu d’écrire un fichier YAML à la main, on peut générer une ConfigMap directement :

configMapGenerator:
  - name: app-config
    literals:
      - ENV=production
      - LOG_LEVEL=debug

Cela génère une ConfigMap nommée app-config contenant les clés ENV et LOG_LEVEL.

Créer un `Secret` avec `secretGenerator`

De la même façon, on peut générer un Secret :

secretGenerator:
  - name: db-secret
    literals:
      - PASSWORD=supersecurisé
    type: Opaque

Cela génère un Secret contenant PASSWORD=supersecurisé.

Modifier les images dans les `Deployments`

Avec images, on peut modifier le nom ou la version d’une image sans modifier le manifeste :

images:
  - name: nginx
    newName: my-nginx
    newTag: "1.21"

Une image nginx:latest sera remplacée par my-nginx:1.21.

Conclusion

Kustomize est un outil puissant pour gérer les configurations Kubernetes sans duplication de fichiers YAML. En utilisant des bases et des overlays, on peut personnaliser les ressources pour chaque environnement sans complexifier la maintenance.

Si vous cherchez une solution simple et native pour gérer vos manifests Kubernetes, Kustomize est l’outil qu’il vous faut. Pour des déploiements plus complexes avec gestion des dépendances, Helm reste une alternative intéressante. On peut aussi combiner les deux pour tirer le meilleur des deux mondes. Cela fera l’objet d’un prochain guide.