Accedi alle istanze Filestore con il driver CSI Filestore

Il driver CSI Filestore è il modo principale per utilizzare le istanze Filestore con Google Kubernetes Engine (GKE). Il driver CSI Filestore offre un'esperienza completamente gestita basata sul driver CSI FilestoreGoogle Cloud open source.

La versione del driver CSI Filestore è associata ai numeri di versione secondaria di Kubernetes. La versione del driver CSI Filestore è in genere l'ultimo driver disponibile al momento del rilascio della versione secondaria di Kubernetes. I driver vengono aggiornati automaticamente quando viene eseguito l'upgrade del cluster all'ultima patch di GKE.

Vantaggi

Il driver CSI Filestore offre i seguenti vantaggi:

  • Hai accesso allo spazio di archiviazione NFS completamente gestito tramite le API Kubernetes (kubectl).

  • Puoi utilizzare il driver CSI Filestore di GKE per eseguire il provisioning dinamico dei PersistentVolume.

  • Puoi utilizzare gli snapshot dei volumi con il driver CSI Filestore di GKE. Gli snapshot dei volumi CSI possono essere utilizzati per creare backup Filestore.

    Un backup di Filestore crea una copia differenziale della condivisione file, inclusi tutti i dati e i metadati dei file, e la archivia separatamente dall'istanza. Puoi ripristinare questa copia solo in una nuova istanza Filestore. Il ripristino in un'istanza Filestore esistente non è supportato. Puoi utilizzare l'API CSI volume snapshot per attivare i backup di Filestore aggiungendo un campo type:backup nella classe snapshot del volume.

  • Puoi utilizzare l'espansione del volume con il driver CSI di GKE Filestore. L'espansione del volume ti consente di ridimensionare la capacità del volume.

  • Puoi accedere alle istanze Filestore esistenti utilizzando istanze Filestore di cui è stato eseguito il pre-provisioning nei workload Kubernetes. Puoi anche creare o eliminare dinamicamente istanze Filestore e utilizzarle nei workload Kubernetes con una StorageClass o un Deployment.

  • Supporta le condivisioni multiple Filestore per GKE. Questa funzionalità ti consente di creare un'istanza Filestore e di allocare contemporaneamente più volumi permanenti montati su NFS di dimensioni inferiori per l'istanza in un numero qualsiasi di cluster GKE.

  • Supporta la scalabilità indipendente delle prestazioni. Puoi scalare dinamicamente le prestazioni di Filestore (IOPS) indipendentemente dalla capacità di archiviazione in fase di runtime senza interruzioni del servizio.

Requisiti

  • Per utilizzare il driver CSI di Filestore, i cluster devono soddisfare i seguenti requisiti:

    • La versione di GKE richiesta dipende dal livello di servizio Filestore e dalle funzionalità che intendi utilizzare. Consulta la tabella Livelli di servizio, protocolli e versioni di GKE supportati per le combinazioni supportate.
    • Il driver CSI di Filestore è supportato per i cluster che utilizzano solo nodi Linux. I nodi Windows Server non sono supportati.
    • La dimensione minima dell'istanza è 1 TiB.

    Per saperne di più, consulta Livelli di servizio.

Livelli di servizio, protocolli e versioni di GKE supportati

La tabella seguente descrive le combinazioni supportate di livelli di servizio Filestore, protocolli e le versioni GKE minime richieste per l'utilizzo con il driver CSI Filestore.

Livello di servizio Tipo di condivisione Versione minima di GKE per NFSv3 Versione minima di GKE per NFSv4.1
Enterprise Condivisione singola, condivisione multipla 1,25 1,33 (solo condivisione singola)
Zonale (1 TiB - 9,75 TiB) Condivisione singola 1,31 1,33
Zonale (10 TiB - 100 TiB) Condivisione singola 1,27 1,33
Regionale(1 TiB - 9,75 TiB) Condivisione singola 1.33.4-gke.1172000 1.33.4-gke.1172000
A livello di regione(10 TiB - 100 TiB) Condivisione singola 1.33.4-gke.1172000 1.33.4-gke.1172000
HDD base (100 GiB - 63,9 TiB) Singola quota 1,33 Non supportata
HDD base Singola quota 1,21 Non supportata
SSD base Condivisione singola 1,21 Non supportata

