Storage

Cette page explique les concepts de stockage de Google Distributed Cloud (logiciel uniquement) pour VMware.

Résumé

Google Distributed Cloud s'intègre aux systèmes externes de stockage de blocs ou de fichiers via :

  • Le pilote Container Storage Interface (CSI) vSphere
  • Des pilotes CSI tiers
  • Plug-ins de volume "in-tree" Kubernetes

Datastores vSphere

Lorsque vous créez un cluster d'administrateur, vous spécifiez un datastore vSphere existant pour les données etcd du cluster.

Lorsque vous créez un cluster d'utilisateur, vous pouvez utiliser le même datastore que le cluster d'administrateur ou en spécifier un autre. Vous pouvez également spécifier des datastores pour des pools de nœuds individuels.

Les datastores vSphere utilisés par les clusters d'administrateur et d'utilisateur peuvent être sauvegardés par NFS, vSAN ou VMFS sur un appareil de stockage en mode bloc, tel qu'un tableau de stockage externe. Dans un environnement multi-hôte, chaque appareil de stockage en mode bloc doit être associé à tous les hôtes de l'environnement, et le datastore doit être configuré sur chaque hôte via l'option Installer Datastore sur des hôtes supplémentaires.

StorageClasses

Lorsque vous créez un PersistentVolumeClaim, vous pouvez spécifier une StorageClass qui fournit des informations sur le provisionnement de l'espace de stockage. Si vous ne spécifiez pas de StorageClass, la StorageClass par défaut est utilisée.

StorageClass de cluster d'administrateur

Dans les clusters d'administrateur, il existe une StorageClass nommée standard, qui est désignée comme StorageClass par défaut. La StorageClass standard désigne le plug-in de volume "in-tree" vSphere comme étant l'approvisionneur.

Pour afficher la StorageClass standard :

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get storageclass \
    standard --output yaml

Dans le résultat, vous pouvez voir que standard est la StorageClass par défaut et que l'approvisionneur est le plug-in de volume "in-tree" vSphere, kubernetes.io/vsphere-volume. Vous pouvez également voir le nom d'un datastore vSphere.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
  ...
  labels:
    bundle.gke.io/component-name: admin-storage-class
  name: standard
...
parameters:
  datastore: vsanDatastore
provisioner: kubernetes.io/vsphere-volume
...

StorageClass de cluster d'utilisateur

Dans les clusters d'utilisateur, il existe une StorageClass nommée standard et une autre StorageClass nommée standard-rwo.

La StorageClass standard-rwo est désignée comme StorageClass par défaut, et elle désigne le pilote CSI vSphere comme étant l'approvisionneur.

Pour afficher la StorageClass standard-rwo :

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get storageclass \
    standard-rwo --output yaml

Dans le résultat, vous pouvez voir que standard-rwo est le StorageClass par défaut et que l'approvisionneur est le pilote CSI vSphere, csi.vsphere.vmware.com. Vous pouvez également voir l'URL d'un datastore vSphere :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
    ...
  labels:
    bundle.gke.io/component-name: user-vsphere-csi-driver-addon
    ...
  name: standard-rwo
...
parameters:
  datastoreURL: ds:///vmfs/volumes/vsan:52fb6ca22be2454e-e67f620175964a9f/
provisioner: csi.vsphere.vmware.com
...

Plug-ins de volume "in-tree" Kubernetes

Kubernetes est fourni avec un certain nombre de plug-ins de volume "in-tree". Toutefois, la plupart de ces plug-ins de volume "in-tree" sont obsolètes (y compris le plug-in de volume "in-tree" vSphere). Pour en savoir plus, consultez le projet de migration CSI.

Migration CSI pour le pilote de stockage vSphere

Auparavant, le plug-in de volume vSphere "in-tree" était l'approvisionneur de la ressource StorageClass par défaut dans les clusters d'utilisateur. Cependant, le plug-in de volume vSphere "in-tree" est désormais obsolète, et le pilote CSI vSphere est l'approvisionneur de la StorageClass par défaut dans les clusters d'utilisateur. Nous vous recommandons d'utiliser le pilote CSI vSphere plutôt que le plug-in de volume "in-tree".

À partir de la version 1.15 de Google Distributed Cloud, la fonctionnalité de migration CSI de Kubernetes est activée par défaut pour le plug-in de volume vSphere "in-tree". Cela signifie que si une charge de travail utilise un volume vSphere "in-tree", tous les appels d'opérations de stockage interne sont automatiquement redirigés vers le pilote CSI vSphere.

Par exemple, supposons qu'un PersistentVolumeClaim spécifie la StorageClass standard, qui répertorie le plug-in de volume "in-tree" vSphere, kubernetes.io/vsphere-volume, en tant qu'approvisionneur. Les appels d'opérations de stockage de toute charge de travail qui utilise ce PersistentVolumeClaim seront alors redirigés vers le pilote CSI vSphere, csi.vsphere.vmware.com.

Vérifications préliminaires

