Volumes applicatifs Kubernetes : partager et injecter vos données

Vos conteneurs ont besoin de partager des fichiers entre eux ? D’accéder à une configuration externe ? De recevoir des secrets ? Les volumes applicatifs permettent de monter des données dans vos Pods — qu’il s’agisse de fichiers temporaires, de configurations projetées ou de données sensibles.

Ce guide couvre les volumes utilisés côté développeur. Pour le stockage persistant géré par les administrateurs (PV, PVC, StorageClass), voir Storage Kubernetes.

Prérequis : concepts des Pods et un cluster fonctionnel.

Ce que vous allez apprendre

• Utiliser emptyDir pour partager des données temporaires entre conteneurs
• Monter un ConfigMap ou un Secret comme fichiers injectés
• Combiner plusieurs sources avec projected
• Comprendre les cycles de vie et limites de chaque type de volume
• Appliquer les bonnes pratiques de sécurité et de permissions

Qu’est-ce qu’un volume Kubernetes ?

Un volume Kubernetes est un espace de stockage monté dans un ou plusieurs conteneurs d’un Pod. Selon son type, il peut être :

• Éphémère : créé avec le Pod, supprimé avec lui (emptyDir)
• Projeté : généré depuis un objet API Kubernetes (ConfigMap, Secret, downwardAPI)
• Lié au nœud : adossé au système de fichiers de la machine hôte (hostPath)

Volumes ≠ stockage persistant

Les volumes applicatifs ne sont pas du stockage persistant. Un emptyDir disparaît avec le Pod, un ConfigMap reflète un objet API, et un hostPath dépend du nœud. Pour la persistance, utilisez des PersistentVolumeClaims.

Pourquoi utiliser des volumes ?

Les données écrites dans le système de fichiers propre au conteneur (writable layer) ne constituent pas une solution fiable pour partager ou conserver des données applicatives. Les volumes Kubernetes fournissent une abstraction dédiée à cet usage :

• Partage : plusieurs conteneurs d’un même Pod peuvent monter le même volume
• Injection : Kubernetes peut pré-remplir le volume avec des configurations ou secrets
• Isolation : le volume existe indépendamment du système de fichiers du conteneur

Types de volumes applicatifs

Type	Nature	Cycle de vie pratique
emptyDir	éphémère	Dure tant que le Pod reste sur le nœud — supprimé si le Pod disparaît
configMap	projeté	Reflète un objet ConfigMap — pas du stockage persistant
secret	projeté	Reflète un objet Secret — pas du stockage persistant
downwardAPI	projeté	Généré à partir des métadonnées du Pod
projected	projeté	Combine ConfigMap, Secret, downwardAPI et serviceAccountToken
hostPath	nœud local	Dépend du nœud — non portable, non résilient

Glissez pour voir

Attention au vocabulaire

Aucun de ces volumes n’est “permanent” au sens stockage durable. Même hostPath, qui persiste sur le nœud, n’offre aucune garantie si le Pod est reschedulé ailleurs.

emptyDir : partage temporaire entre conteneurs

Un volume emptyDir est créé vide quand le Pod démarre et supprimé quand le Pod disparaît du nœud. Idéal pour partager des données temporaires entre conteneurs du même Pod.

Exemple : deux conteneurs qui partagent des données

emptydir-demo.yaml

apiVersion: v1
kind: Pod
metadata:
  name: emptydir-demo
spec:
  containers:
  - name: writer
    image: busybox:1.36
    command: ['sh', '-c', 'echo "Données partagées" > /cache/data.txt && sleep 3600']
    volumeMounts:
    - name: cache-volume
      mountPath: /cache
  - name: reader
    image: busybox:1.36
    command: ['sh', '-c', 'sleep 5 && cat /cache/data.txt && sleep 3600']
    volumeMounts:
    - name: cache-volume
      mountPath: /cache
  volumes:
  - name: cache-volume
    emptyDir: {}

kubectl apply -f emptydir-demo.yaml
kubectl logs emptydir-demo -c reader

Sortie :

Données partagées

Le conteneur reader lit bien le fichier écrit par writer — ils partagent le même volume.

emptyDir en mémoire (RAM)

Pour des performances maximales (cache, scratch space), utilisez la RAM via tmpfs :

volumes:
- name: cache-volume
  emptyDir:
    medium: Memory
    sizeLimit: 100Mi

Impact sur les ressources