Per impostazione predefinita, Filestore utilizza il protocollo del file system NFSv3 nell'istanza Filestore e supporta qualsiasi client compatibile con NFSv3.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

  • Abilita l'API Cloud Filestore e l'API Google Kubernetes Engine.
    • Abilita le API
  • Per utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.

  • Assicurati di avere un cluster Autopilot o Standard esistente. Se ne hai bisogno, crea un cluster Autopilot. Il driver CSI Filestore è abilitato per impostazione predefinita per i cluster Autopilot.

  • Se vuoi utilizzare Filestore su una rete VPC condivisa, consulta le istruzioni di configurazione aggiuntive in Utilizza Filestore con VPC condiviso.

Abilita il driver CSI Filestore sul cluster Standard

Per abilitare il driver CSI Filestore sui cluster Standard, utilizza Google Cloud CLI o la console Google Cloud .

Per abilitare il driver su un cluster Standard esistente, completa i seguenti passaggi:

gcloud

gcloud container clusters update CLUSTER_NAME \
   --update-addons=GcpFilestoreCsiDriver=ENABLED

Sostituisci CLUSTER_NAME con il nome del cluster esistente.

Console

  1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud .

    Vai a Google Kubernetes Engine

  2. Nell'elenco dei cluster, fai clic sul nome del cluster da modificare.

  3. In Funzionalità, accanto al campo Driver CSI Filestore, fai clic su Modifica driver CSI Filestore.

  4. Seleziona la casella di controllo Abilita driver CSI Filestore.

  5. Fai clic su Salva modifiche.

Se vuoi utilizzare Filestore su una rete VPC condivisa, consulta Attivare il driver CSI Filestore su un nuovo cluster con VPC condiviso.

Dopo aver attivato il driver CSI di Filestore, puoi utilizzarlo nei volumi Kubernetes utilizzando il nome del driver e del provisioner: filestore.csi.storage.gke.io.

Disabilita il driver CSI Filestore

Puoi disattivare il driver CSI di Filestore su un cluster Autopilot o Standard esistente utilizzando Google Cloud CLI o la console Google Cloud .

gcloud

gcloud container clusters update CLUSTER_NAME \
    --update-addons=GcpFilestoreCsiDriver=DISABLED \
    --region REGION

Sostituisci i seguenti valori:

  • CLUSTER_NAME: il nome del cluster esistente.
  • REGION: la regione del cluster (ad esempio us-central1).

Console

  1. Nella console Google Cloud , vai al menu Google Kubernetes Engine.

    Vai a Google Kubernetes Engine

  2. Nell'elenco dei cluster, fai clic sul nome del cluster da modificare.

  3. In Funzionalità, accanto al campo Driver CSI Filestore, fai clic su Modifica driver CSI Filestore.

  4. Deseleziona la casella di controllo Abilita driver CSI Filestore.

  5. Fai clic su Salva modifiche.

Accedi alle istanze Filestore preesistenti utilizzando il driver CSI Filestore

Questa sezione descrive la procedura tipica per utilizzare un volume Kubernetes per accedere alle istanze Filestore preesistenti utilizzando il driver CSI Filestore in GKE:

Crea un PersistentVolume e un PersistentVolumeClaim per accedere all'istanza

  1. Crea un file manifest come quello mostrato nell'esempio seguente e assegnagli il nome 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
      protocol: FILESYSTEM_PROTOCOL
  claimRef:
    name: PVC_NAME
    namespace: NAMESPACE
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: PVC_NAME
  namespace: NAMESPACE
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: ""
  resources:
    requests:
      storage: 1Ti

  2. Per creare le risorse PersistentVolumeClaim e PersistentVolume in base al file manifest preprov-filestore.yaml, esegui questo comando:

    kubectl apply -f preprov-filestore.yaml

