Configurer des volumes persistants multi-attach avec OVHcloud NAS-HA

Objectif

OVHcloud Managed Kubernetes intègre nativement le Block Storage comme volumes persistants. Cette technologie peut cependant ne pas convenir à certaines applications legacy ou non cloud-native, qui nécessitent souvent de partager ces données persistantes entre différents pods sur plusieurs worker nodes (ReadWriteMany ou RWX). Si vous devez faire cela pour certains de vos workloads, une solution consiste à utiliser des volumes NFS. OVHcloud NAS-HA est une solution managée qui vous permet de configurer facilement un serveur NFS et plusieurs volumes NFS. Dans ce tutoriel, nous allons voir comment configurer votre cluster OVHcloud Managed Kubernetes pour utiliser OVHcloud NAS-HA comme fournisseur NFS pour les Persistent Volumes Kubernetes.

Prérequis

Ce tutoriel suppose que vous disposez déjà d'un cluster OVHcloud Managed Kubernetes fonctionnel, ainsi que de connaissances de base sur son utilisation. Pour en savoir plus sur ces sujets, consultez la documentation déployer une application Hello World.

Ce tutoriel suppose également que vous disposez déjà d'un service OVHcloud NAS-HA. Si ce n'est pas le cas, vous pouvez en commander un dans l'espace client OVHcloud.

Vous devez également avoir Helm installé sur votre poste de travail ; consultez le tutoriel comment installer Helm sur OVHcloud Managed Kubernetes Service.

Accès à l'espace client OVHcloud

• Lien direct : NAS-HA
• Pour accéder à vos services : Bare Metal Cloud > NAS-HA > Sélectionnez votre NAS-HA

En pratique

Étape 1 - Créer une partition et autoriser votre Managed Kubernetes Service à y accéder

Votre NAS-HA peut exposer plusieurs partitions et prend en charge différents protocoles. Chaque partition n'est accessible que depuis une plage d'IP spécifique. Vous allez en créer une exposant NFS et la rendre accessible depuis vos worker nodes Kubernetes.

Cliquez sur votre NAS, puis sur l'onglet Partitions, puis sur le bouton Créer une partition. Renseignez le nom de la partition, définissez la taille souhaitée et sélectionnez NFS comme protocole, puis confirmez pour créer la partition.

Votre cluster est installé avec un réseau public, ou un réseau privé sans utiliser une OVHcloud Internet Gateway ou une gateway personnalisée comme route par défaut

Une fois la partition créée, vous devez autoriser vos nœuds Kubernetes à accéder à la partition nouvellement créée.

Récupérez l'IP de vos nœuds Kubernetes :

kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="InternalIP")].address }'

$ kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="InternalIP")].address }'
51.77.204.175 51.77.205.79

Votre cluster est installé avec un réseau privé et une route par défaut via votre réseau privé (OVHcloud Internet Gateway/OpenStack Router ou une gateway personnalisée)

Vos nœuds étant configurés pour être routés par la gateway du réseau privé, vous devez ajouter l'adresse IP de la gateway aux ACL.

En utilisant une Gateway Public Cloud avec votre Managed Kubernetes Service, les IP publiques sur les nœuds ne servent qu'à des fins d'administration : Limites connues de MKS

Vous pouvez récupérer l'IP publique de votre OVHcloud Internet Gateway en naviguant dans l'espace client OVHcloud :

Public Cloud > sélectionnez votre tenant > Network / Gateway > Public IP

Vous pouvez également récupérer l'IP publique de votre OVHcloud Internet Gateway en utilisant nos API :

Vous trouverez plus de détails sur l'utilisation des API OVHcloud dans ce guide : Premiers pas avec les API OVHcloud

Si vous souhaitez utiliser votre cluster Kubernetes pour connaître l'IP publique de votre Gateway, vous pouvez exécuter ces commandes :

kubectl run get-gateway-ip --image=ubuntu:latest -i --tty --rm 

Cette commande va créer un pod temporaire et ouvrir une console.

Vous devrez peut-être attendre un peu que le pod soit créé. Une fois le shell affiché, vous pouvez exécuter cette commande :

apt update && apt upgrade -y && apt install -y curl && curl ifconfig.me