Un emptyDir en mémoire utilise la RAM du nœud. Sa consommation compte dans l’usage mémoire du Pod. Selon les limites définies et la pression de ressources sur le nœud, un dépassement peut conduire à une éviction ou à un comportement d’échec lié aux ressources.

Quand utiliser emptyDir

Cas d’usage	Adapté ?
Cache applicatif temporaire	✅ Oui
Scratch space pour calculs intermédiaires	✅ Oui
Partage de fichiers entre conteneurs sidecar	✅ Oui
Stockage de données qui doivent survivre au Pod	❌ Non — utilisez un PVC

Glissez pour voir

ConfigMap : injecter de la configuration

Un ConfigMap monté en volume crée des fichiers — un par clé — dans le répertoire cible. C’est un volume projeté : Kubernetes génère les fichiers à partir d’un objet API.

Créer le ConfigMap

configmap-volume.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  config.json: |
    {
      "database": "postgresql",
      "port": 5432
    }
  settings.ini: |
    [app]
    debug = false
    log_level = info

Monter le ConfigMap

pod-configmap-volume.yaml

apiVersion: v1
kind: Pod
metadata:
  name: configmap-volume-demo
spec:
  containers:
  - name: app
    image: busybox:1.36
    command: ['sh', '-c', 'ls -la /etc/config && cat /etc/config/config.json && sleep 3600']
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
      readOnly: true
  volumes:
  - name: config-volume
    configMap:
      name: app-config

kubectl apply -f configmap-volume.yaml
kubectl apply -f pod-configmap-volume.yaml
kubectl logs configmap-volume-demo

Sortie :

total 0
lrwxrwxrwx    1 root     root            18 Mar 22 10:00 config.json -> ..data/config.json
lrwxrwxrwx    1 root     root            19 Mar 22 10:00 settings.ini -> ..data/settings.ini
{
  "database": "postgresql",
  "port": 5432
}

Chaque clé du ConfigMap devient un fichier (via des liens symboliques pour permettre les mises à jour atomiques).

Monter une seule clé

Pour ne monter qu’un fichier spécifique :

volumes:
- name: config-volume
  configMap:
    name: app-config
    items:
    - key: config.json
      path: app-config.json  # Nom du fichier dans le conteneur

Mise à jour automatique (avec délai)

Les fichiers sont mis à jour automatiquement quand le ConfigMap change. Cependant, ce n’est pas instantané : le délai dépend du kubelet et de sa stratégie de détection des changements (Watch, TTL, ou accès direct API). Il peut aller jusqu’au délai de synchronisation du kubelet (--sync-frequency, 1 minute par défaut) plus le délai de propagation du cache.

Rechargement applicatif

La mise à jour des fichiers ne redémarre pas votre application. Votre code doit surveiller les changements (inotify) ou relire les fichiers périodiquement.

subPath casse la propagation

Avec subPath, les mises à jour du ConfigMap ne sont pas propagées au conteneur. Le fichier garde sa valeur initiale. Utilisez subPath uniquement si vous acceptez cette limitation.

Secret : injecter des données sensibles

Un Secret monté en volume fonctionne comme un ConfigMap, mais pour des données sensibles (credentials, certificats, clés API).

Créer le Secret (avec stringData)

Utilisez stringData pour écrire les valeurs en clair dans le manifest — Kubernetes les encodera automatiquement en base64 :

secret-volume.yaml

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
stringData:
  username: admin
  password: password123

stringData vs data

stringData est plus pratique pour écrire un manifest à la main. Kubernetes stocke ensuite les valeurs encodées en base64 dans l’objet API. Le volume projeté expose les valeurs décodées.

Monter le Secret

pod-secret-volume.yaml

apiVersion: v1
kind: Pod
metadata:
  name: secret-volume-demo
spec:
  containers:
  - name: app
    image: busybox:1.36
    command: ['sh', '-c', 'cat /etc/secrets/username && echo && cat /etc/secrets/password && sleep 3600']
    volumeMounts:
    - name: secret-volume
      mountPath: /etc/secrets
      readOnly: true
  volumes:
  - name: secret-volume
    secret:
      secretName: db-credentials
      defaultMode: 0400  # Lecture seule pour le propriétaire

kubectl apply -f secret-volume.yaml
kubectl apply -f pod-secret-volume.yaml
kubectl logs secret-volume-demo

Sortie :

admin
password123

Le fichier contient la valeur décodée — pas le base64.

