Le pilote CSI Filestore est le principal moyen d'utiliser les instances Filestore avec Google Kubernetes Engine (GKE). Le pilote CSI Filestore fournit une expérience entièrement gérée, basée sur le pilote CSI Google Cloud Filestore Open Source.
La version du pilote CSI Filestore est liée aux numéros de version mineures de Kubernetes. La version du pilote CSI Filestore est généralement le dernier pilote disponible au moment de la publication de la version mineure de Kubernetes. Les pilotes sont mis à jour automatiquement lorsque le cluster est mis à niveau afin d'intégrer le dernier correctif GKE.
Avantages
L'utilisation du pilote CSI Filestore offre les avantages suivants :
Vous avez accès à un espace de stockage NFS entièrement géré via les API Kubernetes (
kubectl
).Vous pouvez utiliser le pilote CSI GKE pour Filestore pour provisionner vos ressources PersistentVolume de manière dynamique.
Vous pouvez utiliser des instantanés de volume avec le pilote CSI Filestore GKE. Les instantanés de volume CSI peuvent servir à créer des sauvegardes Filestore,
qui créent une copie différentielle du partage de fichiers, y compris toutes les données et métadonnées de ces fichiers dans un espace de stockage distinct. Vous ne pouvez restaurer cette copie que sur une nouvelle instance Filestore. Il n'est pas possible d'effectuer une restauration sur une instance Filestore existante. Vous pouvez utiliser l'API d'instantanés de volume CSI pour déclencher des sauvegardes Filestore, en ajoutant un champ
type:backup
dans la classe d'instantanés de volume.Vous pouvez utiliser l'expansion de volume avec le pilote CSI Filestore GKE. L'expansion de volume permet de redimensionner la capacité du volume.
Vous pouvez accéder aux instances Filestore existantes en utilisant des instances Filestore préprovisionnées dans les charges de travail Kubernetes. Vous pouvez également créer ou supprimer des instances Filestore de manière dynamique, et les utiliser dans des charges de travail Kubernetes à l'aide d'un objet StorageClass ou Deployment.
Compatible avec les multipartages Filestore pour GKE. Cette fonctionnalité vous permet de créer une instance Filestore et de lui attribuer simultanément plusieurs volumes persistants plus petits installés sur NFS, sur n'importe quel nombre de clusters GKE.
Conditions requises
Pour utiliser le pilote CSI Filestore, vos clusters doivent utiliser le numéro de version GKE correct applicable à votre niveau de service. Seuls les niveaux de service suivants sont pris en charge :
- HDD de base avec GKE version 1.21 ou ultérieure
- SSD de base avec GKE version 1.21 ou ultérieure
- Zonal (10 à 100 Tio) avec GKE version 1.27 ou ultérieure
- Entreprise avec GKE version 1.25 ou ultérieure
- Pour utiliser la fonctionnalité de multipartages Filestore, vos clusters doivent utiliser GKE version 1.25 ou ultérieure.
Le pilote CSI Filestore est compatible avec les clusters utilisant Linux uniquement. Les nœuds Windows Server ne sont pas compatibles.
La taille minimale d'une instance pour Filestore est d'au moins 1 Tio. La taille minimale de l'instance dépend du niveau de service Filestore que vous avez sélectionné. Pour en savoir plus, consultez la page Niveaux de service.
Filestore utilise le protocole du système de fichiers NFSv3 sur l'instance Filestore et accepte tous les clients compatibles avec NFSv3.
Avant de commencer
Avant de commencer, effectuez les tâches suivantes :
- Activez l'API Cloud Filestore et l'API Google Kubernetes Engine. Activer les API
- Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande
gcloud components update
.
- Si vous souhaitez utiliser Filestore sur un réseau VPC partagé, consultez les instructions de configuration supplémentaires dans la section Utiliser Filestore avec un VPC partagé.
Activer le pilote CSI Filestore sur un nouveau cluster
Pour activer le pilote CSI du pilote CSI Filestore lorsque vous créez un cluster standard, suivez ces étapes avec Google Cloud CLI ou la console Google Cloud.
gcloud
gcloud container clusters create CLUSTER_NAME \
--addons=GcpFilestoreCsiDriver \
--cluster-version=VERSION
Remplacez les éléments suivants :
CLUSTER_NAME
: nom du clusterVERSION
: numéro de version de GKE. Vous devez sélectionner un numéro de version compatible pour utiliser cette fonctionnalité. Consultez [#requirements] pour en savoir plus. Vous pouvez également utiliser l'option--release-channel
et spécifier une version disponible.
Console
Accédez à la page Google Kubernetes Engine dans Google Cloud Console.
Cliquez sur add_box Créer.
Sélectionnez le mode de cluster Standard, puis cliquez sur Configurer.
Configurez le cluster en fonction de vos besoins.
Dans le volet de navigation, sous Cluster, cliquez sur Fonctionnalités.
Cochez la case Activer le pilote CSI Filestore.
Cliquez sur Créer.
Si vous souhaitez utiliser Filestore sur un réseau VPC partagé, consultez la section Activer le pilote CSI Filestore sur un nouveau cluster avec un VPC partagé.
Après avoir activé le pilote CSI Filestore, vous pouvez l'utiliser dans les volumes Kubernetes à l'aide du nom du pilote et de l'approvisionneur : filestore.csi.storage.gke.io
.
Activer le pilote CSI Filestore sur un cluster existant
Pour activer le pilote CSI Filestore dans les clusters existants, utilisez Google Cloud CLI ou la console Google Cloud.
Pour activer le pilote sur un cluster existant, procédez comme suit :
gcloud
gcloud container clusters update CLUSTER_NAME \
--update-addons=GcpFilestoreCsiDriver=ENABLED
Remplacez CLUSTER_NAME
par le nom du cluster existant.
Console
Accédez à la page Google Kubernetes Engine dans Google Cloud Console.
Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez modifier.
Sous Fonctionnalités, à côté du champ Pilote CSI Filestore, cliquez sur edit Modifier le pilote CSI Filestore.
Cochez la case Activer le pilote CSI Filestore.
Cliquez sur Save Changes (Enregistrer les modifications).
Désactiver le pilote CSI Filestore
Vous pouvez désactiver le pilote CSI Filestore sur un cluster Autopilot ou Standard existant à l'aide de Google Cloud CLI ou de la console Google Cloud.
gcloud
gcloud container clusters update CLUSTER_NAME \
--update-addons=GcpFilestoreCsiDriver=DISABLED \
--region REGION
Remplacez les valeurs suivantes :
CLUSTER_NAME
: nom du cluster existant.REGION
: région choisie de votre cluster (par exemple,us-central1
).
Console
Dans Google Cloud Console, accédez au menu Google Kubernetes Engine.
Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez modifier.
Sous Fonctionnalités, à côté du champ Pilote CSI Filestore, cliquez sur edit Modifier le pilote CSI Filestore.
Cochez la case Activer le pilote CSI Filestore.
Cliquez sur Save Changes (Enregistrer les modifications).
Accéder à des instances Filestore préexistantes à l'aide du pilote CSI Filestore
Cette section décrit la procédure d'utilisation standard d'un volume Kubernetes pour accéder à des instances Filestore préexistantes à l'aide du pilote CSI Filestore dans GKE :
Créer un PersistentVolume et un PersistentVolumeClaim pour accéder à l'instance
Créez un fichier manifeste similaire à celui présenté dans l'exemple suivant, puis nommez-le
preprov-filestore.yaml
:apiVersion: v1 kind: PersistentVolume metadata: name: PV_NAME spec: storageClassName: "" capacity: storage: 1Ti accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain volumeMode: Filesystem csi: driver: filestore.csi.storage.gke.io volumeHandle: "modeInstance/FILESTORE_INSTANCE_LOCATION/FILESTORE_INSTANCE_NAME/FILESTORE_SHARE_NAME" volumeAttributes: ip: FILESTORE_INSTANCE_IP volume: FILESTORE_SHARE_NAME claimRef: name: PVC_NAME namespace: NAMESPACE --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: PVC_NAME namespace: NAMESPACE spec: accessModes: - ReadWriteMany storageClassName: "" resources: requests: storage: 1Ti
Pour créer les ressources
PersistentVolumeClaim
etPersistentVolume
en fonction du fichier manifestepreprov-filestore.yaml
, exécutez la commande suivante :kubectl apply -f preprov-filestore.yaml
Ensuite, créez un déploiement qui consomme le volume.
Créer un volume à l'aide du pilote CSI Filestore
Les sections suivantes décrivent la procédure d'utilisation standard d'un volume Kubernetes reposant sur un pilote CSI Filestore dans GKE.
- Créer un objet StorageClass
- Utiliser un objet PersistentVolumeClaim pour accéder au volume
- Créer un objet Deployment qui consomme le volume
Créer une StorageClass
Une fois le pilote CSI Filestore activé, GKE installe automatiquement les objets StorageClasses suivants pour le provisionnement d'instances Filestore :
zonal-rwx
, en utilisant le niveau Filestore zonal. Disponible uniquement pour la plage de capacité supérieure (10 à 100 Tio).enterprise-rwx
, en utilisant le niveau Filestore entreprise, où chaque volume PersistentVolume de Kubernetes est mappé à une instance Filestore.enterprise-multishare-rwx
, en utilisant le niveau Filestore entreprise, où chaque volume PersistentVolume de Kubernetes est mappé sur un partage d'une instance Filestore donnée. Pour en savoir plus, consultez la page Multipartages Filestore pour Google Kubernetes Engine.standard-rwx
, en utilisant le niveau de service Filestore HDD de base.premium-rwx
, en utilisant le niveau de service Filestore SSD de base.
Chaque classe StorageClass n'est disponible que dans les clusters GKE exécutant leurs numéros de version GKE compatibles respectifs. Pour obtenir la liste des versions prises en charge avec chaque niveau de service, consultez la section Conditions requises.
Exécutez la commande suivante pour trouver le nom de votre objet StorageClass
installé :
kubectl get sc
Vous pouvez également installer un autre objet StorageClass
qui utilise le pilote CSI Filestore en ajoutant filestore.csi.storage.gke.io
dans le champ provisioner
.
Filestore doit savoir sur quel réseau créer la nouvelle instance. Les classes StorageClasses installées automatiquement utilisent le réseau par défaut créé pour les clusters GKE. Si vous avez supprimé ce réseau ou si vous souhaitez utiliser un autre réseau, vous devez créer une StorageClass comme décrit dans les étapes suivantes. Sinon, les StorageClasses installées automatiquement ne fonctionneront pas.
Enregistrez le manifeste suivant sous le nom
filestore-example-class.yaml
:apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: filestore-example provisioner: filestore.csi.storage.gke.io volumeBindingMode: Immediate allowVolumeExpansion: true parameters: tier: standard network: default
Dans le fichier manifeste, examinez la configuration de paramètre suivante :
- Si vous définissez
volumeBindingMode
surImmediate
, le provisionnement du volume commence immédiatement. Cela est possible car les instances Filestore sont accessibles depuis n'importe quelle zone. Par conséquent, GKE n'a pas besoin de connaître la zone dans laquelle le pod est programmé, contrairement au disque persistant Compute Engine. Lorsque ce paramètre est défini surWaitForFirstConsumer
, GKE ne commence le provisionnement qu'après la planification du pod. Pour en savoir plus, consultez la section VolumeBindingMode. - Tout niveau Filestore peut être spécifié dans le paramètre
tier
(par exemple,BASIC_HDD
,BASIC_SSD
,ZONAL
ouENTERPRISE
). - Le paramètre
network
peut être utilisé lors du provisionnement d'instances Filestore sur des VPC autres que ceux définis par défaut. Les VPC autres que ceux définis par défaut nécessitent la configuration de règles de pare-feu spéciales.
- Si vous définissez
Pour créer une ressource
StorageClass
basée sur le fichier manifestefilestore-example-class.yaml
, exécutez la commande suivante :kubectl create -f filestore-example-class.yaml
Si vous souhaitez utiliser Filestore sur un réseau VPC partagé, consultez la section Créer une StorageClass lors de l'utilisation du pilote CSI Filestore avec un VPC partagé.
Utiliser un objet PersistentVolumeClaim pour accéder au volume
Vous pouvez créer une ressource PersistentVolumeClaim
qui fait référence à l'objet StorageClass
du pilote CSI Filestore.
Vous pouvez utiliser une StorageClass
préinstallée ou personnalisée.
L'exemple de fichier manifeste suivant crée un objet PersistentVolumeClaim
qui référence la StorageClass
nommée filestore-example
.
Enregistrez le fichier manifeste suivant sous le nom
pvc-example.yaml
:kind: PersistentVolumeClaim apiVersion: v1 metadata: name: podpvc spec: accessModes: - ReadWriteMany storageClassName: filestore-example resources: requests: storage: 1Ti
Pour créer une ressource
PersistentVolumeClaim
basée sur le fichier manifestepvc-example.yaml
, exécutez la commande suivante :kubectl create -f pvc-example.yaml
Créer un objet Deployment qui consomme le volume
L'exemple de fichier manifeste de déploiement suivant utilise la ressource PersistentVolume
nommée pvc-example.yaml
.
Plusieurs pods peuvent partager la même ressource PersistentVolumeClaim
.
Enregistrez le manifeste suivant sous le nom
filestore-example-deployment.yaml
:apiVersion: apps/v1 kind: Deployment metadata: name: web-server-deployment labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx volumeMounts: - mountPath: /usr/share/nginx/html name: mypvc volumes: - name: mypvc persistentVolumeClaim: claimName: podpvc --- kind: PersistentVolumeClaim apiVersion: v1 metadata: name: podpvc spec: accessModes: - ReadWriteMany storageClassName: filestore-example resources: requests: storage: 1Ti
Pour créer un objet Deployment basé sur le fichier manifeste
filestore-example-deployment.yaml
, exécutez la commande suivante :kubectl apply -f filestore-example-deployment.yaml
Vérifiez que le déploiement a bien été créé :
kubectl get deployment
Le provisionnement des instances Filestore peut prendre un certain temps. Avant cela, les déploiements ne signalent pas l'état
READY
. Vous pouvez vérifier la progression en surveillant votre état PVC en exécutant la commande suivante :kubectl get pvc
Le PVC devrait atteindre l'état
BOUND
une fois le provisionnement du volume terminé.
Ajouter un libellé aux instances Filestore
Vous pouvez utiliser des libellés pour regrouper des instances associées et stocker des métadonnées sur une instance. Un libellé est une paire clé-valeur qui vous aide à organiser vos instances Filestore. Vous pouvez associer un libellé à chaque ressource, puis filtrer les ressources par libellé.
Vous pouvez fournir des libellés à l'aide de la clé labels
dans StorageClass.parameters
.
Une instance Filestore peut être libellée avec des informations sur ce que l'instance PersistentVolumeClaim
/PersistentVolume
a créé. Les clés et valeurs des libellés personnalisés doivent respecter la convention d'attribution de noms des libellés.
Consultez l'exemple de classe de stockage Kubernetes pour appliquer des libellés personnalisés à l'instance Filestore.
Utiliser fsgroup avec des volumes Filestore
Kubernetes utilise fsGroup
pour modifier les autorisations et les droits de propriété du volume afin de faire correspondre un fsGroup
demandé par l'utilisateur dans le paramètre SecurityContext du pod.
Un fsGroup
est un groupe supplémentaire qui s'applique à tous les conteneurs d'un pod.
Vous pouvez appliquer un fsgroup aux volumes provisionnés par le pilote CSI Filestore.
Configurer des règles d'accès IP avec des volumes Filestore
Filestore est compatible avec les règles de contrôle d'accès basées sur l'adresse IP pour les volumes. Cette fonctionnalité est disponible sur les clusters GKE exécutant la version 1.29.5 ou ultérieure.
Cette fonctionnalité permet aux administrateurs de spécifier les plages d'adresses IP autorisées à accéder à une instance Filestore provisionnée dynamiquement via GKE. Cela améliore la sécurité en limitant l'accès aux seuls clients autorisés, en particulier dans les scénarios où la plage d'adresses IP du cluster GKE est trop large, ce qui peut exposer l'instance Filestore à des utilisateurs ou applications non autorisés.
Ces règles peuvent être configurées directement via l'API Filestore ou via le pilote CSI Filestore lorsqu'un volume est créé. Vous pouvez fournir la configuration sélectionnée au format JSON dans l'objet StorageClass à l'aide du paramètre nfs-export-options-on-create
.
L'exemple de fichier manifeste suivant montre comment spécifier la configuration :
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: filestore-example
provisioner: filestore.csi.storage.gke.io
volumeBindingMode: Immediate
allowVolumeExpansion: true
parameters:
tier: "enterprise"
nfs-export-options-on-create: '[
{
"accessMode": "READ_WRITE",
"ipRanges": [
"10.0.0.0/24"
],
"squashMode": "ROOT_SQUASH",
"anonUid": "1003",
"anonGid": "1003"
},
{
"accessMode": "READ_WRITE",
"ipRanges": [
"10.0.0.0/28"
],
"squashMode": "NO_ROOT_SQUASH"
}
]'
Options de sécurité
Les règles d'accès IP Filestore simplifient la configuration des autorisations de stockage de fichiers partagés pour vos charges de travail GKE. Toutefois, pour comprendre comment elle gère la propriété et l'accès aux fichiers, vous devez maîtriser quelques concepts clés:
Mappages NFS et utilisateur NFS (Network File System) est le protocole utilisé par Filestore. Il fonctionne en mappant les utilisateurs sur les systèmes clients (vos pods GKE) aux utilisateurs sur le serveur Filestore. Si un fichier sur le serveur appartient à l'ID utilisateur 1003 et qu'un client se connecte avec l'ID utilisateur 1003, il aura accès au fichier.
Root-squashing et
anonUid
:Le Root Squashing
ROOT_SQUASH
est une fonctionnalité de sécurité qui empêche les clients d'accéder à l'instance Filestore avec des privilèges racine complets. Lorsque la compression racine est activée, les utilisateurs racine des systèmes clients sont mappés à un utilisateur non privilégié spécifié par le paramètreanonUid
.Aucun Root Squashing (
NO_ROOT_SQUASH
) permet aux clients d'accéder à l'instance Filestore avec des privilèges racine complets, ce qui est pratique pour la configuration initiale, mais moins sécurisé pour les opérations courantes.
Configuration et autorisations initiales:par défaut, une nouvelle instance Filestore appartient entièrement à l'utilisateur racine. Si vous activez le root squashing sans avoir préalablement configuré d'autorisations pour les autres utilisateurs, vous perdrez l'accès. C'est pourquoi vous avez besoin d'au moins une règle d'exportation NFS avec
NO_ROOT_SQUASH
pour configurer initialement l'accès pour les autres utilisateurs et groupes.
Recommandations
- Configuration initiale: commencez toujours par au moins une règle d'exportation NFS qui spécifie une plage d'administrateurs avec des autorisations
READ_WRITE
et autorise l'accèsNO_ROOT_SQUASH
. Utilisez cet accès pour créer des répertoires, définir des autorisations et attribuer la propriété si nécessaire. - Sécurité: activez l'option root-squashing (
ROOT_SQUASH
) pour renforcer la sécurité. Notez qu'une fois le volume créé, vous ne pouvez modifier les règles d'accès que via l'API Filestore. - Accès partagé: utilisez
fsGroup
dans vos contextes de sécurité de pod pour gérer la propriété de groupe des volumes partagés. Assurez-vous de ne pas chevaucher votre paramètre avec le modeROOT_SQUASH
. Cette opération renvoie un message d'erreurAccess denied
.
Utiliser Filestore avec un VPC partagé
Cette section explique comment utiliser une instance Filestore sur un réseau VPC partagé à partir d'un projet de service.
Configurer un cluster avec un VPC partagé
Pour configurer vos clusters avec un réseau VPC partagé, procédez comme suit :
- Créer un hôte et un projet de service
- Activez l'API Google Kubernetes Engine sur vos projets hôte et de service.
- Dans votre projet hôte, créez un réseau et un sous-réseau.
- Activez le VPC partagé dans le projet hôte.
- Dans le projet hôte, accordez la liaison de rôle utilisateur
HostServiceAgent
pour le compte de service GKE du projet de service. - Activez l'accès privé aux services sur le réseau VPC partagé.
Activer le pilote CSI Filestore sur un nouveau cluster avec un VPC partagé
Pour activer le pilote CSI Filestore sur un nouveau cluster avec un VPC partagé, procédez comme suit :
Vérifiez les sous-réseaux et les plages secondaires utilisables. Lorsque vous créez un cluster, vous devez spécifier un sous-réseau ainsi que les plages d'adresses IP secondaires à utiliser pour les pods et les services du cluster.
gcloud container subnets list-usable \ --project=SERVICE_PROJECT_ID \ --network-project=HOST_PROJECT_ID
Le résultat ressemble à ce qui suit :
PROJECT REGION NETWORK SUBNET RANGE HOST_PROJECT_ID us-central1 shared-net tier-1 10.0.4.0/22 ┌──────────────────────┬───────────────┬─────────────────────────────┐ │ SECONDARY_RANGE_NAME │ IP_CIDR_RANGE │ STATUS │ ├──────────────────────┼───────────────┼─────────────────────────────┤ │ tier-1-pods │ 10.4.0.0/14 │ usable for pods or services │ │ tier-1-services │ 10.0.32.0/20 │ usable for pods or services │ └──────────────────────┴───────────────┴─────────────────────────────┘
créer un cluster GKE ; Les exemples suivants montrent comment utiliser gcloud CLI pour créer un cluster Autopilot ou Standard configuré pour un VPC partagé. Les exemples suivants utilisent les noms de réseau, de sous-réseau et de plage de la section Créer un réseau et deux sous-réseaux.
Autopilot
gcloud container clusters create-auto tier-1-cluster \ --project=SERVICE_PROJECT_ID \ --region=COMPUTE_REGION \ --network=projects/HOST_PROJECT_ID/global/networks/NETWORK_NAME \ --subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNET_NAME \ --cluster-secondary-range-name=tier-1-pods \ --services-secondary-range-name=tier-1-services
Standard
gcloud container clusters create tier-1-cluster \ --project=SERVICE_PROJECT_ID \ --zone=COMPUTE_REGION \ --enable-ip-alias \ --network=projects/HOST_PROJECT_ID/global/networks/NETWORK_NAME \ --subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNET_NAME \ --cluster-secondary-range-name=tier-1-pods \ --services-secondary-range-name=tier-1-services \ --addons=GcpFilestoreCsiDriver
Créez des règles de pare-feu pour autoriser la communication entre les nœuds, les pods et les services de votre cluster. L'exemple suivant montre comment créer une règle de pare-feu nommée
my-shared-net-rule-2
.gcloud compute firewall-rules create my-shared-net-rule-2 \ --project HOST_PROJECT_ID \ --network=NETWORK_NAME \ --allow=tcp,udp \ --direction=INGRESS \ --source-ranges=10.0.4.0/22,10.4.0.0/14,10.0.32.0/20
Dans l'exemple, les valeurs de plages d'adresses IP sources proviennent de l'étape précédente, où vous avez vérifié les sous-réseaux et les plages secondaires utilisables.
Créer une classe StorageClass lorsque vous utilisez le pilote CSI Filestore avec un VPC partagé
L'exemple suivant montre comment créer une classe StorageClass lorsque vous utilisez le pilote CSI Filestore avec un VPC partagé :
cat <<EOF | kubectl apply -f -
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: filestore-sharedvpc-example
provisioner: filestore.csi.storage.gke.io
parameters:
network: "projects/HOST_PROJECT_ID/global/networks/SHARED_VPC_NAME"
connect-mode: PRIVATE_SERVICE_ACCESS
reserved-ip-range: RESERVED_IP_RANGE_NAME
allowVolumeExpansion: true
EOF
Remplacez les éléments suivants :
HOST_PROJECT_ID
: ID ou nom du projet hôte du réseau VPC partagé.SHARED_VPC_NAME
: nom du réseau VPC partagé que vous avez créé précédemmentRESERVED_IP_RANGE_NAME
: nom de la plage d'adresses IP réservée spécifique dans laquelle provisionner l'instance Filestore. Ce champ est facultatif. Si une plage d'adresses IP réservée est spécifiée, elle doit être une plage d'adresses nommée et non une valeur CIDR directe.
Si vous souhaitez provisionner un volume sauvegardé par des multipartages Filestore sur des clusters GKE exécutant la version 1.23 ou ultérieure, consultez la page Optimiser le stockage avec les multipartages Filestore pour GKE.
Reconnecter les volumes Filestore à partage unique
Si vous utilisez Filestore avec le niveau HDD de base, SSD de base ou Entreprise (partage unique), vous pouvez suivre les instructions ci-dessous pour reconnecter votre instance Filestore existante à vos charges de travail GKE.
Recherchez les détails de votre instance Filestore préprovisionnée en suivant les instructions de la section Obtenir des informations sur une instance spécifique.
Redéployez la spécification PersistentVolume. Dans le champ
volumeAttributes
, modifiez les champs suivants pour utiliser les mêmes valeurs que votre instance Filestore de l'étape 1 :ip
: remplacez cette valeur par l'adresse IP de l'instance Filestore préprovisionnée.volume
: remplacez cette valeur par le nom de partage de l'instance Filestore préprovisionnée. DansclaimRef
, veillez à référencer le même PersistentVolumeClaim que celui de l'étape 2.
Redéployez la spécification PersistentVolumeClaim.
Vérifiez l'état de la liaison de votre PersistentVolumeClaim et de votre PersistentVolume en exécutant
kubectl get pvc
.Redéployez la spécification de votre pod et assurez-vous qu'il peut de nouveau accéder au partage Filestore.
Étapes suivantes
- Apprenez à déployer une charge de travail Filestore avec état sur GKE.
- Découvrez comment partager une instance Filestore entreprise avec plusieurs volumes persistants.
- Découvrez comment utiliser l'expansion du volume.
- Découvrez comment utiliser des instantanés de volume.
- En savoir plus sur le pilote CSI sur GitHub