Lab 03 : Gestion des Volumes dans OKS

Créer et utiliser des PersistentVolumes (PV) et PersistentVolumeClaims (PVC) avec un StorageClass.
Tester le comportement des volumes avec des applications simples.

Pré-requis

Un cluster Kubernetes opérationnel fourni par OKS.
Accès à la CLI kubectl.
Droits administrateurs sur le cluster.
Connaissance de base des objets Kubernetes : Pod, PVC, etc.

Vérifier l’accès au cluster

Assurez-vous d’avoir les permissions nécessaires pour accéder au cluster cible. Vous devez disposer d’un utilisateur ou d’un rôle qui vous permet d’exporter ou de récupérer la configuration du cluster.

Récupérer le fichier kubeconfig

oks-cli cluster kubeconfig --cluster-name my-cluster --project-name my-project > kubeconfig.yaml
export KUBECONFIG=./kubeconfig.yaml

Tester le cluster

kubectl get nodes

Étape 1 : Vérification du StorageClass par défaut

Vérification initiale

OKS fournit un StorageClass par défaut pour les volumes dynamiques. Si vous oubliez de créer un StorageClass personnalisé, Kubernetes utilisera automatiquement celui par défaut. Pour vérifier les StorageClasses disponibles, exécutez la commande suivante :

kubectl get storageclass

Vous devirez obtenir une liste des StorageClass de ce type:

NAME                PROVISIONER            RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
bsu-gp2 (default)   bsu.csi.outscale.com   Retain          WaitForFirstConsumer   true                   30d
bsu-gp2-del         bsu.csi.outscale.com   Delete          WaitForFirstConsumer   true                   30d
bsu-io1-50          bsu.csi.outscale.com   Retain          WaitForFirstConsumer   true                   30d
bsu-io1-50-del      bsu.csi.outscale.com   Delete          WaitForFirstConsumer   true                   30d
bsu-standard        bsu.csi.outscale.com   Retain          WaitForFirstConsumer   true                   30d
bsu-standard-del    bsu.csi.outscale.com   Delete          WaitForFirstConsumer   true                   30d

On peut remarquer que dans la list des StorageClass disponibles dans notre cluster OKS, la classe de stockage bsu-gp2 est indiquée comme celle par défaut (default). Ce qui veut dire que lors de la création d’un PVC, si on ne précise pas le nom de la classe de stockage, c’est cette classe qui sera utilisée par défaut.

Si on veut définir une storageClass par défaut à utiliser, on peut le faire avec cette commande :

kubectl patch storageclass bsu-gp2-del -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

Étape 2 : Création d’un PVC en ReadWriteOnce (RWO)

Déployer un environnement de test

Créer un namespace dédié

kubectl create namespace lab-volumes

Définition du PVC

Nous allons créer un Persistent Volume Claim (PVC) qui demande un espace de stockage de 5 Gi.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: bsu-claim
  namespace: lab-volumes
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: bsu-standard

Application du PVC

Appliquer le fichier yaml afin de créer votre PVC

kubectl apply -f pvc.yaml

Une fois le PVC appliqué, vous pouvez vérifier qu’il a bien été créé. Utilisez la commande suivante pour lister les PVC dans le namespace :

kubectl get pvc -n lab-volumes
NAME        STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
bsu-claim   Pending                                      bsu-standard   <unset>                 50s

Vous remarquez que le STATUS du PVC que nous venons de créer est Pending, c’est à dire qu’il n’est pas encore lié à un PersistentVolume. Ce qui est normal, si vous regardez la liste des StorageClass plus haut, on voit que le VOLUMEBINDINGMODE est WaitForFirstConsumer, ce qui veut dire que tant qu’un Pod n’utilisera pas ce PVC, le PV ne sera pas provisionné et donc pas lié au PVC.

Étape 3 : Déploiement d’un Pod utilisant le PVC

Définition du Pod

Créez un Pod simple qui monte le PVC pour écrire dans un fichier sur le volume.

Voici un exemple de fichier YAML pour le Pod :

apiVersion: v1
kind: Pod
metadata:
  name: app
  namespace: lab-volumes