Sécurité des Secrets

base64 ≠ chiffrement

Les valeurs d’un Secret ne sont pas protégées par le simple encodage base64. La protection au repos dépend de la configuration de chiffrement du cluster, notamment côté etcd. Vérifiez que le chiffrement est activé dans votre cluster.

Bonnes pratiques :

• Montez toujours les Secrets en readOnly: true
• Définissez des permissions restrictives avec defaultMode: 0400
• Ne loggez jamais le contenu des fichiers secrets
• Envisagez des solutions comme Sealed Secrets ou External Secrets Operator pour la gestion

downwardAPI : métadonnées du Pod

Le volume downwardAPI expose les métadonnées du Pod comme fichiers. Utile pour que l’application connaisse son contexte sans code spécifique Kubernetes.

downward-api-demo.yaml

apiVersion: v1
kind: Pod
metadata:
  name: downward-demo
  labels:
    app: myapp
    version: v1
spec:
  containers:
  - name: app
    image: busybox:1.36
    command: ['sh', '-c', 'cat /etc/podinfo/labels && echo "---" && cat /etc/podinfo/name && sleep 3600']
    volumeMounts:
    - name: podinfo
      mountPath: /etc/podinfo
      readOnly: true
  volumes:
  - name: podinfo
    downwardAPI:
      items:
      - path: labels
        fieldRef:
          fieldPath: metadata.labels
      - path: name
        fieldRef:
          fieldPath: metadata.name
      - path: namespace
        fieldRef:
          fieldPath: metadata.namespace
      - path: cpu-limit
        resourceFieldRef:
          containerName: app
          resource: limits.cpu

Champs disponibles

fieldPath	Contenu
metadata.name	Nom du Pod
metadata.namespace	Namespace
metadata.labels	Labels (format key="value")
metadata.annotations	Annotations
metadata.uid	UID du Pod
spec.nodeName	Nom du nœud
spec.serviceAccountName	ServiceAccount
status.podIP	IP du Pod

Glissez pour voir

projected : combiner plusieurs sources

Un volume projected permet de monter plusieurs sources (ConfigMap, Secret, downwardAPI, serviceAccountToken) dans un seul répertoire. C’est la méthode standard pour agréger des données de sources différentes.

projected-demo.yaml

apiVersion: v1
kind: Pod
metadata:
  name: projected-demo
  labels:
    app: myapp
spec:
  containers:
  - name: app
    image: busybox:1.36
    command: ['sh', '-c', 'ls -la /etc/all-config && sleep 3600']
    volumeMounts:
    - name: all-config
      mountPath: /etc/all-config
      readOnly: true
  volumes:
  - name: all-config
    projected:
      sources:
      - configMap:
          name: app-config
          items:
          - key: config.json
            path: config.json
      - secret:
          name: db-credentials
          items:
          - key: password
            path: db-password
      - downwardAPI:
          items:
          - path: pod-name
            fieldRef:
              fieldPath: metadata.name

Résultat dans /etc/all-config :

config.json    (depuis ConfigMap)
db-password    (depuis Secret)
pod-name       (depuis downwardAPI)

Cas d'usage typique

projected est particulièrement utile pour monter le token ServiceAccount, des certificats TLS (Secret) et une configuration applicative (ConfigMap) dans un même répertoire.

hostPath : accès au système de fichiers du nœud

Un volume hostPath monte un répertoire ou fichier du nœud hôte dans le Pod.

hostpath-demo.yaml

apiVersion: v1
kind: Pod
metadata:
  name: hostpath-demo
spec:
  containers:
  - name: logger
    image: busybox:1.36
    command: ['sh', '-c', 'ls /var/log && sleep 3600']
    volumeMounts:
    - name: host-logs
      mountPath: /var/log
      readOnly: true
  volumes:
  - name: host-logs
    hostPath:
      path: /var/log
      type: Directory

Types de hostPath

Type	Comportement
"" (vide)	Pas de vérification
DirectoryOrCreate	Crée le répertoire s’il n’existe pas
Directory	Le répertoire doit exister (échec sinon)
FileOrCreate	Crée le fichier s’il n’existe pas
File	Le fichier doit exister (échec sinon)

Glissez pour voir

Risques majeurs de hostPath

hostPath expose directement une partie du système de fichiers du nœud au Pod. Cela :

