Accedere alle istanze Managed Lustre esistenti su GKE utilizzando il driver CSI Managed Lustre

Questa guida descrive come connetterti a un'istanza Managed Lustre esistente utilizzando il driver CSI Managed Lustre. In questo modo, puoi accedere alle istanze Managed Lustre esistenti come volumi per i tuoi carichi di lavoro stateful in modo controllato e prevedibile.

Supporto di più NIC per il networking ad alte prestazioni

Per i cluster GKE che eseguono la versione 1.35.2-gke.1842000 o successive, il driver CSI Managed Lustre è abilitato per impostazione predefinita per utilizzare tutte le schede di interfaccia di rete (NIC) disponibili per un maggiore throughput. Questo supporto aggrega la larghezza di banda distribuendo il traffico di archiviazione TCP sulle interfacce di rete.

Per utilizzare il supporto multi-NIC, i nodi devono soddisfare i seguenti requisiti:

  • NIC standard per TCP:i nodi devono utilizzare NIC standard, come Google Virtual NIC (gVNIC) o VirtIO-Net, per gestire il traffico di archiviazione TCP.
  • Stessa rete VPC:tutte le NIC standard devono trovarsi nella stessa rete VPC.
  • Considerazioni su RDMA:i tuoi nodi possono avere anche NIC RDMA collegate, ma il driver CSI Managed Lustre utilizza solo le NIC standard per il traffico di archiviazione TCP.

Se vuoi disattivare il supporto multi-NIC, consulta Disattivare multi-NIC per Lustre.

Porte di comunicazione Lustre

Il driver GKE Managed Lustre CSI utilizza porte diverse per la comunicazione con le istanze Managed Lustre, a seconda della versione del cluster GKE e delle configurazioni Managed Lustre esistenti.

  • Porta predefinita (consigliata): per i nuovi cluster GKE che eseguono la versione 1.33.2-gke.4780000 o successive, il driver utilizza la porta 988 per la comunicazione Lustre per impostazione predefinita.

  • Porta legacy (ritirata): utilizza la porta 6988 aggiungendo il flag --enable-legacy-lustre-port ai comandi gcloud nei seguenti scenari:

    • Versioni precedenti di GKE:se il tuo cluster GKE esegue una versione precedente alla 1.33.2-gke.4780000, il flag --enable-legacy-lustre-port risolve un conflitto di porte con gke-metadata-server sui nodi GKE.
    • Istanze Lustre esistenti:se ti connetti a un'istanza Managed Lustre esistente creata con il flag gke-support-enabled, devi comunque includere --enable-legacy-lustre-port nei comandi gcloud, indipendentemente dalla versione del cluster. Senza questo flag, il cluster GKE non riuscirà a montare l'istanza Lustre esistente.

Puoi configurare i cluster nuovi ed esistenti in modo che utilizzino la porta predefinita 988 o la porta legacy 6988.

Prima di iniziare

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

  • Abilita l'API Google Cloud Managed Lustre e l'API Kubernetes Engine.
  • Abilita le API
  • Se vuoi 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.

Imposta le variabili di ambiente

Imposta le seguenti variabili di ambiente:

export CLUSTER_NAME=CLUSTER_NAME
export PROJECT_ID=PROJECT_ID
export NETWORK_NAME=LUSTRE_NETWORK
export LOCATION=ZONE

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del cluster.
  • PROJECT_ID: il tuo Google Cloud ID progetto.
  • LUSTRE_NETWORK: la rete Virtual Private Cloud condivisa in cui si trovano sia il cluster GKE sia l'istanza Managed Lustre.
  • ZONE: la zona geografica del tuo cluster GKE, ad esempio us-central1-a.

Configura il driver CSI Managed Lustre

Questa sezione spiega come attivare e disattivare il driver CSI Managed Lustre.

Abilita il driver CSI Managed Lustre su un nuovo cluster GKE

Le sezioni seguenti descrivono come abilitare il driver CSI Managed Lustre su un nuovo cluster GKE.

Utilizza la porta predefinita 988

Per abilitare il driver CSI Managed Lustre quando crei un nuovo cluster GKE che esegue la versione 1.33.2-gke.4780000 o successive, esegui questo comando:

Autopilot

gcloud container clusters create-auto "${CLUSTER_NAME}" \
    --location=${LOCATION} \
    --network="${NETWORK_NAME}" \
    --cluster-version=${CLUSTER_VERSION} \
    --enable-lustre-csi-driver

Standard

gcloud container clusters create "${CLUSTER_NAME}" \
    --location=${LOCATION} \
    --network="${NETWORK_NAME}" \
    --cluster-version=${CLUSTER_VERSION} \
    --addons=LustreCsiDriver