spec:
  containers:
  - name: app
    image: centos:centos7
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 5; done"]
    volumeMounts:
    - name: persistent-storage
      mountPath: /data
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: bsu-claim

Application du Pod

Appliquez ce fichier avec la commande suivante :

kubectl apply -f pod-rwo.yaml

Maintenant que le Pod est déployé dans votre cluster, si vous listez de nouveau les PVC, le STATUS de notre PVC devrait avoir changé. La sortie attendue doit indiquer que le PVC est dans l’état Bound et qu’il est associé à un volume persistant :

kubectl get pvc -n lab-volumes
NAME         STATUS   VOLUME                                    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
bsu-claim    Bound    pvc-xxxx-xxxx-xxxx-xxxx                   5Gi        RWO            bsu-standard   5s

Dans cet exemple, le PVC bsu-claim est lié au volume pvc-xxxx-xxxx-xxxx-xxxx, avec une capacité de 5Gi et un mode d’accès ReadWriteOnce. Ceci car le Pod que nous avons déployé utilise le PVC crée plus tôt dans notre TP.

Tester le Pod

Vérifiez que le Pod est en cours d’exécution avec la commande :

kubectl get pods -n lab-volumes

Accédez au Pod pour vérifier que le fichier est bien écrit sur le volume :

  kubectl exec -it app -n lab-volumes -- /bin/sh

Dans le conteneur, consultez le fichier /data/out.txt :

cat /data/out.txt
Fri Jun 20 14:37:04 UTC 2025
Fri Jun 20 14:37:09 UTC 2025
Fri Jun 20 14:37:14 UTC 2025
Fri Jun 20 14:37:19 UTC 2025

Vous devriez voir un fichier avec des dates ajoutées toutes les 5 secondes. Si vous souhaitez voir l’évolution des dates dans ce fichier, vous pouvez utiliser la commande suivante:

tail -f /data/out.txt
Fri Jun 20 14:37:04 UTC 2025
Fri Jun 20 14:37:09 UTC 2025
Fri Jun 20 14:37:14 UTC 2025
Fri Jun 20 14:37:19 UTC 2025
Fri Jun 20 14:37:24 UTC 2025
Fri Jun 20 14:37:29 UTC 2025
Fri Jun 20 14:37:34 UTC 2025
Fri Jun 20 14:37:39 UTC 2025
Fri Jun 20 14:37:44 UTC 2025
...

Appliquer les CRDS du external snapshotter

kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/release-8.0/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/release-8.0/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/release-8.0/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/release-8.0/deploy/kubernetes/snapshot-controller/rbac-snapshot-controller.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/release-8.0/deploy/kubernetes/snapshot-controller/setup-snapshot-controller.yaml

Créer un `VolumeSnapshot`

Créer une Snapshot du volume Appliquez la définition de la snapshot en faisant référence au PersistentVolumeClaim :

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: bsu-volume-snapshot
  namespace: lab-volumes
spec:
  volumeSnapshotClassName: csi-osc-vsc
  source:
    persistentVolumeClaimName: bsu-claim

Attendre que la snapshot soit prête à l’emploi

Vérifiez que l’attribut Ready To Use est à true :

kubectl describe volumesnapshot.snapshot.storage.k8s.io bsu-volume-snapshot

Supprimer l’application existante

Supprimez les ressources de l’application courante :

kubectl delete pod app -n lab-volumes
kubectl delete pvc bsu-claim -n lab-volumes

Restaurer un volume depuis la snapshot

Créez une nouvelle PersistentVolumeClaim en se basant sur la VolumeSnapshot via le champ dataSource :

apiVersion: v1
kind: Pod
metadata:
  name: app
  namespace: lab-volumes
spec:
  containers:
  - name: app
    image: centos:centos7
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 5; done"]
    volumeMounts:
    - name: persistent-storage
      mountPath: /data
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: bsu-snapshot-restored-claim
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: bsu-snapshot-restored-claim
  namespace: lab-volumes
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: bsu-sc
  resources:
    requests:
      storage: 5Gi
  dataSource:
    name: bsu-volume-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io

Valider que les données sont restaurées

Comparez l’horodatage (timestamp) de la première entrée dans le fichier restauré :

kubectl exec -it app -n lab-volumes -- /bin/sh