Volumes persistants sur OVHcloud Managed Kubernetes Service

Ce tutoriel décrit la mise en place d'un Persistent Volume (PV) sur OVHcloud Managed Kubernetes Service.

Pour provisionner un volume, une Persistent Volume Claim (PVC) est requise. Celle-ci crée automatiquement un Persistent Volume (PV) associé à un volume Public Cloud Block Storage.

Le volume Block Storage devient alors disponible pour tout pod qui le réclame via une PVC.

Prérequis

Un cluster MKS opérationnel : consultez le guide Démarrage rapide avec OVHcloud Managed Kubernetes Service pour plus d'informations.

Persistent Volumes (PV) et Persistent Volume Claims (PVC)

Comme l'indique la documentation officielle :

• Un PersistentVolume (PV) est un espace de stockage du cluster provisionné par un administrateur ou provisionné dynamiquement à l'aide de Storage Classes. C'est une ressource du cluster, au même titre qu'un nœud est une ressource du cluster.
• Une PersistentVolumeClaim (PVC) est une demande de stockage émise par un utilisateur. Elle est similaire à un pod. Les pods consomment des ressources de nœud et les PVC consomment des ressources de PV. Les pods peuvent demander des niveaux spécifiques de ressources (CPU et mémoire). Les claims peuvent demander une taille et des modes d'accès spécifiques (par exemple, ils peuvent être montés une fois en lecture/écriture ou plusieurs fois en lecture seule).

Créer une PVC

L'exemple suivant, test-pvc.yaml, réserve un volume de 10Gi avec la storage class csi-cinder-high-speed :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: csi-cinder-high-speed

Pour la créer sur un cluster :

kubectl apply -f test-pvc.yaml

Pour vérifier que la PersistentVolumeClaim (pvc) et son PersistentVolume (pv) associé ont bien été créés :

kubectl get pvc
kubectl get pv | grep "test-pvc"

Exemple de résultat :

$ kubectl apply -f test-pvc.yaml
persistentvolumeclaim/test-pvc created

$ kubectl get pvc
NAME       STATUS   VOLUME                                                                   CAPACITY   ACCESS MODES   STORAGECLASS            AGE
test-pvc   Bound    ovh-managed-kubernetes-dmhe43-pvc-ac9493f5-e65f-41ee-a7fa-45d42fc37fe3   10Gi       RWO            csi-cinder-high-speed   4m5s

$ kubectl get pv | grep "test-pvc"
ovh-managed-kubernetes-dmhe43-pvc-ac9493f5-e65f-41ee-a7fa-45d42fc37fe3   10Gi       RWO            Delete           Bound      default/test-pvc                               csi-cinder-high-speed            4m55s

Utiliser la PVC

Ce pod d'exemple monte le volume provisionné via sa PVC :

apiVersion: v1
kind: Pod
metadata:
  name: test-pvc-pod
spec:
  containers:
  - name: myfrontend
    image: nginx
    volumeMounts:
    - mountPath: "/usr/share/nginx/html"
      name: test-volume
  volumes:
  - name: test-volume
    persistentVolumeClaim:
      claimName: test-pvc

Pour le créer sur un cluster :

kubectl apply -f test-pvc-pod.yaml

Pour vérifier que le pod a bien monté le volume et démarré avec succès :

kubectl describe pod test-pvc-pod

Exemple de résultat :

$ kubectl apply -f test-pvc-pod.yaml
pod/test-pvc-pod created

