E-NO
Kubernetes 7 min de lecture

Laboratoire local de volumes Kubernetes avec exemples pratiques

calendar_today Publié : 2026-08-26
update Dernière mise à jour : 2026-08-26
analytics Efficacité SEO : 100%
Illustration du guide technique pour « Laboratoire local de volumes Kubernetes avec exemples pratiques ».

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 :

ComposantVersion recommandéeRemarques
Kubernetesv1.24 ou ultérieureMinikube ou kind fonctionnent tous deux
kubectlv1.24 ou ultérieureFaites correspondre la version mineure au cluster
Minikubev1.26 ou ultérieureOu kind v0.14 ou ultérieure
Moteur de conteneursDocker ou containerdMinikube peut utiliser sa propre VM
Système d'exploitation hôteLinux, macOS ou WindowsLinux 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.

Question rapide 1 sur 2

Quelle est l'approche recommandée pour la sécurité et l'isolation des données selon la documentation Kubernetes ?

La référence indique que pour la sécurité et l'isolation des données, l'approvisionnement dynamique de volumes est recommandé et que les types de volumes utilisant les ressources du nœud doivent être évités.

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

Question rapide 2 sur 2

Quel est le but d'une PersistentVolumeClaim ?

Une PersistentVolumeClaim est une demande de stockage par un utilisateur, de la même manière que les Pods consomment les ressources du nœud.

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 ssh et 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 :

ÉtapeCommande / ActionRésultat attendu
Démarrer le clusterminikube startCluster prêt
Vérifier la StorageClasskubectl get scstandard listée
Appliquer le PVCkubectl apply -f pvc.yamlPVC créé
Vérifier que le PVC est liékubectl get pvcSTATUS Bound
Appliquer le podkubectl apply -f pod.yamlPod en cours d'exécution
Écrire un fichier de testkubectl exec ... -- sh -c 'echo test > /mnt/test.txt'Aucune erreur
Lire le fichier de testkubectl exec ... -- cat /mnt/test.txtSortie test
Supprimer le pod et le recréerkubectl delete pod ... && kubectl apply -f pod.yamlLes données persistent
Nettoyerkubectl delete pod, pvcRessources supprimées

Pour une inspection plus approfondie :

  • kubectl describe pvc affiche les événements de provisionnement.
  • kubectl describe pv affiche les détails de la source du volume.
  • minikube ssh permet 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.

Recherches connexes

Score de qualité de l’article

Utilité pour le lecteur 100%
  • check_circle Guide prêt à lire
  • check_circle Exemples pratiques inclus
  • check_circle URL d’article optimisée pour le SEO