Lorsque vous créez ou mettez à niveau un cluster, des vérifications préliminaires permettent de s'assurer que votre environnement est adapté à la migration CSI.

Par exemple, les vérifications préliminaires :

  • Vérifient que vos versions de vCenter et d'ESXi sont appropriées.
  • Vérifient que le pilote CSI vSphere est activé s'il existe des PersistentVolume vSphere "in-tree".
  • Vérifient que les StorageClass vSphere ne comportent pas de paramètres ignorés après la migration CSI.
  • Vérifient les annotations sur les PersistentVolume et les PersistentVolumeClaim "in-tree" créés de manière statique, requises pour la migration CSI.
  • Vérifient que le cluster peut exécuter une charge de travail à l'aide d'un volume CSI provisionné par le pilote CSI vSphere.

Pour en savoir plus, consultez la section Exécuter des vérifications préliminaires.

Problèmes connus

Il existe plusieurs problèmes connus liés au pilote CSI vSphere. Pour en savoir plus et connaître les solutions de contournement, consultez la section "Problèmes connus" dans les notes de version sur le pilote CSI vSphere 3.0 de VMWare.

Migration complète vers CSI

La fonctionnalité de migration CSI de Kubernetes étant activée par défaut dans la version 1.15, le PersistentVolume soutenu par le plug-in de volume vSphere "in-tree" continue de fonctionner dans un environnement CSI uniquement. Il redirige simplement les appels d'opérations de plug-in "in-tree" vers le plug-in CSI. Étant donné que la spécification PersistentVolume est immuable, elle sera identique à celle du plug-in de volume "in-tree".

Par conséquent, l'ensemble complet des fonctionnalités CSI, comme l'expansion de volume et l'instantané de volume, n'est pas disponible pour ces volumes. Pour profiter de ces fonctionnalités, la charge de travail avec état doit être entièrement migrée vers CSI en recréant la spécification de ressource Kubernetes avec des champs CSI. Nous avons développé un outil automatisé pour vous aider à migrer les charges de travail avec état vers CSI sans interruption de l'application. Vous pourrez ainsi utiliser l'ensemble des fonctionnalités CSI.

Utiliser des pilotes tiers

Si vous souhaitez provisionner des volumes de stockage autres que les Datastore vSphere, vous pouvez créer une nouvelle StorageClass dans un cluster utilisant un autre pilote de stockage. Vous pouvez ensuite définir la StorageClass comme valeur par défaut du cluster ou configurer vos charges de travail à l'aide de la StorageClass (exemple StatefulSet).

Partenaires de stockage

Nous avons établi un partenariat avec de nombreux fournisseurs de stockage pour assurer la compatibilité de leurs systèmes de stockage avec Google Distributed Cloud. Consultez la liste complète des partenaires de stockage qualifiés.

Expansion de volume

Vous pouvez augmenter la taille d'un volume persistant après son provisionnement en modifiant la demande de capacité dans le PersistentVolumeClaim. Vous pouvez augmenter la capacité en ligne lorsque le volume est utilisé par un pod ou hors connexion lorsque le volume n'est pas utilisé.

Pour le pilote CSI vSphere, l'expansion hors connexion est disponible à partir de la version 7.0 de vSphere et l'expansion en ligne à partir de la mise à jour 2 de la version 7.0 de vSphere.

La StorageClass standard-rwo définit allowVolumeExpansion sur "true" par défaut pour les clusters nouvellement créés et exécutés sur vSphere 7.0 ou une version ultérieure. Vous pouvez utiliser l'expansion en ligne et hors connexion pour les volumes utilisant cette StorageClass. Étant donné que les StorageClass ne sont pas modifiées lors des mises à niveau d'un cluster, lorsqu'un cluster est mis à niveau de la version 1.7 vers la version 1.8, le paramètre allowVolumeExpansion dans standard-rwo reste non défini, ce qui signifie que l'expansion de volume n'est pas autorisée.

Pour en savoir plus sur l'expansion de volume, consultez la page Utiliser l'expansion de volume.

Instantanés du volume CSI

Vous pouvez créer des instantanés du stockage persistant à l'aide des ressources VolumeSnapshot et VolumeSnapshotClass. Pour utiliser cette fonctionnalité sur un volume CSI, le pilote CSI doit être compatible avec les instantanés de volume, et le conteneur side-car external-snapshotter doit être inclus dans le déploiement du pilote CSI.

Pour en savoir plus sur les instantanés de volume, consultez la page Utiliser des instantanés de volume.

Les contrôleurs d'instantané CSI sont déployés automatiquement lorsque vous créez un cluster.

Nettoyage des volumes

Lorsque vous supprimez un cluster d'utilisateur, les volumes provisionnés par le pilote CSI vSphere ne sont pas supprimés. Vous devez supprimer tous les volumes, les PersistentVolumeClaim et les StatefulSet avant de supprimer le cluster.

Dépannage

Consultez la page Dépannage du système de stockage.

Documentation complémentaire