Cette page explique les concepts de Google Distributed Cloud Storage.
Résumé
Google Distributed Cloud s'intègre aux systèmes de stockage de blocs ou de fichiers externes 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 datastore différent. 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 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 une PersistentVolumeClaim, vous pouvez spécifier une StorageClass qui fournit des informations sur le 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 et elle est désignée comme StorageClass par défaut. La StorageClass standard répertorie le plug-in de volume "in-tree" vSphere comme 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 afficher 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 indique le pilote CSI vSphere comme 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 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". 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.
CSI Migration 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 internes 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 "in-tree" vSphere, kubernetes.io/vsphere-volume, comme approvisionneur. Ainsi, les appels d'opérations de stockage de toutes les charges de travail qui utilisent 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 sont effectuées pour vous assurer que votre environnement est adapté à la migration CSI.
Par exemple, les vérifications préliminaires sont les suivantes:
- 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 les StorageClasses vSphere ne comportent pas certains paramètres ignorés après la migration CSI.
- Vérifiez les annotations sur les PersistentVolumes "in-tree" et les PersistentVolumeClaims créés en mode statique pour la migration 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 section Exécuter des vérifications préliminaires.
Problèmes connus
Plusieurs problèmes connus sont liés au pilote CSI vSphere. Pour en savoir plus et pour obtenir des solutions, consultez la section "Problèmes connus" dans les notes de version du pilote CSI vSphere VMware 3.0.
Effectuer la migration vers CSI
Avec la fonctionnalité de migration CSI de Kubernetes activée par défaut dans la version 1.15, le PersistentVolume sauvegardé par le plug-in de volume vSphere "in-tree" continue de fonctionner dans un environnement CSI uniquement. Il redirige simplement les appels d'opération du plug-in "in-tree" vers le plug-in CSI. Étant donné que 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 CSI, telles que l'extension de volume et les instantanés de volume, n'est pas disponible pour de tels volumes. Pour tirer parti de ces fonctionnalités, la charge de travail avec état doit être complètement 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 de l'application. Vous pourrez ainsi 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 certifier leurs systèmes de stockage avec 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 la 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 vSphere 7.0 et ultérieures, tandis que l'expansion en ligne est disponible dans les versions 7.0 Update 2 ou 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 version ultérieure. Vous pouvez utiliser l'expansion en ligne et hors connexion pour les volumes utilisant cette StorageClass. Dans le cas d'un cluster mis à niveau, étant donné que les ressources StorageClass ne sont pas modifiées lors des mises à niveau du cluster, lorsqu'un cluster passe de la version 1.7 à la version 1.8, le paramètre allowVolumeExpansion dans standard-rwo n'est pas défini, ce qui signifie que l'expansion du 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 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, ainsi que les PersistentVolumeClaims et les StatefulSets avant de supprimer le cluster.
Dépannage
Consultez la page Dépannage du système de stockage.