Utilizza la porta legacy 6988

Per abilitare il driver CSI Managed Lustre quando crei un nuovo cluster GKE che esegue una versione precedente a 1.33.2-gke.4780000, esegui il seguente comando:

Autopilot

gcloud container clusters create-auto "${CLUSTER_NAME}" \
    --location=${LOCATION} \
    --network="${NETWORK_NAME}" \
    --cluster-version=${CLUSTER_VERSION} \
    --enable-lustre-csi-driver \
    --enable-legacy-lustre-port

Standard

gcloud container clusters create "${CLUSTER_NAME}" \
    --location=${LOCATION} \
    --network="${NETWORK_NAME}" \
    --cluster-version=${CLUSTER_VERSION} \
    --addons=LustreCsiDriver \
    --enable-legacy-lustre-port

Abilita il driver CSI Managed Lustre sui cluster GKE esistenti

Le sezioni seguenti descrivono come abilitare il driver CSI Managed Lustre sui cluster GKE esistenti.

Utilizza la porta predefinita 988

Per abilitare il driver CSI di Managed Lustre su un cluster GKE esistente che esegue la versione 1.33.2-gke.4780000 o successive, esegui questo comando:

  gcloud container clusters update ${CLUSTER_NAME} \
      --location=${LOCATION} \
      --update-addons=LustreCsiDriver=ENABLED

Utilizza la porta legacy 6988

Per abilitare il driver CSI di Managed Lustre su un cluster GKE esistente, potresti dover utilizzare la porta legacy 6988 aggiungendo il flag --enable-legacy-lustre-port. Questo flag è obbligatorio nei seguenti scenari:

  • Se il cluster GKE viene eseguito su una versione precedente a 1.33.2-gke.4780000.
  • Se intendi connettere questo cluster a un'istanza Managed Lustre esistente creata con il flag gke-support-enabled.

    gcloud container clusters update ${CLUSTER_NAME} \
        --location=${LOCATION} \
        --enable-legacy-lustre-port
    

Upgrade dei nodi richiesto sui cluster esistenti

L'abilitazione del driver CSI Managed Lustre sui cluster esistenti può attivare la ricreazione dei nodi per aggiornare i moduli del kernel necessari per il client Managed Lustre. Per una disponibilità immediata, ti consigliamo di eseguire manualmente l'upgrade dei pool di nodi.

I cluster GKE su un canale di rilascio vengono aggiornati in base all'implementazione pianificata, che può richiedere diverse settimane a seconda del periodo di manutenzione. Se utilizzi una versione statica di GKE, devi eseguire l'upgrade manualmente dei node pool.

Fino al completamento dell'upgrade del nodo, il pod del driver CSI potrebbe andare in crashloop sui nodi in attesa di aggiornamento. Se nei log del pod del driver CSI viene visualizzato un errore Operation not permitted, significa che è necessario eseguire l'upgrade o la ricreazione del nodo.

Dopo l'upgrade del pool di nodi, i nodi CPU potrebbero sembrare utilizzare un'immagine GPU nell'output della console Google Cloud o della CLI. Si tratta di un comportamento normale. L'immagine della GPU viene riutilizzata sui nodi della CPU per installare in modo sicuro i moduli del kernel Managed Lustre. Non ti verrà addebitato alcun costo per l'utilizzo della GPU.

(Facoltativo) Crea un pool di nodi con più NIC

Per utilizzare il networking ad alte prestazioni, devi creare un pool di nodi con un tipo di istanza che supporti più interfacce di rete. Il supporto multi-NIC è abilitato per impostazione predefinita nei cluster GKE che eseguono la versione 1.35.2-gke.1842000 o successive. Assicurati che le interfacce di rete secondarie si trovino nella stessa rete VPC dell'interfaccia principale.

Esegui questo comando:

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --machine-type=MACHINE_TYPE \
    --enable-gvnic \
    --additional-node-network network=NETWORK_NAME,subnetwork=SECONDARY_SUBNET

Sostituisci quanto segue:

  • NODE_POOL_NAME: il nome del tuo pool di nodi.
  • CLUSTER_NAME: il nome del tuo cluster.
  • LOCATION: la regione o la zona del cluster.
  • MACHINE_TYPE: il tipo di macchina per il pool di nodi, ad esempio a3-megagpu-8g, spesso utilizzato con più NIC per prestazioni elevate. Multi-NIC è supportato su qualsiasi tipo di macchina.
  • NETWORK_NAME: il nome della rete VPC.
  • SECONDARY_SUBNET: il nome della subnet secondaria.

Disabilita più NIC su Lustre