• Réduit l’isolation entre le Pod et l’hôte
• Crée un couplage fort au nœud — le Pod ne fonctionnera pas si reschedulé ailleurs
• Peut ouvrir des voies de contournement des contrôles de sécurité du cluster

Les Pod Security Standards (Baseline et Restricted) interdisent ou restreignent fortement hostPath. Réservez-le aux DaemonSets ou au debug, jamais aux workloads applicatifs standards.

Gérer les permissions avec securityContext

Les problèmes de permissions sont fréquents avec les volumes. Le securityContext permet de les résoudre.

Définir le groupe propriétaire avec fsGroup

fsgroup-demo.yaml

apiVersion: v1
kind: Pod
metadata:
  name: fsgroup-demo
spec:
  securityContext:
    fsGroup: 1000  # Tous les fichiers montés appartiendront à ce groupe
    runAsUser: 1000
    runAsGroup: 1000
  containers:
  - name: app
    image: busybox:1.36
    command: ['sh', '-c', 'ls -la /data && sleep 3600']
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    emptyDir: {}

Définir les permissions des fichiers

Pour les volumes ConfigMap et Secret :

volumes:
- name: secret-volume
  secret:
    secretName: db-credentials
    defaultMode: 0400  # -r-------- (lecture seule pour le propriétaire)

Mode	Permissions	Usage
0644	-rw-r--r--	Fichiers de configuration lisibles par tous
0600	-rw-------	Fichiers sensibles, écriture par le propriétaire
0400	-r--------	Secrets, lecture seule
0755	-rwxr-xr-x	Scripts exécutables

Glissez pour voir

Sous-chemins (subPath)

Pour monter un fichier spécifique sans écraser le répertoire existant :

volumeMounts:
- name: config
  mountPath: /etc/nginx/nginx.conf
  subPath: nginx.conf  # Ne monte que ce fichier

Limitation critique

Avec subPath, les mises à jour du ConfigMap ou Secret ne sont pas propagées au conteneur. Le fichier garde sa valeur initiale jusqu’au redémarrage du conteneur. Utilisez subPath uniquement si vous acceptez cette limitation.

Alternative sans subPath : Montez le ConfigMap dans un sous-répertoire et créez un lien symbolique dans un init container.

Combiner plusieurs volumes

Un Pod peut monter plusieurs volumes de types différents :

multi-volume-demo.yaml

apiVersion: v1
kind: Pod
metadata:
  name: multi-volume
spec:
  securityContext:
    fsGroup: 101  # Groupe nginx
  containers:
  - name: app
    image: nginx:alpine
    volumeMounts:
    - name: config
      mountPath: /etc/nginx/conf.d
      readOnly: true
    - name: secrets
      mountPath: /etc/nginx/ssl
      readOnly: true
    - name: cache
      mountPath: /var/cache/nginx
  volumes:
  - name: config
    configMap:
      name: nginx-config
  - name: secrets
    secret:
      secretName: nginx-certs
      defaultMode: 0400
  - name: cache
    emptyDir: {}

Tableau de décision

Besoin	Volume conseillé	Remarque
Partager temporairement entre conteneurs	emptyDir	Disparaît avec le Pod
Cache haute performance	emptyDir avec medium: Memory	Compte dans la mémoire du Pod
Injecter une config sous forme de fichiers	configMap	Volume projeté, mises à jour auto
Injecter un secret sous forme de fichiers	secret	Volume projeté, toujours en readOnly
Exposer le nom/namespace/labels du Pod	downwardAPI	Volume projeté
Combiner config + secret + metadata	projected	Méthode standard d’agrégation
Accéder à un chemin du nœud	hostPath	Éviter sauf DaemonSet/debug
Stocker des données persistantes	PVC	Pas un volume applicatif

Glissez pour voir

Anti-patterns à éviter

Anti-pattern	Pourquoi c’est problématique	Solution
Utiliser hostPath comme stockage persistant	Non portable, risques de sécurité	Utiliser un PVC
Modifier des fichiers depuis un ConfigMap/Secret	Ce sont des sources projetées, pas un espace d’écriture	Copier dans un emptyDir si besoin de modifier
Oublier que subPath casse la propagation	Les mises à jour ConfigMap ne seront pas reflétées	Monter le répertoire complet ou redémarrer le Pod
Supposer qu’un emptyDir survit au Pod	Le contenu est perdu si le Pod est supprimé ou reschedulé	Utiliser un PVC pour les données importantes
Oublier readOnly: true sur les Secrets	Risque de modification accidentelle	Toujours spécifier readOnly: true
Ignorer les permissions (fsGroup, defaultMode)	Erreurs “permission denied” au runtime	Définir explicitement le contexte de sécurité
Monter des chemins sensibles via hostPath	Contournement des contrôles de sécurité du cluster	Utiliser les Pod Security Standards pour bloquer