Per specificare il protocollo del file system NFSv4.1, imposta il campo protocol su NFS_V4_1 nel campo volumeAttributes di un oggetto PersistentVolume. Per utilizzare il protocollo del file system NFSv3, imposta il campo protocol su NFS_V3 o ometti il campo protocol.

A questo punto, procedi a creare un deployment che utilizzi il volume.

Crea un volume utilizzando il driver CSI di Filestore

Le sezioni seguenti descrivono il processo tipico per l'utilizzo di un volume Kubernetes supportato da un driver CSI Filestore in GKE:

Crea una classe StorageClass

Dopo aver attivato il driver CSI di Filestore, GKE installa automaticamente le seguenti StorageClasses per il provisioning delle istanze Filestore:

Ogni StorageClass è disponibile solo nei cluster GKE in esecuzione nei rispettivi numeri di versione GKE supportati. Per un elenco delle versioni supportate richieste per ogni livello di servizio, consulta Requisiti.

Puoi trovare il nome del StorageClass installato eseguendo questo comando:

kubectl get sc

Puoi anche installare un altro StorageClass che utilizza il driver CSI di Filestore aggiungendo filestore.csi.storage.gke.io nel campo provisioner.

Filestore deve sapere su quale rete creare la nuova istanza. Le StorageClass installate automaticamente utilizzano la rete predefinita creata per i cluster GKE. Se hai eliminato questa rete o vuoi utilizzarne un'altra, devi creare una nuova StorageClass come descritto nei passaggi seguenti. In caso contrario, le classi di archiviazione installate automaticamente non funzioneranno.

  1. Salva il seguente manifest come 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

    Dal manifest, considera la seguente configurazione dei parametri:

    • Se imposti volumeBindingMode su Immediate, il provisioning del volume può iniziare immediatamente. Questo è possibile perché le istanze Filestore sono accessibili da qualsiasi zona. Pertanto, GKE non ha bisogno di conoscere la zona in cui è pianificato il pod, a differenza del disco permanente di Compute Engine. Se impostato su WaitForFirstConsumer, GKE inizia il provisioning solo dopo la pianificazione del pod. Per ulteriori informazioni, vedi VolumeBindingMode.
    • Qualsiasi livello Filestore supportato può essere specificato nel parametro tier (ad esempio BASIC_HDD, BASIC_SSD, ZONAL o ENTERPRISE).
    • Il parametro network può essere utilizzato durante il provisioning delle istanze Filestore su VPC non predefiniti. I VPC non predefiniti richiedono la configurazione di regole firewall speciali.
    • Il parametro protocol può essere utilizzato per impostare il protocollo del file system dell'istanza Filestore. Può assumere i seguenti valori: NFS_V3 (predefinito) e NFS_V4_1. Il protocollo predefinito è NFS_V3.

  2. Per creare una risorsa StorageClass basata sul file manifest filestore-example-class.yaml, esegui questo comando:

    kubectl create -f filestore-example-class.yaml

Se vuoi utilizzare Filestore su una rete VPC condivisa, consulta Creare una StorageClass quando utilizzi il driver CSI Filestore con il VPC condiviso.

Usa un oggetto PersistentVolumeClaim per accedere al volume

Puoi creare una risorsa PersistentVolumeClaim che fa riferimento al StorageClass del driver CSI Filestore.

Puoi utilizzare un StorageClass preinstallato o personalizzato.

Il seguente file manifest di esempio crea un PersistentVolumeClaim che fa riferimento alla StorageClass denominata filestore-example.

  1. Salva il seguente file manifest come pvc-example.yaml:

    kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc
