Accéder aux instances Filestore avec le pilote CSI Filestore

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.

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 cluster
  • VERSION : 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

  1. Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

    Accéder à Google Kubernetes Engine

  2. Cliquez sur Créer.

  3. Sélectionnez le mode de cluster Standard, puis cliquez sur Configurer.

  4. Configurez le cluster en fonction de vos besoins.

  5. Dans le volet de navigation, sous Cluster, cliquez sur Fonctionnalités.

  6. Cochez la case Activer le pilote CSI Filestore.

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

  1. Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

    Accéder à Google Kubernetes Engine

  2. Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez modifier.

  3. Sous Fonctionnalités, à côté du champ Pilote CSI Filestore, cliquez sur  Modifier le pilote CSI Filestore.

  4. Cochez la case Activer le pilote CSI Filestore.

  5. 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 la CLI Google Cloud 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

  1. Dans Google Cloud Console, accédez au menu Google Kubernetes Engine.

    Accéder à Google Kubernetes Engine

  2. Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez modifier.

  3. Sous Fonctionnalités, à côté du champ Pilote CSI Filestore, cliquez sur  Modifier le pilote CSI Filestore.

  4. Cochez la case Activer le pilote CSI Filestore.

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

  1. 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
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: ""
  volumeName: PV_NAME
  resources:
    requests:
      storage: 1Ti

  2. Pour créer les ressources PersistentVolumeClaim et PersistentVolume en fonction du fichier manifeste preprov-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 une StorageClass

Une fois le pilote CSI Filestore activé, GKE installe automatiquement les objets StorageClasses suivants pour le provisionnement d'instances Filestore :

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

  1. 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 sur Immediate, 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 sur WaitForFirstConsumer, 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 ou ENTERPRISE).
    • 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.

  2. Pour créer une ressource StorageClass basée sur le fichier manifeste filestore-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.

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

  2. Pour créer une ressource PersistentVolume basée sur le fichier manifeste pvc-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.

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

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

  3. 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 de manière dynamique via GKE. Cela améliore la sécurité en limitant l'accès aux seuls clients autorisés, en particulier dans les cas où la plage d'adresses IP du cluster GKE est trop étendue, ce qui peut exposer l'instance Filestore à des utilisateurs ou à des 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é pour vos charges de travail GKE. Cependant, pour comprendre comment il gère la propriété et l'accès aux fichiers, vous devez maîtriser quelques concepts clés:

  • NFS et mappages d'utilisateurs NFS (Network File System) est le protocole utilisé par Filestore. Son fonctionnement consiste à mapper les utilisateurs des 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:

    • 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ètre anonUid.

    • 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 initiale et autorisations: 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 devez disposer 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ès NO_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 mode ROOT_SQUASH. Cette opération renvoie un message d'erreur Access 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 :

  1. Créer un hôte et un projet de service
  2. Activez l'API Google Kubernetes Engine sur vos projets hôte et de service.
  3. Dans votre projet hôte, créez un réseau et un sous-réseau.
  4. Activez le VPC partagé dans le projet hôte.
  5. Dans le projet hôte, accordez la liaison de rôle utilisateur HostServiceAgent pour le compte de service GKE du projet de service.
  6. 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 :

  1. 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 │
└──────────────────────┴───────────────┴─────────────────────────────┘

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

  3. 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édemment
  • RESERVED_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.

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

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

  3. Redéployez la spécification PersistentVolumeClaim. Dans volumeName, veillez à référencer le même nom PersistentVolume que celui de l'étape 2.

  4. Vérifiez l'état de la liaison de votre PersistentVolumeClaim et de votre PersistentVolume en exécutant kubectl get pvc.

  5. Redéployez la spécification de votre pod et assurez-vous qu'il peut de nouveau accéder au partage Filestore.

Étapes suivantes