L'IP publique de la Gateway que vous utilisez devrait s'afficher.

Cliquez sur le menu Manage Access de votre partition nouvellement créée. Ajoutez soit les IP des nœuds une par une, soit l'IP publique de la Gateway selon votre configuration. Pour chaque entrée, cliquez sur Add an access, saisissez l'adresse IP, puis confirmez.

Une fois les règles d'accès enregistrées, notez l'IP du zpool (ZPOOL_IP), le nom du zpool (ZPOOL_NAME) et le nom de la partition (PARTITION_NAME) affichés sur la page de détails de la partition.

Dans cet exemple, notre ZPOOL_IP est 10.201.18.33, notre ZPOOL_NAME est zpool-127659, et notre PARTITION_NAME est kubernetes. Adaptez ces valeurs en conséquence dans les étapes suivantes.

Étape 2 - Configurer Kubernetes pour utiliser votre partition NFS nouvellement créée

Votre cluster Kubernetes a besoin de quelques composants logiciels supplémentaires pour utiliser la partition NFS. Vous allez les installer, puis créer un premier volume, partagé entre plusieurs pods.

Pour cela, installez le csi-driver-nfs :

helm repo add csi-driver-nfs https://raw.githubusercontent.com/kubernetes-csi/csi-driver-nfs/master/charts
helm install csi-driver-nfs csi-driver-nfs/csi-driver-nfs --namespace kube-system --version v4.7.0 --set driver.name="nfs2.csi.k8s.io" --set controller.name="csi-nfs2-controller" --set rbac.name=nfs2

$ helm install csi-driver-nfs -n kube-system csi-driver-nfs/csi-driver-nfs --version v4.7.0 --set driver.name="nfs2.csi.k8s.io" --set rbac.name=nfs --set controller.name="csi-nfs2-controller"
NAME: csi-driver-nfs
LAST DEPLOYED: Thu Jul 11 15:13:34 2024
NAMESPACE: kube-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
The CSI NFS Driver is getting deployed to your cluster.

To check CSI NFS Driver pods status, please run:

  kubectl --namespace=kube-system get pods --selector="app.kubernetes.io/instance=csi-driver-nfs" --watch

Vérifiez votre installation :

kubectl --namespace=kube-system get pods --selector="app.kubernetes.io/instance=csi-driver-nfs"

$ kubectl --namespace=kube-system get pods --selector="app.kubernetes.io/instance=csi-driver-nfs"
NAME                                   READY   STATUS    RESTARTS   AGE
csi-nfs-node-2qczs                     3/3     Running   0          16s
csi-nfs-node-tw77p                     3/3     Running   0          16s
csi-nfs2-controller-58b8b4cf7f-nk727   4/4     Running   0          16s

Étape 3 - Créer l'objet StorageClass NFS

Créez un fichier nfs-storageclass.yaml :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-csi
provisioner: nfs2.csi.k8s.io
parameters:
  server: '[ZPOOL_IP]'
  share: '/[ZPOOL_NAME]/[PARTITION_NAME]'
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
  - nfsvers=4.1
  - tcp
  - rsize=1048576
  - wsize=1048576

Appliquez ensuite le fichier YAML pour créer la StorageClass :

kubectl apply -f nfs-storageclass.yaml

Étape 4 - Créer et utiliser un volume persistant NFS

Créez un fichier nfs-persistent-volume-claim.yaml :

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: nfs-pvc
  namespace: default
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: nfs-csi
  resources:
    requests:
      storage: 1Gi

Appliquez ce fichier pour créer la persistent volume claim :

kubectl apply -f nfs-persistent-volume-claim.yaml

Vous pouvez obtenir plus d'informations sur la PVC en exécutant cette commande :

kubectl describe pvc nfs-pvc

$ kubectl describe pvc nfs-pvc
Name:          nfs-pvc
Namespace:     default
StorageClass:  nfs-csi
Status:        Pending
Volume:
[...]
Events:
  Type    Reason                 Age                   From                                                                                             Message
  ----    ------                 ----                  ----                                                                                             -------
  Normal  Provisioning           2m25s                 nfs2.csi.k8s.io_nodepool-c7ef08a9-2a22-40fd-9c-node-993f96_7078d019-f44a-42a1-8e7f-c6ee36f3f466  External provisioner is provisioning volume for claim "default/nfs-pvc"
  Normal  ExternalProvisioning   15s (x10 over 2m25s)  persistentvolume-controller                                                                      Waiting for a volume to be created either by the external provisioner 'nfs2.csi.k8s.io' or manually by the system administrator. If volume creation is delayed, please verify that the provisioner is running and correctly registered.