spec:
  accessModes:
  - ReadWriteMany
  storageClassName: filestore-example
  resources:
    requests:
      storage: 1Ti

  2. Per creare una risorsa PersistentVolumeClaim basata sul file manifest pvc-example.yaml, esegui questo comando:

    kubectl create -f pvc-example.yaml

Crea un deployment che utilizza il volume

Il seguente manifest di Deployment utilizza la risorsa PersistentVolume denominata pvc-example.yaml.

Più pod possono condividere la stessa risorsa PersistentVolumeClaim.

  1. Salva il seguente manifest come 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. Per creare un deployment basato sul file manifest filestore-example-deployment.yaml, esegui questo comando:

    kubectl apply -f filestore-example-deployment.yaml

  3. Verifica che il deployment sia stato creato correttamente:

    kubectl get deployment

    Il completamento del provisioning delle istanze Filestore potrebbe richiedere un po' di tempo. Prima di allora, le implementazioni non segnaleranno lo stato READY. Puoi controllare l'avanzamento monitorando lo stato della PVC con il seguente comando:

    kubectl get pvc

    Quando il provisioning del volume viene completato, dovresti vedere il PVC raggiungere lo stato BOUND.

Scalare dinamicamente le prestazioni di Filestore utilizzando VolumeAttributesClass

Il driver CSI di Filestore supporta le prestazioni personalizzate per i livelli di servizio a livello di zona e di regione. La configurazione delle prestazioni personalizzate ti consente di regolare le prestazioni dell'applicazione in base alle esigenze del tuo workload, aumentandole e diminuendole in base alle necessità. Assicurati che la versione del cluster GKE sia 1.35 o successiva.

Per consentire uno scaling delle prestazioni fluido, puoi definire più livelli di prestazioni utilizzando l'API VolumeAttributesClass. La presenza di livelli predefiniti consente di aggiornare dinamicamente le impostazioni delle prestazioni sui volumi esistenti passando da un livello all'altro in fase di runtime senza eseguire nuovamente il provisioning del volume o riscontrare tempi di inattività.

Livelli di prestazioni predefiniti

La tabella seguente elenca i livelli di prestazioni predefiniti. Per definire un livello di prestazioni personalizzato, consulta Definisci i livelli di prestazioni.

Nome del livello prestazioni Parametro IOPS massime
filestore-high-performance-fixed max-iops "17000"
filestore-min-performance-scaling max-iops-per-tb "4000"
filestore-moderate-performance-scaling max-iops-per-tb "10000"

Definisci i livelli di prestazioni

Definisci più livelli di rendimento creando risorse VolumeAttributesClass. Nell'esempio seguente, crei un livello di prestazioni moderate e un livello di prestazioni elevate utilizzando una frequenza di IOPS fissa (max-iops). Puoi anche utilizzare un rapporto IOPS per TiB (max-iops-per-tb) che scala in modo lineare con le dimensioni del volume.

Specifica i valori max-iops o max-iops-per-tb che generano almeno 2000 IOPS sottoposte a provisioning. Se le IOPS calcolate sono inferiori a 2000, il sistema arrotonda automaticamente il valore per eccesso fino a questo minimo.

  1. Salva il seguente manifest come performance-tiers.yaml:

    apiVersion: storage.k8s.io/v1
kind: VolumeAttributesClass
metadata:
  name: filestore-moderate
driverName: filestore.csi.storage.gke.io
parameters:
  max-iops: "4000"
---
apiVersion: storage.k8s.io/v1
kind: VolumeAttributesClass
metadata:
  name: filestore-high
driverName: filestore.csi.storage.gke.io
parameters:
  max-iops: "10000"
---
apiVersion: storage.k8s.io/v1
kind: VolumeAttributesClass
metadata:
  name: filestore-density-based