$ kubectl describe pod test-pvc-pod
Name:         test-pvc-pod
Namespace:    default
Priority:     0
Node:         nodepool-f636da5d-3d0d-481d-aa-node-f4d042/141.94.167.92
Start Time:   Mon, 28 Nov 2022 09:58:09 +0100
Labels:       <none>
Annotations:  <none>
Status:       Pending
IP:
IPs:          <none>
Containers:
  myfrontend:
    Container ID:
    Image:          nginx
    Image ID:
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       ContainerCreating
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /usr/share/nginx/html from test-volume (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-vgx5h (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  test-volume:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  test-pvc
    ReadOnly:   false
  kube-api-access-vgx5h:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  7s    default-scheduler  Successfully assigned default/test-pvc-pod to nodepool-f636da5d-3d0d-481d-aa-node-f4d042

Storage Classes

Les storage classes désignent une technologie de stockage particulière utilisée pour provisionner un volume. Cette storage class est indiquée dans la définition de la PersistentVolumeClaim. Consultez la documentation officielle pour plus d'informations.

Les storage classes suivantes sont actuellement prises en charge sur OVHcloud Managed Kubernetes :

• la storage class csi-cinder-high-speed-gen2 repose sur du matériel incluant des disques SSD avec interfaces NVMe. L'allocation de performance est progressive et linéaire (30 IOPS alloués par Go et 0,5 Mo/s alloué par Go) avec un maximum de 20k IOPS et 1 Go/s par volume. Les performances en IOPS et en bande passante augmentent à mesure que l'espace de stockage est augmenté.
• la performance de csi-cinder-high-speed est fixe. Vous obtenez jusqu'à 3 000 IOPS par volume, quelle que soit la taille du volume.
• csi-cinder-classic utilise des disques mécaniques traditionnels (200 IOPS garantis, jusqu'à 64 Mo/s par volume). (Pas encore pris en charge sur le plan MKS Standard. Reportez-vous aux limitations décrites dans la section Multi availability zones deployments de notre guide Limites connues). Toutes ces Storage Classes sont basées sur Cinder, le service de stockage bloc d'OpenStack. La différence entre elles réside dans le type de support physique de stockage associé. Elles sont distribuées de façon transparente, sur trois réplicas physiques locaux.

csi-cinder-high-speed est recommandée pour des volumes allant jusqu'à 100 Go. Au-delà de 100 Go par volume, une performance renforcée est obtenue avec les volumes csi-cinder-high-speed-gen2.

Classes de stockage chiffrées LUKS

OVHcloud Managed Kubernetes prend en charge les volumes de stockage bloc chiffrés LUKS à l'aide d'OVHcloud Managed Keys (OMK). Les classes de stockage chiffrées suivantes sont disponibles :

• csi-cinder-high-speed-gen2-luks - Version chiffrée de High Speed Gen2 (performance progressive)
• csi-cinder-high-speed-luks - Version chiffrée de High Speed (3 000 IOPS fixes)
• csi-cinder-classic-luks - Version chiffrée de Classic (disques mécaniques)

Pour plus d'informations :

• Choisir la classe de stockage bloc adaptée
• Créer des volumes persistants chiffrés sur des clusters OVHcloud Managed Kubernetes avec LUKS (tutoriel complet)

$ kubectl get storageclass
NAME                              PROVISIONER                RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
csi-cinder-high-speed (default)   cinder.csi.openstack.org   Delete          WaitForFirstConsumer   true                   11d
csi-cinder-high-speed-gen-2       cinder.csi.openstack.org   Delete          WaitForFirstConsumer   true                   11d
csi-cinder-high-speed-gen2-luks   cinder.csi.openstack.org   Delete          WaitForFirstConsumer   true                   11d
csi-cinder-high-speed-luks        cinder.csi.openstack.org   Delete          WaitForFirstConsumer   true                   11d

Lorsque vous créez une Persistent Volume Claim sur votre cluster Kubernetes, nous provisionnons le stockage Cinder dans votre compte. Ce stockage est facturé conformément aux tarifs de stockage cloud flexible d'OVHcloud.

Depuis Kubernetes 1.11, la prise en charge de l'extension des PersistentVolumeClaims (PVC) est activée par défaut, et elle fonctionne sur les volumes Cinder. Pour savoir comment les redimensionner, reportez-vous au tutoriel Redimensionner des volumes persistants. Le redimensionnement des PVC Kubernetes permet uniquement d'agrandir les volumes, pas de les réduire.

Modes d'accès

La façon dont un PV peut être monté sur un hôte dépend des capacités du fournisseur de ressources. Chaque PV dispose de son propre ensemble de modes d'accès décrivant les capacités spécifiques de ce PV :

• ReadWriteOnce : le PV peut être monté en lecture-écriture par un seul nœud
• ReadOnlyMany : le PV peut être monté en lecture seule par plusieurs nœuds
• ReadWriteMany : le PV peut être monté en lecture-écriture par plusieurs nœuds

Les storage classes MKS par défaut ne permettent pas de monter un PV sur plusieurs nœuds : seul le mode d'accès ReadWriteOnce est pris en charge pour le moment.

Des storage classes ReadWriteMany supplémentaires peuvent être configurées pour disposer de cette capacité :

• L'Enterprise File Storage offre un système de fichiers partagé managé, accessible via NFS.
• L'OVHcloud Cloud Disk Array offre un système de fichiers partagé managé, accessible via CephFS.

Politiques de rétention

Le comportement d'un volume lors de la suppression d'une PVC est configuré à l'aide d'une politique de rétention (reclaim policy). Cette politique est configurée au niveau de la StorageClass.

Toutes les storage classes installées par défaut sur MKS définissent actuellement la RetainPolicy sur Delete : lorsqu'une PVC est supprimée, le PV et son volume Public Cloud associé sont également supprimés.

Pour contrôler ce comportement au niveau du PersistentVolume, l'attribut persistentVolumeReclaimPolicy peut être défini dans le Spec du PV. Consultez la documentation officielle pour plus d'informations. Une autre valeur, comme Retain, peut être définie pour empêcher la suppression du volume.

Exemple : suppression d'une PVC et de ses ressources associées

Grâce à la politique de rétention Delete, si vous supprimez la PVC, le PV associé est également supprimé :

kubectl delete pod test-pvc-pod
kubectl delete pvc test-pvc
kubectl get pvc
kubectl get pv | grep "test-pvc"

$ kubectl delete po test-pvc-pod
pod "test-pvc-pod" deleted

$ kubectl delete pvc test-pvc
persistentvolumeclaim "test-pvc" deleted

$ kubectl get pvc
No resources found.

$ kubectl get pv | grep "test-pvc"
No resources found.

Exemple : suppression d'une PVC en conservant ses ressources associées

Pour illustrer comment modifier la politique de rétention, commencez par créer une nouvelle PVC à l'aide du fichier test-pvc.yaml :

kubectl apply -f test-pvc.yaml

Listez le PV et récupérez son nom :

kubectl get pv | grep "test-pvc"

Puis modifiez-le (patch) pour changer sa politique de rétention :

kubectl patch pv `<your-pv-name>` -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'

Où <your-pv-name> est le nom du PersistentVolume choisi.

Vous pouvez maintenant vérifier que le PV a la bonne politique :

kubectl get pv | grep "test-pvc"

$ kubectl apply -f test-pvc.yaml
persistentvolumeclaim/test-pvc created

$ kubectl get pv | grep "test-pvc"
NAME                                      CAPACITY  ACCESS MODES  RECLAIM POLICY  STATUS  CLAIM             STORAGECLASS           AGE
ovh-managed-kubernetes-btw8lc-pvc-LONG-ID 10Gi      RWO           Delete          Bound   default/test-pvc  csi-cinder-high-speed  19s

$ kubectl patch pv ovh-managed-kubernetes-btw8lc-pvc-LONG-ID -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
persistentvolume/ovh-managed-kubernetes-btw8lc-pvc-LONG-ID patched

$ kubectl get pv | grep "test-pvc"
NAME                                       CAPACITY  ACCESS MODES  RECLAIM POLICY  STATUS  CLAIM             STORAGECLASS           AGE
ovh-managed-kubernetes-btw8lc-pvc-LONG-ID  10Gi      RWO           Retain          Bound   default/test-pvc  csi-cinder-high-speed  19s

Dans le résultat précédent, vous pouvez constater que le volume lié à la PVC default/test-pvc a la politique de rétention Retain. Il ne sera pas automatiquement supprimé lorsqu'un utilisateur supprimera la PVC default/test-pvc

Aller plus loin

• Pour une formation ou une assistance technique sur la mise en œuvre de nos solutions, contactez votre commercial ou consultez la page Professional Services pour obtenir un devis et faire analyser votre projet par nos experts.

• Échangez avec notre communauté d'utilisateurs.