Cette page décrit les concepts de Google Distributed Cloud Storage.
Résumé
Google Distributed Cloud s'intègre aux systèmes externes de stockage de blocs ou de fichiers via:
- Pilote CSI (Container Storage Interface) vSphere
- 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 spécifier un autre datastore. 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'une baie de stockage externe. Dans un environnement à hôtes multiples, chaque périphérique 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 une PersistentVolumeClaim, vous pouvez spécifier une StorageClass qui fournit des informations sur le mode de provisionnement du stockage. Si vous ne spécifiez pas de StorageClass, la StorageClass par défaut est utilisée.
StorageClass du 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 répertorie le plug-in de volume vSphere in-tree en tant qu'approvisionneur.
Pour afficher la StorageClass standard:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get storageclass \
standard --output yaml
Dans la sortie, vous pouvez voir que standard est la StorageClass par défaut et que l'approvisionneur est le plug-in de volume vSphere in-tree, 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
...
StorageClasses du 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 le pilote CSI vSphere est répertorié en tant qu'approvisionneur.
Pour afficher la StorageClass standard-rwo:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get storageclass \
standard-rwo --output yaml
Dans la sortie, vous pouvez voir que standard-rwo est la 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". Cependant, la plupart de ces plug-ins de volume "in-tree" sont obsolètes (y compris le plug-in de volume vSphere in-tree). 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 StorageClass par défaut dans les clusters d'utilisateur. Toutefois, 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 au lieu du 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'une PersistentVolumeClaim spécifie la StorageClass standard, qui répertorie le plug-in de volume vSphere in-tree kubernetes.io/vsphere-volume en tant qu'approvisionneur. Ensuite, les appels d'opérations de stockage de toute charge de travail utilisant cette PersistentVolumeClaim seront 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érifiez que vos versions de vCenter et ESXI sont appropriées.
- Vérifiez que le pilote CSI vSphere est activé s'il existe des PersistentVolumes vSphere dans l'arborescence.
- Vérifiez que certains paramètres des StorageClasses vSphere ne sont pas ignorés après la migration CSI.
- Vérifiez les annotations sur les PersistentVolumes in-tree créés de manière statique et les PersistentVolumeClaims requises pour la migration de CSI.
- Vérifiez 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 page 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 obtenir des solutions, consultez la section "Problèmes connus" dans les notes de version du pilote CSI vSphere VMware 3.0.
Migration complète vers CSI
Avec la fonctionnalité de migration CSI de Kubernetes activée par défaut dans la version 1.15, le PersistentVolume reposant sur 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. Comme la spécification PersistentVolume est immuable, elle est identique à celle du plug-in de volume "in-tree".
Par conséquent, l'ensemble complet des fonctionnalités de CSI, telles que l'extension de volume et les instantanés de volume, ne sont pas disponibles pour ces volumes. Pour bénéficier 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é des outils automatisés pour vous aider à migrer une charge de travail avec état vers CSI sans temps d'arrêt des applications, ce qui vous permet d'utiliser l'ensemble de fonctionnalités CSI complet.
Utiliser des pilotes tiers
Si vous souhaitez provisionner des volumes de stockage autres que les datastores 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 pour qu'elles utilisent la StorageClass (exemple StatefulSet).
Partenaires de stockage
Nous nous sommes associés à de nombreux fournisseurs de stockage pour qualifier leurs systèmes de stockage d'GKE sur VMware. 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 l'objet 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'extension hors connexion est disponible dans les versions 7.0 et ultérieures de vSphere, et dans les versions 7.0 et ultérieures de vSphere.
La StorageClass standard-rwo définit allowVolumeExpansion sur "true" par défaut pour les nouveaux clusters s'exécutant sur vSphere 7.0 ou une version ultérieure. Vous pouvez utiliser l'expansion en ligne et hors connexion pour les volumes à l'aide de cette StorageClass. Dans le cas d'un cluster mis à niveau, étant donné que les StorageClass ne sont pas modifiées lors des mises à niveau du cluster, lorsqu'un cluster est mis à niveau de la version 1.7 à la version 1.8, le paramètre allowVolumeExpansion dans standard-rwo reste non défini, ce qui signifie que l'extension 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 d'un espace de 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 PersistentVolumeClaims et les StatefulSets avant de supprimer le cluster.
Dépannage
Consultez la page Dépannage du système de stockage.