Glissez pour voir

Dépannage

Symptôme	Cause probable	Solution
MountVolume.SetUp failed for volume	ConfigMap/Secret introuvable	Vérifier que la ressource existe dans le même namespace
Fichiers vides	ConfigMap/Secret vide	kubectl get configmap xxx -o yaml pour vérifier
Permission denied	Mode trop restrictif ou mauvais user/group	Ajuster defaultMode, fsGroup ou runAsUser
Volume non monté	Nom mal référencé	Vérifier que volumeMounts.name correspond exactement à volumes.name
Fichier non mis à jour après modification ConfigMap	Utilisation de subPath	Redémarrer le Pod ou ne pas utiliser subPath
Pod bloqué en ContainerCreating	Volume non disponible	kubectl describe pod pour voir les événements

Glissez pour voir

Commandes de diagnostic

# Voir les montages déclarés
kubectl get pod mon-pod -o jsonpath='{.spec.volumes}' | jq

# Voir les montages effectifs dans le conteneur
kubectl describe pod mon-pod | grep -A 20 "Mounts:"

# Lister les fichiers dans un volume monté
kubectl exec mon-pod -- ls -la /chemin/du/montage

# Vérifier les permissions
kubectl exec mon-pod -- stat /chemin/du/fichier

# Voir les événements liés aux volumes
kubectl get events --field-selector involvedObject.name=mon-pod

Réflexes CKAD

1. Identifier où déclarer

   • spec.volumes[] : déclare le volume et sa source
   • spec.containers[].volumeMounts[] : monte le volume dans un conteneur
   • Le name doit correspondre exactement entre les deux

2. Créer rapidement un Pod avec volume

   # Générer le YAML de base
   kubectl run mypod --image=nginx --dry-run=client -o yaml > pod.yaml
   # Puis ajouter volumes et volumeMounts manuellement

3. Vérifier vite le montage

   kubectl describe pod mypod | grep -A 5 "Mounts:"
   kubectl exec mypod -- ls -la /chemin/montage
   kubectl exec mypod -- cat /chemin/montage/fichier

4. Différencier volume partagé et volume projeté

   • emptyDir : les conteneurs peuvent lire et écrire — c’est un espace partagé
   • configMap, secret, downwardAPI : injectés par Kubernetes — à traiter comme read-only

5. Piège courant à l’examen

   Le volume est déclaré mais pas monté, ou le nom ne correspond pas. Toujours vérifier la correspondance volumes.name ↔ volumeMounts.name.

Volumes éphémères génériques (aperçu)

Pour des besoins avancés, Kubernetes propose aussi des ephemeral volumes génériques qui permettent d’utiliser des drivers CSI pour créer des volumes éphémères (par exemple, un disque SSD temporaire provisionné dynamiquement). Ces volumes sont supprimés avec le Pod.

volumes:
- name: scratch
  ephemeral:
    volumeClaimTemplate:
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: fast-ssd
        resources:
          requests:
            storage: 10Gi

Consultez la documentation Kubernetes sur les ephemeral volumes pour approfondir.

À retenir

1. emptyDir : partage temporaire entre conteneurs — disparaît avec le Pod
2. configMap et secret : volumes projetés depuis des objets API — pas du stockage persistant
3. projected : combine plusieurs sources dans un seul répertoire — méthode standard d’agrégation
4. downwardAPI : expose les métadonnées du Pod comme fichiers
5. hostPath : accès au système de fichiers du nœud — risques majeurs, à éviter en production
6. Toujours monter ConfigMap et Secret en readOnly: true
7. Avec subPath, les mises à jour ne sont pas propagées
8. Utilisez securityContext et fsGroup pour gérer les permissions
9. Un volume se déclare dans spec.volumes, se monte avec volumeMounts — les noms doivent correspondre

Prochaines étapes

Storage Kubernetes PersistentVolumes et StorageClasses pour la vraie persistance

ConfigMaps Gérer la configuration de vos applications

Secrets Stocker et injecter les données sensibles

Init Containers et Sidecars Préparer et enrichir vos Pods

×

📖 Voir la documentation →