Sebbene il supporto di più NIC sia consigliato per i carichi di lavoro ad alte prestazioni, potresti volerlo disattivare in scenari specifici. Ad esempio, potresti non voler distribuire il traffico Lustre su tutte le interfacce hardware disponibili oppure potresti dover isolare i problemi di connettività in un singolo percorso di rete per la risoluzione dei problemi.

Nota: se disabiliti il supporto di più NIC sui nodi in esecuzione, potresti dover ricreare o eseguire l'upgrade manuale dei tuoi pool di nodi affinché questa modifica abbia effetto.

Per un cluster

Per disattivare la rete ad alte prestazioni per l'intero cluster, utilizza il flag --disable-multi-nic-lustre durante la creazione o l'aggiornamento del cluster. Ad esempio:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --disable-multi-nic-lustre

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del tuo cluster.
  • LOCATION: la regione o la zona del cluster.

Per un pool di nodi

Per disabilitare la rete ad alte prestazioni per un pool di nodi specifico, aggiorna il pool di nodi in modo da impostare l'etichetta lustre.csi.storage.gke.io/multi-nic su false:

gcloud container node-pools update NODE_POOL_NAME \
--cluster=CLUSTER_NAME \
--zone=LOCATION \
--node-labels=lustre.csi.storage.gke.io/multi-nic=false

Sostituisci quanto segue:

  • NODE_POOL_NAME: il nome del tuo pool di nodi.
  • CLUSTER_NAME: il nome del tuo cluster.
  • LOCATION: la zona del cluster.

Disabilita il driver CSI Managed Lustre

Puoi disattivare il driver CSI di Managed Lustre su un cluster GKE esistente utilizzando Google Cloud CLI.

gcloud container clusters update ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --update-addons=LustreCsiDriver=DISABLED

Dopo la disattivazione del driver CSI, GKE ricrea automaticamente i nodi e disinstalla i moduli del kernel Managed Lustre.

Accedi a un'istanza Managed Lustre esistente utilizzando il driver CSI Managed Lustre

Se hai già eseguito il provisioning di un'istanza Managed Lustre all'interno della stessa rete del tuo cluster GKE, puoi seguire queste istruzioni per eseguire il provisioning statico di un PersistentVolume che fa riferimento alla tua istanza.

Le sezioni seguenti descrivono la procedura tipica per accedere a un'istanza Managed Lustre esistente utilizzando il driver CSI Managed Lustre:

  1. Crea un PersistentVolume che faccia riferimento all'istanza Managed Lustre.
  2. Usa un oggetto PersistentVolumeClaim per accedere al volume.
  3. Crea un workload che utilizzi il volume.

Crea un PersistentVolume

  1. Per individuare l'istanza di Managed Lustre, esegui questo comando.

    gcloud lustre instances list \
        --project=${PROJECT_ID} \
        --location=${LOCATION}
    

    L'output dovrebbe essere simile al seguente. Prima di procedere al passaggio successivo, assicurati di annotare i campi nome dell'istanza Managed Lustre, filesystem e mountPoint.

    capacityGib: '9000'
    createTime: '2025-04-28T22:42:11.140825450Z'
    filesystem: testlfs
    gkeSupportEnabled: true
    mountPoint: 10.90.1.4@tcp:/testlfs
    name: projects/my-project/locations/us-central1-a/instances/my-lustre
    network: projects/my-project/global/networks/default
    perUnitStorageThroughput: '1000'
    state: ACTIVE
    updateTime: '2025-04-28T22:51:41.559098631Z'
    
  2. Salva il seguente manifest in un file denominato lustre-pv.yaml:

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: lustre-pv
    spec:
      storageClassName: "STORAGE_CLASS_NAME"
      capacity:
        storage: 9000Gi
      accessModes:
        - ReadWriteMany
      persistentVolumeReclaimPolicy: Retain
      volumeMode: Filesystem
      claimRef:
        namespace: default
        name: lustre-pvc
      csi:
        driver: lustre.csi.storage.gke.io
        volumeHandle: "PROJECT_ID/LOCATION/INSTANCE_NAME"
        volumeAttributes:
          ip: IP_ADDRESS
          filesystem: FILESYSTEM
    

    Sostituisci quanto segue:

    • storageClassName: il nome di StorageClass. Il valore può essere una stringa vuota, ma deve soddisfare la specifica del PersistentVolumeClaim.
    • volumeHandle: l'identificatore di questo volume.
      • PROJECT_ID: l'ID progetto Google Cloud .
      • LOCATION: la posizione zonale dell'istanza Lustre. Devi specificare una zona supportata per il driver CSI Managed Lustre.
      • INSTANCE_NAME: il nome dell'istanza Lustre.
    • ip: l'indirizzo IP della tua istanza Lustre. Ottieni questo valore dal campo mountPoint nell'output del comando precedente.
    • filesystem: il nome del file system dell'istanza Managed Lustre.

    Per l'elenco completo dei campi supportati nell'oggetto PersistentVolume, consulta la documentazione di riferimento del driver CSI Managed Lustre.

  3. Crea PersistentVolume eseguendo questo comando:

    kubectl apply -f lustre-pv.yaml
    

