Un guide pratique pour construire un laboratoire de volumes Kubernetes sûr sur votre machine locale afin de tester les PersistentVolumes, PersistentVolumeClaims, StorageClasses et les configurations de stockage des pods.
Introduction
Les volumes Kubernetes sont un élément fondamental des applications avec état, mais ils sont souvent mal compris. Un laboratoire local vous offre un environnement sûr et isolé pour expérimenter avec les PersistentVolumes (PV), les PersistentVolumeClaims (PVC) et les StorageClasses sans risquer les données de production. Ce guide vous accompagne dans la mise en place d'un tel laboratoire en utilisant des outils courants comme Minikube ou kind, la création de stockage local et l'exécution de tests pratiques. À la fin, vous disposerez d'un flux de travail reproductible pour apprendre et déboguer le comportement des volumes.
Nous commencerons par la configuration de l'environnement, puis nous créerons une StorageClass et un PVC, attacherons le volume à un pod, vérifierons la persistance, explorerons les modes de défaillance et la récupération, et terminerons par une liste de contrôle opérationnelle. Chaque étape comprend des commandes concrètes, des extraits YAML et les résultats attendus pour que vous puissiez suivre.
Inventaire des versions et de l'environnement
Avant de commencer, assurez-vous d'avoir installé et compatible les éléments suivants :
| Composant | Version recommandée | Remarques |
|---|---|---|
| Kubernetes | v1.24 ou ultérieure | Minikube ou kind fonctionnent tous deux |
| kubectl | v1.24 ou ultérieure | Faites correspondre la version mineure au cluster |
| Minikube | v1.26 ou ultérieure | Ou kind v0.14 ou ultérieure |
| Moteur de conteneurs | Docker ou containerd | Minikube peut utiliser sa propre VM |
| Système d'exploitation hôte | Linux, macOS ou Windows | Linux est le plus simple pour les volumes locaux |
Ce laboratoire utilise Minikube avec le pilote Docker par défaut. Vérifiez votre environnement avec :
kubectl version --client
# Exemple de sortie : Client Version: v1.26.3
minikube version
# Exemple de sortie : minikube version: v1.29.0
Démarrez votre cluster :
minikube start --driver=docker --kubernetes-version=v1.26.3
# Exemple de sortie : Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default.
Vérifiez que le cluster est opérationnel :
kubectl get nodes
# Sortie attendue :
# NAME STATUS ROLES AGE VERSION
# minikube Ready control-plane 1m v1.26.3
Si votre environnement utilise kind, les étapes sont similaires, mais les volumes hostPath seront sur le conteneur du nœud kind plutôt que sur une VM. Les commandes pour créer des PVC et des pods restent les mêmes.
Chemin de configuration sûr
Pour un laboratoire sûr, utilisez une StorageClass avec volumeBindingMode: Immediate et un provisionneur de chemin local. Minikube fournit une StorageClass standard intégrée qui provisionne dynamiquement des volumes hostPath. Vous pouvez également créer votre propre StorageClass pour plus de contrôle.
Tout d'abord, inspectez les StorageClasses existantes :
kubectl get storageclass
# Sortie attendue :
# NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
# standard (default) k8s.io/minikube-hostpath Delete Immediate false 1m
La sortie montre une StorageClass par défaut nommée standard avec le provisionneur k8s.io/minikube-hostpath. Ce provisionneur crée un répertoire sous /tmp/hostpath-provisioner/ sur le nœud Minikube pour chaque volume. Comme la politique de récupération est Delete, la suppression du PVC supprimera le répertoire associé.
Si vous avez besoin d'une StorageClass personnalisée, créez un fichier YAML custom-sc.yaml :
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: local-hp
provisioner: k8s.io/minikube-hostpath
reclaimPolicy: Retain
volumeBindingMode: Immediate
Appliquez-le :
kubectl apply -f custom-sc.yaml
# Sortie attendue : storageclass.storage.k8s.io/local-hp created
Pour ce laboratoire, nous utiliserons la classe standard par défaut pour plus de simplicité.
Créez maintenant un PVC pour demander du stockage à cette StorageClass. Enregistrez le contenu suivant sous pvc.yaml :
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: lab-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
Appliquez-le :
kubectl apply -f pvc.yaml
# Sortie attendue : persistentvolumeclaim/lab-pvc created
Vérifiez l'état du PVC :
kubectl get pvc lab-pvc
# Sortie attendue :
# NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
# lab-pvc Bound pvc-1234abcd-56ef-7890-ghij-klmnopqrstuv 1Gi RWO standard 5s
Un PV a été automatiquement créé. Affichez-le :
kubectl get pv
# Sortie attendue :
# NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
# pvc-1234abcd-56ef-7890-ghij-klmnopqrstuv 1Gi RWO Delete Bound default/lab-pvc standard 10s
Le PV est lié au PVC. Notez que la politique de récupération est Delete, ce qui signifie que lorsque le PVC est supprimé, le PV et les données sous-jacentes seront supprimés.
Déployez maintenant un pod qui utilise ce PVC. Enregistrez le contenu suivant sous pod.yaml :
apiVersion: v1
kind: Pod
metadata:
name: volume-test
spec:
containers:
- name: app
image: nginx:latest
volumeMounts:
- mountPath: /usr/share/nginx/html
name: data
volumes:
- name: data
persistentVolumeClaim:
claimName: lab-pvc
Appliquez le pod :
kubectl apply -f pod.yaml
# Sortie attendue : pod/volume-test created
Vérifiez que le pod est en cours d'exécution :
kubectl get pod volume-test
# Sortie attendue :
# NAME READY STATUS RESTARTS AGE
# volume-test 1/1 Running 0 10s
Vérification et diagnostics
Pour vérifier que le volume fonctionne, écrivez un fichier depuis l'intérieur du pod, puis vérifiez-le depuis l'hôte ou un autre pod.
Tout d'abord, exécutez une commande dans le pod pour créer un fichier :
kubectl exec -it volume-test -- sh -c 'echo Hello from volume > /usr/share/nginx/html/test.txt'
# Aucune sortie en cas de succès
Lisez le fichier depuis le pod :
kubectl exec volume-test -- cat /usr/share/nginx/html/test.txt
# Sortie attendue : Hello from volume
Maintenant, inspectez le chemin hôte où le volume est monté. Pour Minikube, vous pouvez utiliser minikube ssh :
minikube ssh
# À l'intérieur de la VM Minikube
sudo ls /tmp/hostpath-provisioner/default/lab-pvc
# Sortie attendue : test.txt
sudo cat /tmp/hostpath-provisioner/default/lab-pvc/test.txt
# Sortie attendue : Hello from volume
Cela confirme que le volume persiste sur l'hôte. Quittez la session SSH avec exit.
Pour tester la persistance lors des redémarrages de pod, supprimez le pod et recréez-le :
kubectl delete pod volume-test
# Sortie attendue : pod "volume-test" deleted
kubectl apply -f pod.yaml
# Sortie attendue : pod/volume-test created
Après le démarrage du pod, vérifiez que le fichier existe toujours :
kubectl exec volume-test -- cat /usr/share/nginx/html/test.txt
# Sortie attendue : Hello from volume
Pour voir des informations détaillées sur le volume, décrivez le PVC et le PV :
kubectl describe pvc lab-pvc
# Recherchez les Events :
# Normal ProvisioningSucceeded 10s k8s.io/minikube-hostpath_minikube Successfully provisioned volume pvc-1234abcd-56ef-7890-ghij-klmnopqrstuv
kubectl describe pv pvc-1234abcd-56ef-7890-ghij-klmnopqrstuv
# Recherchez Source :
# Type: HostPath (path: /tmp/hostpath-provisioner/default/lab-pvc)
Vérifiez la capacité et l'utilisation du stockage depuis l'intérieur du pod :
kubectl exec volume-test -- df -h /usr/share/nginx/html
# Exemple de sortie :
# Filesystem Size Used Avail Use% Mounted on
# /dev/sda1 9.7G 1.2G 8.5G 12% /usr/share/nginx/html
Modes de défaillance et récupération
Les défaillances courantes dans un laboratoire local incluent un PVC bloqué en Pending, un pod qui ne parvient pas à monter le volume ou une perte de données due à la politique de récupération.
PVC en attente (Pending)
Si le PVC n'est pas lié, vérifiez la StorageClass et le provisionneur :
kubectl describe pvc lab-pvc
# Recherchez les Events :
# Warning ProvisioningFailed 10s k8s.io/minikube-hostpath_minikube failed to provision volume with StorageClass "standard": ...
Si vous utilisez une StorageClass personnalisée, assurez-vous que le provisionneur est correct et disponible. Pour Minikube, la classe standard fonctionne immédiatement.
Erreurs de montage du pod
Si le pod ne démarre pas avec une erreur de montage, vérifiez l'état du PVC et les événements du pod :
kubectl get pvc
kubectl describe pod volume-test
# Recherchez les Events :
# Warning FailedMount 30s kubelet MountVolume.SetUp failed for volume "pvc-..." : ...
Parfois, le problème est que le volume est déjà monté par un autre pod avec ReadWriteOnce sur un nœud différent. Dans un Minikube à nœud unique, cela est rare.
Perte de données lors de la suppression du PVC
La politique de récupération par défaut pour la StorageClass standard est Delete. Si vous supprimez le PVC, le PV et les données hostPath sont supprimés.
kubectl delete pvc lab-pvc
# Sortie attendue : persistentvolumeclaim "lab-pvc" deleted
Si vous devez conserver les données, changez la politique de récupération en Retain sur le PV avant de supprimer le PVC. Cependant, pour un laboratoire, vous pouvez recréer le PVC et le pod à partir de zéro.
Étapes de récupération
- Vérifiez les événements du cluster :
kubectl get events --sort-by=.metadata.creationTimestamp - Vérifiez la StorageClass :
kubectl get sc - Inspectez le hostPath sur le nœud si vous utilisez hostPath :
minikube sshet parcourez/tmp/hostpath-provisioner/... - Recréez les ressources si nécessaire.
Pour réinitialiser complètement le laboratoire, supprimez toutes les ressources créées :
kubectl delete pod volume-test
kubectl delete pvc lab-pvc
# Aucune sortie, mais les ressources sont supprimées
Puis réappliquez vos fichiers YAML.
Liste de contrôle opérationnelle
Utilisez cette liste de contrôle pour des opérations de laboratoire reproductibles :
| Étape | Commande / Action | Résultat attendu |
|---|---|---|
| Démarrer le cluster | minikube start | Cluster prêt |
| Vérifier la StorageClass | kubectl get sc | standard listée |
| Appliquer le PVC | kubectl apply -f pvc.yaml | PVC créé |
| Vérifier que le PVC est lié | kubectl get pvc | STATUS Bound |
| Appliquer le pod | kubectl apply -f pod.yaml | Pod en cours d'exécution |
| Écrire un fichier de test | kubectl exec ... -- sh -c 'echo test > /mnt/test.txt' | Aucune erreur |
| Lire le fichier de test | kubectl exec ... -- cat /mnt/test.txt | Sortie test |
| Supprimer le pod et le recréer | kubectl delete pod ... && kubectl apply -f pod.yaml | Les données persistent |
| Nettoyer | kubectl delete pod, pvc | Ressources supprimées |
Pour une inspection plus approfondie :
kubectl describe pvcaffiche les événements de provisionnement.kubectl describe pvaffiche les détails de la source du volume.minikube sshpermet des vérifications de fichiers au niveau de l'hôte.
Conservez les fichiers YAML sous contrôle de version pour des laboratoires reproductibles.
Conclusion
Vous disposez maintenant d'un laboratoire de volumes Kubernetes fonctionnel sur votre machine locale. Vous avez appris à configurer un cluster, créer une StorageClass, provisionner un PVC, l'attacher à un pod, vérifier la persistance des données et récupérer des défaillances courantes. Ce laboratoire sert de base pour explorer des sujets plus avancés comme les StatefulSets, le provisionnement dynamique avec différents backends de stockage et les pilotes CSI. N'oubliez pas de commencer avec un scénario étroit et de l'élargir progressivement, comme le suggèrent les preuves de recherche pour un développement local efficace. Gardez votre environnement propre et vos fichiers YAML organisés pour un apprentissage reproductible.
Pour étendre ce laboratoire, expérimentez avec différents modes d'accès, politiques de récupération et StorageClasses personnalisées. Essayez de déployer plusieurs pods partageant un volume ReadWriteMany, ou utilisez un StatefulSet pour gérer le stockage persistant de chaque réplica. Ces exercices approfondiront votre compréhension du stockage Kubernetes et vous prépareront aux scénarios de production.