Le provisioner externe (ici le NAS-HA) provisionne votre volume. Attendez un peu, le volume devrait apparaître :

$ kubectl describe pvc nfs-pvc
Name:          nfs-pvc
Namespace:     default
StorageClass:  nfs-csi
Status:        Bound
Volume:        pvc-a213e1a9-2fee-4632-ae9e-c952fab74e38
[...]
Events:
  Type    Reason                 Age                   From                                                                                             Message
  ----    ------                 ----                  ----                                                                                             -------
  Normal  Provisioning           2m25s                 nfs2.csi.k8s.io_nodepool-c7ef08a9-2a22-40fd-9c-node-993f96_7078d019-f44a-42a1-8e7f-c6ee36f3f466  External provisioner is provisioning volume for claim "default/nfs-pvc"
  Normal  ExternalProvisioning   15s (x10 over 2m25s)  persistentvolume-controller                                                                      Waiting for a volume to be created either by the external provisioner 'nfs2.csi.k8s.io' or manually by the system administrator. If volume creation is delayed, please verify that the provisioner is running and correctly registered.
  Normal  ProvisioningSucceeded  14s                   nfs2.csi.k8s.io_nodepool-c7ef08a9-2a22-40fd-9c-node-993f96_7078d019-f44a-42a1-8e7f-c6ee36f3f466  Successfully provisioned volume pvc-a213e1a9-2fee-4632-ae9e-c952fab74e38

Si vous rencontrez des erreurs telles que :

Warning  ProvisioningFailed    3s (x3 over 7s)  nfs2.csi.k8s.io_nodepool-c7ef08a9-2a22-40fd-9c-node-993f96_7078d019-f44a-42a1-8e7f-c6ee36f3f466  failed to provision volume with StorageClass "nfs-csi": rpc error: code = Internal desc = failed to make subdirectory: mkdir /tmp/pvc-31210848-7f3f-40e6-aa7a-fafa616da4e7/pvc-31210848-7f3f-40e6-aa7a-fafa616da4e7: input/output error

ou telles que :

Warning  ProvisioningFailed    1s (x3 over 4s)  nfs2.csi.k8s.io_nodepool-8bdec3f1-f54a-4de8-ad-node-091e7d_15634ab1-b7e2-45b5-9565-3a775490c4e3  failed to provision volume with StorageClass "nfs-csi": rpc error: code = Internal desc = failed to mount nfs server: rpc error: code = Internal desc = mount failed: exit status 32
Mounting command: mount
Mounting arguments: -t nfs -o nfsvers=4.1 [ZPOOL_IP]:/[ZPOOL_NAME]/[PARTITION_NAME] /tmp/pvc-f7693542-a817-472d-bb55-de7af91306b5
Output: mount.nfs: access denied by server while mounting [ZPOOL_IP]:/[ZPOOL_NAME]/[PARTITION_NAME]

Cela signifie le plus souvent qu'un problème est survenu avec les ACL du NAS-HA. Vérifiez les IP autorisées à accéder à la partition souhaitée dans la liste des ACL.

Créez maintenant un DaemonSet de pods Nginx utilisant la persistent volume claim comme dossier racine web (webroot).

L'utilisation d'un DaemonSet créera un pod sur chaque nœud déployé, ce qui facilite le dépannage en cas de mauvaise configuration ou permet d'isoler un problème sur un nœud.

Créez un fichier nommé nginx-daemonset.yaml :

apiVersion: apps/v1
kind: DaemonSet
metadata:
    name: nfs-nginx
    namespace: default
spec:
    selector:
      matchLabels:
        name: nginx
    template:
        metadata:
          labels:
            name: nginx
        spec:
          volumes:
          - name: nfs-volume
            persistentVolumeClaim:
              claimName: nfs-pvc
          containers:
          - name: nginx
            image: nginx
            ports:
            - containerPort: 80
              name: "http-server"
            volumeMounts:
            - mountPath: "/usr/share/nginx/html"
              name: nfs-volume

