Version 1.2. Cette version n'est pas entièrement compatible. Pour obtenir les derniers correctifs et mises à jour afin de corriger les failles et les risques de sécurité, ainsi que les problèmes affectant GKE On-Prem, effectuez une mise à niveau vers une version entièrement compatible. Vous trouverez la version la plus récente ici.

Storage

Cet article 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 une ressource StorageClass Kubernetes 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 d'utilisateur, GKE On-Prem utilise le plug-in de volume vSphere Kubernetes pour provisionner de manière dynamique de nouveaux disques virtuels (VMDK) dans un datastore vSphere (notez que les clusters d'utilisateur antérieurs à la version 1.2 utilisaient le même datastore que les clusters d'administrateur).

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.

Stockage par défaut

Les clusters GKE On-Prem incluent une ressource StorageClass Kubernetes 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 ressource StorageClass par défaut d'un cluster d'utilisateur pointe vers un datastore vSphere, qui est défini dans le champ datastore de la configuration de 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és par StorageClasses qui pointent par défaut vers le stockage vSphere.

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-tree"DescriptionModes 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 Open Source défini par logicielPod unique en lecture/écritureOui
CephFSSystème de stockage Open Source défini par logicielPods 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

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

Configurer le stockage en clusters

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 à l'aide de la StorageClass (exemple StatefulSet).

Dépannage

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

Documentation complémentaire