Ce document a été traduit à l'aide d'une technologie de traduction automatique. Bien que nous nous efforcions de fournir des traductions exactes, nous ne fournissons aucune garantie quant à l'exhaustivité, l'exactitude ou la fiabilité du contenu traduit. En cas de divergence, la version originale anglaise prévaut et fait foi.

Stockage VMware vSphere

Pour fournir aux charges de travail à état le stockage VMware vSphere, nous recommandons de créer une StorageClass vSphereVolume. Cette pratique provisionne dynamiquement le stockage vSphere lorsque les charges de travail à état demandent des volumes via un PersistentVolumeClaim.

Pour provisionner dynamiquement le stockage dans vSphere, le fournisseur vSphere doit être activé. Voir les pages suivantes pour plus d’informations : vSphere hors-arborescence et vSphere intégré.

Conditions préalables

Pour provisionner des volumes vSphere dans un cluster créé avec le RKE2, le fournisseur de cloud vSphere doit être explicitement activé dans les options du cluster.

Créer une StorageClass

Les étapes suivantes peuvent également être effectuées en utilisant l’outil en ligne de commande kubectl. Voir la documentation Kubernetes sur les volumes persistants pour plus de détails.

  1. Cliquez sur ☰ > Gestion des clusters.

  2. Choisissez le cluster auquel vous souhaitez fournir un stockage vSphere et cliquez sur Explorer.

  3. Dans la barre de navigation à gauche, sélectionnez Stockage  Classes de stockage.

  4. Cliquez sur Create.

  5. Entrez un Nom pour la StorageClass.

  6. Sous Provisionneur, sélectionnez Volume VMware vSphere.

    vsphere storage class

  7. Optionnellement, spécifiez des propriétés supplémentaires pour cette classe de stockage sous Paramètres. Référez-vous à la documentation sur le stockage vSphere pour plus de détails.

  8. Cliquez sur Create.

Créer une charge de travail avec un volume VMware vSphere

  1. Dans la barre de navigation à gauche, cliquez sur Charge de travail.

  2. Cliquez sur Create.

  3. Cliquez sur StatefulSet.

  4. Dans l’onglet Modèles de demande de volume, cliquez sur Ajouter un modèle de demande.

  5. Entrez un nom de volume persistant.

  6. Dans le champ Classe de stockage, sélectionnez la StorageClass vSphere que vous avez créée.

  7. Entrez la Capacité requise pour le volume. Puis cliquez sur Définir.

  8. Attribuez un chemin dans le champ Point de montage. Ceci est le chemin complet où le volume sera monté dans le système de fichiers du conteneur, par exemple /persistent.

  9. Cliquez sur Create.

Vérification de la persistance du volume

  1. Dans la barre de navigation à gauche, cliquez sur Charge de travail  Pods.

  2. Allez à la charge de travail que vous venez de créer et cliquez sur ⋮ > Exécuter le shell.

  3. Notez le répertoire à la racine où le volume a été monté (dans ce cas /persistent).

  4. Créez un fichier dans le volume en exécutant la commande touch /<volumeMountPoint>/data.txt.

  5. Fermez la fenêtre du shell.

  6. Cliquez sur le nom de la charge de travail pour révéler des informations détaillées.

  7. Cliquez sur ⋮ > Supprimer.

  8. Observez que le pod est supprimé. Ensuite, un nouveau pod est programmé pour le remplacer afin que la charge de travail maintienne son échelle configurée d’un seul pod stateful.

  9. Une fois que le pod de remplacement est en cours d’exécution, cliquez sur Exécuter le shell.

  10. Inspectez le contenu du répertoire où le volume est monté en entrant ls -l /<volumeMountPoint>. Notez que le fichier que vous avez créé précédemment est toujours présent.

    workload-persistent-data

Pourquoi utiliser des StatefulSets au lieu de déploiements

Vous devez toujours utiliser StatefulSets pour les charges de travail consommant du stockage vSphere, car ce type de ressource est conçu pour répondre à un inconvénient de stockage en bloc VMDK.

Étant donné que les volumes vSphere sont soutenus par un stockage de blocs VMDK, ils ne prennent en charge qu’un mode d’accès de ReadWriteOnce. Ce paramètre restreint le volume afin qu’il ne puisse être monté que sur un seul pod à la fois, sauf si tous les pods utilisant ce volume sont co-localisés sur le même nœud. Ce comportement rend une ressource de déploiement inutilisable pour une mise à l’échelle au-delà d’une seule réplique si elle consomme des volumes vSphere.

Même l’utilisation d’une ressource de déploiement avec une seule réplique peut entraîner une situation de blocage lors de la mise à jour du déploiement. Si le pod mis à jour est programmé sur un nœud différent de celui où se trouve le pod existant, il échouera à démarrer car le VMDK est toujours attaché à l’autre nœud.

Liens connexes