Appliquez ce fichier pour créer le DaemonSet Nginx :

kubectl apply -f nginx-daemonset.yaml

Les deux pods devraient être en cours d'exécution :

kubectl get pods
NAME          READY   STATUS    RESTARTS   AGE
nfs-nginx-29r49   1/1     Running   0          14m
nfs-nginx-f5j92   1/1     Running   0          14m

Entrez dans le premier pod et conteneur Nginx pour vérifier que le zpool est correctement monté, et créez un fichier sur le volume persistant NFS :

FIRST_POD=$(kubectl get pod -l name=nginx --no-headers=true -o custom-columns=:metadata.name | head -1)
kubectl exec -it $FIRST_POD -n default -- bash

Vérifiez que le zpool est monté sur le pod Nginx :

root@nfs-nginx-29r49:/# mount -l | grep zpool
[ZPOOL_IP]:/[ZPOOL_NAME]/[PARTITION_NAME]/[PV_NAME] on /usr/share/nginx/html type nfs4 (rw,relatime,vers=4.1,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=[NODE_IP],local_lock=none,addr=[ZPOOL_IP])

Vous pouvez tester les IOPS et la vitesse du NAS-HA en installant et en exécutant l'outil FIO dans un conteneur :

apt update
apt install fio

Puis en exécutant ces commandes (n'oubliez pas de vous déplacer dans le dossier monté depuis le NAS-HA) :

cd /usr/share/nginx/html/
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=testfiofrommks --filename=random_read_write.fio --bs=128k --iodepth=64 --size=10G --readwrite=randrw --rwmixread=75

À la fin du benchmark, vous devriez obtenir un résultat comme celui-ci :

End of the FIO test:

testfiofrommks: Laying out IO file (1 file / 10240MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=117MiB/s,w=36.1MiB/s][r=933,w=289 IOPS][eta 00m:00s]
testfiofrommks: (groupid=0, jobs=1): err= 0: pid=748: Tue May 21 15:22:14 2024
  read: IOPS=931, BW=116MiB/s (122MB/s)(7683MiB/65965msec)
   bw (  KiB/s): min=119040, max=119824, per=100.00%, avg=119333.25, stdev=106.46, samples=131
   iops        : min=  930, max=  936, avg=932.29, stdev= 0.83, samples=131
  write: IOPS=310, BW=38.8MiB/s (40.7MB/s)(2557MiB/65965msec); 0 zone resets
  [...]

Vous allez maintenant vérifier que le NAS-HA est correctement partagé entre les pods déployés.

Créez un nouveau fichier index.html :

echo "NFS volume!" > /usr/share/nginx/html/index.html

Puis quittez le conteneur Nginx :

exit

Essayez d'accéder à votre nouvelle page web :

kubectl proxy

Générez l'URL à ouvrir dans votre navigateur :

URL=$(echo "http://localhost:8001/api/v1/namespaces/default/pods/http:$FIRST_POD:/proxy/")
echo $URL

Vous pouvez ouvrir l'URL affichée pour accéder au Service Nginx.

Vérifiez maintenant si les données sont partagées avec le second pod (si vous avez déployé plus d'un nœud).

$ SECOND_POD=$(kubectl get pod -l name=nginx --no-headers=true -o custom-columns=:metadata.name | head -2 | tail -1)
URL2=$(echo "http://localhost:8001/api/v1/namespaces/default/pods/http:$SECOND_POD:/proxy/")
echo $URL2

Vous pouvez ouvrir l'URL affichée pour accéder au Service Nginx sur l'autre pod.

Comme vous pouvez le constater, les données sont correctement partagées entre les deux pods Nginx exécutés sur deux nœuds Kubernetes différents.

Félicitations, vous avez configuré avec succès un volume persistant multi-attach avec OVHcloud NAS-HA !

Aller plus loin

Pour en savoir plus sur l'utilisation pratique de votre cluster Kubernetes, consultez notre site de documentation OVHcloud Managed Kubernetes.

• 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.