Kubernetes volumes
| Fiche express | |
|---|---|
| Types courants | emptyDir · hostPath · NFS · PersistentVolume
|
| Objets stockage | PersistentVolume (PV) · PersistentVolumeClaim (PVC) · StorageClass |
| Voir aussi | Kubernetes ConfigMaps · Kubernetes secrets |
Un volume Kubernetes est un espace de stockage attaché à un Pod, dont le cycle de vie et les garanties de persistance dépendent du type choisi. Les volumes servent aussi bien à survivre au redémarrage d'un conteneur qu'à monter une configuration ou un secret (voir Kubernetes ConfigMaps).
Types de volumes simples
| Type | Persistance | Usage typique |
|---|---|---|
| emptyDir | Créé vide à la création du Pod, supprimé avec le Pod | Stockage temporaire, partage de données entre conteneurs d'un même Pod |
| hostPath | Situé sur le disque local du worker node | Cas spécifiques (accès à des fichiers du nœud) ; lie le Pod à un nœud précis, à éviter en usage général |
| NFS | Externe au nœud, partagé | Stockage réseau partageable entre plusieurs Pods/nœuds |
Exemple d'utilisation d'un volume hostPath pour écrire une donnée sur le nœud :
kubectl create -f volume-pod.yml
kubectl get pod volume-pod -o wide # identifier le worker node hébergeant le Pod
Le fichier produit reste alors consultable directement sur le nœud hôte, hors du cycle de vie du Pod.
Exemple d'un emptyDir partagé entre deux conteneurs d'un même Pod (motif sidecar) :
kubectl create -f shared-volume-pod.yml
kubectl logs shared-volume-pod -c busybox2 # doit voir les données écrites par busybox1
PersistentVolume et PersistentVolumeClaim
Pour un stockage géré indépendamment du cycle de vie d'un Pod donné, Kubernetes distingue deux objets :
- PersistentVolume (PV) — une ressource de stockage administrée (par un administrateur cluster ou de façon dynamique par une StorageClass).
- PersistentVolumeClaim (PVC) — la requête qu'un utilisateur ou une application émet pour réclamer l'accès à un PV correspondant à ses critères (taille, mode d'accès, classe de stockage).
Politique de réclamation (reclaim policy)
Détermine ce qu'il advient du PV une fois son PVC supprimé :
- Retain — conserve le volume et les données ; nécessite une intervention manuelle pour le réutiliser.
- Delete — supprime le volume et la ressource de stockage sous-jacente.
- Recycle — (dépréciée) effaçait les données mais conservait l'objet PV.
Expansion d'un volume
Un PVC peut être étendu à chaud si la StorageClass associée l'autorise (allowVolumeExpansion: true).
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: disque-local
provisioner: kubernetes.io/no-provisioner
allowVolumeExpansion: true
Provisionnement statique : pas à pas
Cas d'usage manuel, PV et PVC créés séparément puis liés :
# 1. Créer la StorageClass (si expansion souhaitée)
kubectl create -f storageclass.yml
# 2. Créer le PersistentVolume
kubectl create -f mon-pv.yml
kubectl get pv
# 3. Créer le PersistentVolumeClaim qui se liera au PV
kubectl create -f mon-pvc.yml
kubectl get pv
kubectl get pvc # vérifier l'état "Bound"
# 4. Utiliser le PVC dans un Pod
kubectl create -f pv-pod.yml
Étendre le PVC ensuite si la StorageClass l'autorise :
kubectl edit pvc mon-pvc
Nettoyage :
kubectl delete pod pv-pod
kubectl delete pvc mon-pvc
kubectl get pv # vérifier l'état du PV selon sa reclaim policy
Provisionnement dynamique
En pratique, la majorité des clusters (notamment dans le cloud, ou avec un provisioner CSI on-prem) utilisent le provisionnement dynamique : un PVC référence directement une StorageClass, et le PV correspondant est créé automatiquement par le provisioner, sans étape manuelle de création du PV. C'est le mode recommandé — la gestion statique décrite ci-dessus reste utile pour comprendre le mécanisme sous-jacent, mais devient vite impraticable à l'échelle d'un cluster de production.