Utilizza PersistentVolumeClaim per accedere al volume

Puoi creare una risorsa PersistentVolumeClaim che fa riferimento a StorageClass del driver CSI Managed Lustre.

Il seguente file manifest mostra un esempio di come creare un PersistentVolumeClaim nella modalità di accesso ReadWriteMany, che fa riferimento alla StorageClass creata in precedenza.

  1. Salva il seguente manifest in un file denominato lustre-pvc.yaml:

    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: lustre-pvc
    spec:
      accessModes:
        - ReadWriteMany
      storageClassName: "STORAGE_CLASS_NAME"
      volumeName: lustre-pv
      resources:
        requests:
          storage: STORAGE_SIZE
    

    Sostituisci STORAGE_SIZE con le dimensioni dello spazio di archiviazione, ad esempio 9000Gi. Deve corrispondere alla specifica nel PersistentVolume.

  2. Crea l'oggetto PersistentVolumeClaim eseguendo questo comando:

    kubectl create -f lustre-pvc.yaml
    

Crea un workload che utilizzi il volume

Questa sezione mostra come creare un pod che utilizza la risorsa PersistentVolumeClaim creata in precedenza.

Più pod possono condividere la stessa risorsa PersistentVolumeClaim.

  1. Salva il seguente manifest in un file denominato my-pod.yaml.

    apiVersion: v1
    kind: Pod
    metadata:
      name: my-pod
    spec:
      containers:
      - name: nginx
        image: nginx
        volumeMounts:
          - name: lustre-volume
            mountPath: /data
      volumes:
      - name: lustre-volume
        persistentVolumeClaim:
          claimName: lustre-pvc
    
  2. Esegui questo comando per applicare il manifest al cluster:

    kubectl apply -f my-pod.yaml
    

    Il pod attende che GKE esegua il provisioning di PersistentVolumeClaim prima di iniziare l'esecuzione. Il completamento di questa operazione potrebbe richiedere diversi minuti.

  3. Verifica che il pod sia in esecuzione:

    kubectl get pods
    

    Potrebbero essere necessari alcuni minuti prima che il pod raggiunga lo stato Running.

    L'output è simile al seguente:

    NAME           READY   STATUS    RESTARTS   AGE
    my-pod         1/1     Running   0          11s
    

Utilizzare fsGroup con i volumi Managed Lustre

Puoi modificare la proprietà del gruppo della directory di livello radice del file system montato in modo che corrisponda a un fsGroup richiesto dall'utente specificato in SecurityContext del pod.

Risoluzione dei problemi

Per indicazioni sulla risoluzione dei problemi, consulta la pagina di risoluzione dei problemi nella documentazione di Managed Lustre.

Esegui la pulizia

Per evitare che al tuo account Google Cloud vengano addebitati costi, elimina le risorse di archiviazione che hai creato in questa guida.

  1. Elimina il pod e PersistentVolumeClaim.

    kubectl delete pod my-pod
    kubectl delete pvc lustre-pvc
    
  2. Controlla lo stato di PersistentVolume. Dopo aver eliminato il pod e PersistentVolumeClaim, PersistentVolume dovrebbe segnalare lo stato "Released":

    kubectl get pv
    

    L'output è simile al seguente:

    NAME        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     CLAIM                 STORAGECLASS   REASON   AGE
    lustre-pv   9000Gi      RWX            Retain        Released   default/preprov-pvc                           2m28s
    
  3. Riutilizza il PersistentVolume. Per riutilizzare PersistentVolume, rimuovi il riferimento alla richiesta (claimRef):

    kubectl patch pv lustre-pv --type json -p '[{"op": "remove", "path": "/spec/claimRef"}]'
    

    PersistentVolume dovrebbe ora segnalare lo stato "Disponibile", a indicare che è pronto per essere associato a un nuovo PersistentVolumeClaim. Controlla lo stato di PersistentVolume:

    kubectl get pv
    

    L'output è simile al seguente:

    NAME        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
    lustre-pv   9000Gi      RWX           Retain         Available                                   19m
    
  4. Elimina PersistentVolume se non è più necessario. Se PersistentVolume non è più necessario, eliminalo:

    kubectl delete pv lustre-pv
    

    L'eliminazione di PersistentVolume non rimuove l'istanza Managed Lustre sottostante.

Passaggi successivi