Storage

Cette page explique les concepts de stockage de GKE On-Prem.

Résumé

GKE On-Prem s'intègre aux systèmes externes de stockage de blocs ou de fichiers via le stockage VMware vSphere, les plug-ins de volume "in-tree" Kubernetes (ou "pilotes") et les pilotes Container Storage Interface (CSI).

Les clusters GKE On-Prem utilisent la ressource Kubernetes StorageClass par défaut pour provisionner le stockage des charges de travail avec état sur un datastore vSphere. Vous pouvez également utiliser une ressource StorageClass pour provisionner différents volumes de stockage.

Stockage vSphere

Par défaut, les clusters GKE On-Prem utilisent le stockage vSphere. Le cluster d'administrateur nécessite un datastore vSphere pré-provisionné pour ses données etcd.

Lorsque vous créez un cluster utilisateur, GKE On-Prem utilise le plug-in de volume vSphere Kubernetes pour provisionner dynamiquement de nouveaux disques de machine virtuelle (VMDK) dans un datastore vSphere. (Notez que les clusters d'utilisateurs antérieurs à la version 1.2 utilisaient le même Datastore que les clusters d'administration.)

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

Stockage par défaut

Les clusters GKE On-Prem incluent une ressource Kubernetes StorageClass par défaut, qui détermine la manière dont Kubernetes doit provisionner le stockage. Une fois que Kubernetes a provisionné les volumes de stockage, ils sont représentés par des PersistentVolumes de Kubernetes.

La classe StorageClass par défaut d'un cluster d'utilisateurs pointe vers un datastore vSphere, qui est défini dans le champ datastore de la configuration StorageClass. Par défaut, les PersistentVolumes de Kubernetes provisionnés pour le cluster d'utilisateur sont des VMDK de ce datastore. Ce datastore n'est pas nécessairement le même que celui utilisé par le cluster d'administrateur.

Dans GKE On-Prem, les StatefulSets Kubernetes (charges de travail avec état nécessitant généralement un stockage persistant) utilisent des PersistentVolumeClaims sauvegardées par StorageClasses qui pointent par défaut vers le stockage vSphere.

Interface de stockage en conteneurs

L'interface CSI (Container Storage Interface, interface de stockage en conteneurs) est une API standard Open Source qui permet à Kubernetes d'exposer des systèmes de stockage arbitraires à des charges de travail conteneurisées. Lorsque vous déployez un pilote de volume compatible avec CSI sur un cluster GKE On-Prem, les charges de travail peuvent se connecter directement à un périphérique de stockage compatible sans passer par le stockage vSphere.

GKE On-Prem est compatible avec la version 1.0 de CSI. Pour utiliser CSI dans votre cluster, vous devez déployer le pilote CSI fourni par votre fournisseur de stockage. Vous pouvez ensuite configurer des charges de travail pour qu'elles utilisent la ressource StorageClass du pilote ou définir celle-ci comme StorageClass par défaut.

Nous nous sommes associés à de nombreux fournisseurs de stockage pour obtenir la certification de leurs systèmes de stockage avec GKE On-Prem. Consultez la liste complète des partenaires de stockage qualifiés.

Pilote CSI vSphere

Par défaut, GKE On-Prem exploite le plug-in de volume "in-tree" à partir de VMware, le fournisseur cloud vSphere (VCP) , qui active automatiquement la compatibilité des datastores VMware, y compris vSAN. Le pilote CSI vSphere est automatiquement déployé dans les clusters GKE On-Prem et est disponible en tant que fonctionnalité d'aperçu à partir de la version 1.5 de GKE On-Prem.

Nettoyage des volumes

Lorsque vous supprimez un cluster d'utilisateur, les volumes provisionnés par le plug-in de volume "in-tree" de VMware peuvent ne pas être supprimés. Toutefois, lors de la suppression d'un cluster d'utilisateur, les volumes provisionnés par le pilote CSI vSphere ne sont pas supprimés. Vous devez vérifier que tous les volumes, les PVC et les objets StatefulSet sont supprimés avant la suppression du cluster.

Plug-ins de volume "in-tree" Kubernetes

Kubernetes est fourni avec un certain nombre de plug-ins de volume "in-tree". Vous pouvez utiliser n'importe lequel d'entre eux pour fournir un stockage de blocs ou de fichiers pour vos charges de travail avec état. Les plug-ins "in-tree" permettent aux charges de travail de se connecter directement au stockage sans avoir à passer par le stockage vSphere.

Alors que le stockage vSphere offre automatiquement un provisionnement dynamique des volumes dans un Datastore sauvegardé par n'importe quel appareil de stockage iSCSI, FC ou NFS, la plupart des plug-ins de volume "in-tree" ne sont pas compatibles avec le provisionnement dynamique. Vous devez créer manuellement des PersistentVolumes.

Le tableau suivant décrit plusieurs plug-ins de volume "in-tree" :

Plug-in de volume in-treeDescriptionModes d'accès compatiblesProvisionnement dynamique
Fibre ChannelPlug-in de stockage génériquePod unique en lecture/écritureNon
iSCSIPlug-in de stockage génériquePod unique en lecture/écritureNon
NFSPlug-in de stockage génériquePods multiples en lecture/écritureNon
Ceph RBDSystème de stockage défini par logiciel Open SourcePod unique en lecture/écritureOui
CephFSSystème de stockage défini par logiciel Open SourcePods multiples en lecture/écritureNon
PortworxSystème de stockage propriétaire défini par logicielPods multiples en lecture/écritureOui
QuobyteSystème de stockage propriétaire défini par logicielPod unique en lecture/écritureOui
StorageOSSystème de stockage propriétaire défini par logicielPod unique en lecture/écritureOui

Configurer le stockage en clusters

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

Dépannage

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

Documentation complémentaire