driverName: filestore.csi.storage.gke.io
parameters:
  max-iops-per-tb: "5000"

  2. Crea le risorse VolumeAttributesClass:

    kubectl apply -f performance-tiers.yaml

Crea un PersistentVolumeClaim con un livello di prestazioni iniziale

Per creare un PersistentVolumeClaim con una configurazione delle prestazioni, fai riferimento a VolumeAttributesClass nella risorsa PersistentVolumeClaim.

  1. Salva il seguente manifest come pvc-custom-performance.yaml, facendo riferimento al livello filestore-moderate:

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: filestore-pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: regional-rwx
  volumeAttributesClassName: filestore-moderate
  resources:
    requests:
      storage: 1Ti

  2. Crea PersistentVolumeClaim:

    kubectl apply -f pvc-custom-performance.yaml

Aggiorna PersistentVolumeClaim per utilizzare un livello di prestazioni diverso

  1. Quando il tuo workload richiede prestazioni più elevate, aggiorna volumeAttributesClassName nel file pvc-custom-performance.yaml in filestore-high:

     apiVersion: v1
 kind: PersistentVolumeClaim
 metadata:
   name: filestore-pvc
 spec:
   accessModes:
     - ReadWriteMany
   storageClassName: regional-rwx
   volumeAttributesClassName: filestore-high
   resources:
     requests:
       storage: 1Ti
 ```

  2. Applica la modifica:

    kubectl apply -f pvc-custom-performance.yaml

    Il driver CSI Filestore elabora l'aggiornamento in modo dinamico.

  3. Verifica lo stato del rendimento:

    kubectl describe pvc filestore-pvc

    Controlla la sezione Eventi nell'output comando per verificare se gli attributi sono stati modificati correttamente.

Etichetta le istanze Filestore

Puoi utilizzare le etichette per raggruppare le istanze correlate e archiviare i metadati di un'istanza. Un'etichetta è una coppia chiave-valore che ti aiuta a organizzare le istanze Filestore. Puoi allegare un'etichetta a ogni risorsa, quindi filtrare le risorse in base alle relative etichette.

Puoi fornire le etichette utilizzando il tasto labels in StorageClass.parameters. Un'istanza Filestore può essere etichettata con informazioni su PersistentVolumeClaim/PersistentVolume per cui è stata creata. Le chiavi e i valori delle etichette personalizzate devono essere conformi alla convenzione di denominazione delle etichette. Consulta l'esempio di classe di archiviazione di Kubernetes per applicare etichette personalizzate all'istanza Filestore.

Utilizzare il protocollo del file system NFSv4.1 con Filestore

Il driver CSI Filestore supporta il protocollo del file system NFSv4.1 con GKE versione 1.33 o successive. In caso di provisioning statico, imposta il campo protocol su NFS_V4_1 nel campo volumeAttributes di un oggetto PersistentVolume.

Per il provisioning dinamico, imposta il campo protocol su NFS_V4_1 nei parametri di un oggetto StorageClass.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: enterprise-multishare-rwx
provisioner: filestore.csi.storage.gke.io
parameters:
  tier: enterprise
  multishare: "true"
  instance-storageclass-label: "enterprise-multishare-rwx"
  protocol: NFS_V4_1
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Non puoi montare l'istanza Filestore con il protocollo NFSv4.1 con mountOptions impostato su nfsvers=3 nell'oggetto StorageClass.

Utilizzare fsgroup con i volumi Filestore

Kubernetes utilizza fsGroup per modificare le autorizzazioni e la proprietà del volume in modo che corrispondano a un fsGroup richiesto dall'utente nel SecurityContext del pod. Un fsGroup è un gruppo supplementare che si applica a tutti i container di un pod. Puoi applicare un fsgroup ai volumi di cui è stato eseguito il provisioning dal driver CSI Filestore.

Configura le regole di accesso IP con i volumi Filestore

Filestore supporta regole di controllo dell'accesso basate su IP per i volumi. Questa funzionalità è disponibile sui cluster GKE che eseguono la versione 1.29.5 o successive.

Questa funzionalità consente agli amministratori di specificare quali intervalli di indirizzi IP sono autorizzati ad accedere a un'istanza Filestore di cui è stato eseguito il provisioning dinamico tramite GKE. In questo modo, la sicurezza viene migliorata limitando l'accesso solo ai client autorizzati, soprattutto in scenari in cui l'intervallo IP del cluster GKE è troppo ampio, esponendo potenzialmente l'istanza Filestore a utenti o applicazioni non autorizzati.

Queste regole possono essere configurate direttamente tramite l'API Filestore o tramite il driver CSI di Filestore quando viene creato un volume. Puoi fornire la configurazione selezionata in formato JSON in StorageClass utilizzando il parametro nfs-export-options-on-create.

Il seguente manifest di esempio mostra come specificare la configurazione:

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"
    }
  ]'

Opzioni di sicurezza

Le regole di accesso IP di Filestore semplificano la configurazione delle autorizzazioni di archiviazione dei file condivisi per i workload GKE. Tuttavia, per capire come gestisce la proprietà e l'accesso ai file, è necessario comprendere alcuni concetti chiave:

  • NFS e mappature utente NFS (Network File System) è il protocollo utilizzato da Filestore. Funziona mappando gli utenti sui sistemi client (i tuoi pod GKE) agli utenti sul server Filestore. Se un file sul server è di proprietà dell'ID utente 1003 e un client si connette con l'ID utente 1003, avrà accesso al file.

  • Root squashing e anonUid:

    • Root Squashing ROOT_SQUASH è una funzionalità di sicurezza che impedisce ai client di accedere all'istanza Filestore con privilegi root completi. Quando la funzionalità root squash è attiva, gli utenti root sui sistemi client vengono mappati a un utente non privilegiato specificato dall'impostazione anonUid.

    • Nessun root squash (NO_ROOT_SQUASH) consente ai client di accedere all'istanza Filestore con privilegi root completi, il che è comodo per la configurazione iniziale, ma meno sicuro per le operazioni regolari.

  • Configurazione iniziale e autorizzazioni: per impostazione predefinita, una nuova istanza Filestore è di proprietà esclusiva dell'utente root. Se attivi lo schiacciamento root senza prima configurare le autorizzazioni per altri utenti, perderai l'accesso. Per questo motivo, devi avere almeno una regola di esportazione NFS con NO_ROOT_SQUASH per configurare inizialmente l'accesso per altri utenti e gruppi.

Consigli

  • Configurazione iniziale:inizia sempre con almeno una regola di esportazione NFS che specifichi un intervallo di amministratori con autorizzazioni READ_WRITE e consenta l'accesso NO_ROOT_SQUASH. Utilizza questo accesso per creare directory, impostare le autorizzazioni e assegnare la proprietà in base alle esigenze.
  • Sicurezza:attiva la compressione della radice (ROOT_SQUASH) per migliorare la sicurezza. Tieni presente che dopo la creazione di un volume, puoi modificare le regole di accesso solo tramite l'API Filestore.
  • Accesso condiviso: utilizza fsGroup nei contesti di sicurezza dei pod per gestire la proprietà di gruppo dei volumi condivisi. Assicurati di non sovrapporre l'impostazione con la modalità ROOT_SQUASH. In questo modo viene restituito un messaggio di errore Access denied.

Utilizza Filestore con un VPC condiviso

Questa sezione illustra come utilizzare un'istanza Filestore su una reteVPC condivisoa da un progetto di servizio.

Configura un cluster con VPC condiviso

Per configurare i cluster con una rete VPC condiviso:

  1. Crea un progetto host e un progetto di servizio.
  2. Abilita l'API Kubernetes Engine sia nel progetto host sia in quello di servizio.
  3. Nel progetto host, crea una rete e una subnet.
  4. Abilita il VPC condiviso nel progetto host.
  5. Nel progetto host, concedi l'associazione del ruolo utente HostServiceAgent per il service account GKE del progetto di servizio.
  6. Abilita l'accesso privato ai servizi sulla VPC condiviso condivisa.

Abilita il driver CSI di Filestore su un nuovo cluster con VPC condiviso

Per abilitare il driver CSI di Filestore su un nuovo cluster con VPC condiviso, segui questi passaggi:

  1. Verifica le subnet e gli intervalli secondari utilizzabili. Quando crei un cluster, devi specificare una subnet e gli intervalli di indirizzi IP secondari da utilizzare per i pod e il servizio del cluster.

    gcloud container subnets list-usable \
   --project=SERVICE_PROJECT_ID \
   --network-project=HOST_PROJECT_ID

    L'output è simile al seguente:

    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. Creare un cluster GKE. Gli esempi seguenti mostrano come utilizzare gcloud CLI per creare un cluster Autopilot o Standard configurato per il VPC condiviso. Gli esempi seguenti utilizzano i nomi di rete, subnet e intervallo di Crea una rete e due subnet.

    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. Crea regole firewall per consentire la comunicazione tra nodi, pod e servizi nel cluster. L'esempio seguente mostra come creare una regola firewall denominata 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

    Nell'esempio, i valori IP degli intervalli di origine provengono dal passaggio precedente, in cui hai verificato le subnet e gli intervalli secondari utilizzabili.

Crea una classe StorageClass quando utilizzi il driver CSI di Filestore con un VPC condiviso

L'esempio seguente mostra come creare una StorageClass quando utilizzi il driver CSI Filestore con un VPC condiviso:

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

Sostituisci quanto segue:

  • HOST_PROJECT_ID: l'ID o il nome del progetto host della rete VPC condiviso.
  • SHARED_VPC_NAME: il nome della rete VPC condiviso che hai creato in precedenza.
  • RESERVED_IP_RANGE_NAME: il nome dell'intervallo di indirizzi IP riservato specifico in cui eseguire il provisioning dell'istanza Filestore. Questo campo è facoltativo. Se viene specificato un intervallo di indirizzi IP prenotato, deve essere un intervallo di indirizzi denominato anziché un valore CIDR diretto.

Se vuoi eseguire il provisioning di un volume supportato da Filestore multishares sui cluster GKE che eseguono la versione 1.23 o successive, consulta Ottimizzare lo spazio di archiviazione con Filestore multishares per GKE.

Riconnetti i volumi a condivisione singola di Filestore

Se utilizzi Filestore con i livelli HDD di base, SSD di base o Enterprise (condivisione singola), puoi seguire queste istruzioni per riconnettere la tua istanza Filestore esistente ai tuoi carichi di lavoro GKE.

  1. Trova i dettagli dell'istanza Filestore di cui hai eseguito il provisioning seguendo le istruzioni riportate in Recupero di informazioni su un'istanza specifica.

  2. Rifai il deployment della specifica PersistentVolume. Nel campo volumeAttributes, modifica i seguenti campi in modo che utilizzino gli stessi valori dell'istanza Filestore del passaggio 1:

    • ip: modifica questo valore con l'indirizzo IP dell'istanza Filestore di cui è stato eseguito il pre-provisioning.
    • volume: modifica questo valore con il nome della condivisione dell'istanza Filestore di cui è stato eseguito il provisioning preliminare. Nel claimRef assicurati di fare riferimento allo stesso PersistentVolumeClaim del passaggio 2.

  3. Rifai il deployment della specifica PersistentVolumeClaim.

  4. Controlla lo stato del binding di PersistentVolumeClaim e PersistentVolume eseguendo kubectl get pvc.

  5. Rifai il deployment della specifica del pod e assicurati che il pod possa accedere di nuovo alla condivisione Filestore.

Passaggi successivi