Introduction
Les conteneurs disposent de systèmes de fichiers inscriptibles, mais ce stockage est lié au cycle de vie du conteneur. Les volumes Kubernetes offrent aux Pods un moyen plus structuré de gérer les fichiers. Certains volumes sont éphémères et destinés aux données temporaires au sein d'un seul Pod. D'autres volumes sont persistants et permettent de conserver les données disponibles même lorsqu'un Pod est supprimé et recréé.
Dans ce laboratoire, vous utiliserez un volume emptyDir pour des données de travail locales au Pod, puis vous créerez un PersistentVolumeClaim que vous monterez dans deux Pods différents pour démontrer que les données survivent au remplacement du Pod.
Préparer un espace de noms pour la pratique des volumes
Dans cette étape, vous allez préparer un espace de noms propre et confirmer que le cluster dispose des ressources de stockage nécessaires pour ce laboratoire.
Commencez dans /home/labex/project. Vous rédigerez les manifestes des Pods et des PVC dans ce répertoire.
mkdir -p /home/labex/project
cd /home/labex/project
Vérifiez que le serveur API Kubernetes est accessible. Si la machine virtuelle vient de démarrer et que le nœud n'est pas encore prêt, attendez quelques secondes et relancez la commande.
kubectl get nodes --request-timeout=5s
La sortie attendue inclut :
NAME STATUS ROLES AGE VERSION
labex-v135 Ready control-plane ... v1.35...
Attendez que le Pod réseau du cluster soit prêt :
kubectl wait --namespace kube-system --for=condition=Ready pod -l k8s-app=calico-node --timeout=120s
Sortie attendue :
pod/calico-node-... condition met
Ce laboratoire utilise un PersistentVolumeClaim plus tard. Confirmez que la StorageClass standard par défaut existe, puis attendez le Pod du provisionneur de stockage minikube.
kubectl get storageclass standard
kubectl wait --namespace kube-system --for=condition=Ready pod/storage-provisioner --timeout=120s
La sortie attendue inclut :
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ...
standard (default) k8s.io/minikube-hostpath Delete Immediate ...
pod/storage-provisioner condition met
Créez un espace de noms nommé ckad-prep-volumes :
kubectl create namespace ckad-prep-volumes
Définissez cet espace de noms comme espace de noms actuel pour le contexte :
kubectl config set-context --current --namespace=ckad-prep-volumes
Confirmez l'espace de noms actuel :
kubectl config view --minify --output 'jsonpath={..namespace}'; echo
Sortie attendue :
ckad-prep-volumes
Utiliser emptyDir pour des données de travail locales au Pod
Dans cette étape, vous allez créer un Pod qui utilise un volume emptyDir.
Un volume emptyDir est vide lors de la création du Pod. Les conteneurs au sein du même Pod peuvent l'utiliser comme espace de travail partagé, espace de cache ou répertoire de travail temporaire. Il n'est pas destiné à conserver les données après la suppression du Pod.
Créez emptydir-pod.yaml :
cat > emptydir-pod.yaml <<'EOF'
apiVersion: v1
kind: Pod
metadata:
name: scratch-worker
labels:
app: scratch-worker
spec:
terminationGracePeriodSeconds: 0
volumes:
- name: scratch-space
emptyDir: {}
containers:
- name: worker
image: busybox:1.36
command:
- /bin/sh
- -c
- 'echo scratch-ready > /scratch/status.txt; sleep 3600'
volumeMounts:
- name: scratch-space
mountPath: /scratch
EOF
Appliquez le manifeste :
kubectl apply -f emptydir-pod.yaml
Sortie attendue :
pod/scratch-worker created
Attendez que le Pod soit prêt :
kubectl wait --for=condition=Ready pod/scratch-worker --timeout=120s
Sortie attendue :
pod/scratch-worker condition met
Lisez le fichier depuis le volume emptyDir monté :
kubectl exec scratch-worker -c worker -- cat /scratch/status.txt
Sortie attendue :
scratch-ready
Inspectez le type de volume du Pod. L'expression jsonpath affiche le nom du volume et confirme qu'il s'agit d'un emptyDir.
kubectl get pod scratch-worker -o 'jsonpath={.spec.volumes[0].name}{" emptyDir\n"}'
Sortie attendue :
scratch-space emptyDir
Écrire des données dans un PersistentVolumeClaim
Dans cette étape, vous allez créer un PersistentVolumeClaim et le monter dans un Pod d'écriture.
Un PersistentVolumeClaim, ou PVC, est une demande de stockage faite par une application. Dans ce laboratoire, la StorageClass standard fournit dynamiquement le stockage pour la demande. Votre Pod monte la réclamation sur /data et y écrit un fichier.
Créez notes-pvc.yaml :
cat > notes-pvc.yaml <<'EOF'
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: notes-pvc
spec:
accessModes:
- ReadWriteOnce
storageClassName: standard
resources:
requests:
storage: 1Mi
EOF
Appliquez le PVC :
kubectl apply -f notes-pvc.yaml
Sortie attendue :
persistentvolumeclaim/notes-pvc created
Attendez que le PVC soit à l'état Bound :
kubectl wait --for=jsonpath='{.status.phase}'=Bound pvc/notes-pvc --timeout=120s
Sortie attendue :
persistentvolumeclaim/notes-pvc condition met
Créez un Pod d'écriture qui monte le PVC :
cat > pvc-writer-pod.yaml <<'EOF'
apiVersion: v1
kind: Pod
metadata:
name: pvc-writer
labels:
app: pvc-writer
spec:
terminationGracePeriodSeconds: 0
volumes:
- name: notes-storage
persistentVolumeClaim:
claimName: notes-pvc
containers:
- name: writer
image: busybox:1.36
command:
- /bin/sh
- -c
- 'echo persistent-note > /data/note.txt; sleep 3600'
volumeMounts:
- name: notes-storage
mountPath: /data
EOF
Appliquez le Pod d'écriture et attendez qu'il soit prêt :
kubectl apply -f pvc-writer-pod.yaml
kubectl wait --for=condition=Ready pod/pvc-writer --timeout=120s
Sortie attendue :
pod/pvc-writer created
pod/pvc-writer condition met
Lisez le fichier depuis le montage du PVC :
kubectl exec pvc-writer -c writer -- cat /data/note.txt
Sortie attendue :
persistent-note
Réutiliser le PVC depuis un nouveau Pod
Dans cette étape, vous allez supprimer le Pod d'écriture, créer un nouveau Pod de lecture qui monte le même PVC, et confirmer que le fichier est toujours présent.
C'est là que réside la différence pratique entre les données de travail locales au Pod et le stockage persistant. Le Pod d'écriture peut être supprimé, mais le PVC demeure. Un nouveau Pod peut monter la même réclamation et lire les données.
Supprimez le Pod d'écriture :
kubectl delete pod pvc-writer
Sortie attendue :
pod "pvc-writer" deleted
Créez un Pod de lecture qui monte le même PVC :
cat > pvc-reader-pod.yaml <<'EOF'
apiVersion: v1
kind: Pod
metadata:
name: pvc-reader
labels:
app: pvc-reader
spec:
terminationGracePeriodSeconds: 0
volumes:
- name: notes-storage
persistentVolumeClaim:
claimName: notes-pvc
containers:
- name: reader
image: busybox:1.36
command:
- /bin/sh
- -c
- 'cat /data/note.txt; sleep 3600'
volumeMounts:
- name: notes-storage
mountPath: /data
EOF
Appliquez le Pod de lecture et attendez qu'il soit prêt :
kubectl apply -f pvc-reader-pod.yaml
kubectl wait --for=condition=Ready pod/pvc-reader --timeout=120s
Sortie attendue :
pod/pvc-reader created
pod/pvc-reader condition met
Lisez le fichier depuis le nouveau Pod :
kubectl exec pvc-reader -c reader -- cat /data/note.txt
Sortie attendue :
persistent-note
Inspectez le PVC. Il devrait toujours être à l'état Bound, même si le Pod d'écriture original a disparu.
kubectl get pvc notes-pvc
La sortie attendue inclut :
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE
notes-pvc Bound ... 1Mi RWO standard <unset> ...
Résumé
Vous avez utilisé un volume emptyDir pour des données de travail locales au Pod, créé un PVC pour le stockage persistant, écrit des données via un Pod, supprimé ce Pod, et lu les mêmes données depuis un nouveau Pod ayant monté la même réclamation. Vous savez désormais quand utiliser le stockage éphémère pour des données temporaires de Pod et quand demander un stockage persistant pour des données devant survivre au remplacement d'un Pod.
