Mit dem Managed Lustre-CSI-Treiber auf vorhandene Managed Lustre-Instanzen in GKE zugreifen

In diesem Leitfaden wird beschrieben, wie Sie mithilfe des Managed Lustre-CSI-Treibers eine Verbindung zu einer vorhandenen Managed Lustre-Instanz herstellen können. So können Sie kontrolliert und vorhersehbar auf vorhandene Managed Lustre-Instanzen als Volumes für Ihre zustandsorientierten Arbeitslasten zugreifen.

Unterstützung mehrerer NICs für leistungsstarke Netzwerke

Für GKE-Cluster mit Version 1.35.2-gke.1842000 oder höher ist der Managed Lustre-CSI-Treiber standardmäßig aktiviert, um alle verfügbaren Netzwerkkarten (NICs) für einen höheren Durchsatz zu verwenden. Durch diese Unterstützung wird die Bandbreite aggregiert, indem der TCP-Speichertraffic auf Ihre Netzwerkschnittstellen verteilt wird.

Damit Sie die Unterstützung für mehrere NICs verwenden können, müssen Ihre Knoten die folgenden Anforderungen erfüllen:

  • Standard-NICs für TCP:Ihre Knoten müssen Standard-NICs wie Google Virtual NIC (gVNIC) oder VirtIO-Net verwenden, um TCP-Speichertraffic zu verarbeiten.
  • Dieselbe VPC:Alle Standard-NICs müssen sich im selben VPC-Netzwerk befinden.
  • RDMA-Überlegungen:An Ihre Knoten können auch RDMA-NICs angehängt sein. Der verwaltete Lustre-CSI-Treiber verwendet jedoch nur die Standard-NICs für den TCP-Speichertraffic.

Wenn Sie die Unterstützung für mehrere NICs deaktivieren möchten, lesen Sie den Abschnitt Unterstützung für mehrere NICs für Lustre deaktivieren.

Lustre-Kommunikationsports

Der GKE Managed Lustre CSI-Treiber verwendet je nach GKE-Clusterversion und vorhandenen Managed Lustre-Konfigurationen unterschiedliche Ports für die Kommunikation mit Managed Lustre-Instanzen.

  • Standardport (empfohlen): Bei neuen GKE-Clustern mit Version 1.33.2-gke.4780000 oder höher verwendet der Treiber standardmäßig Port 988 für die Lustre-Kommunikation.

  • Legacy-Port (eingestellt): Verwenden Sie Port 6988, indem Sie das Flag --enable-legacy-lustre-port an Ihre gcloud-Befehle anhängen, wenn:

    • Ältere GKE-Versionen:Wenn auf Ihrem GKE-Cluster eine Version vor 1.33.2-gke.4780000 ausgeführt wird, umgeht das Flag --enable-legacy-lustre-port einen Portkonflikt mit gke-metadata-server auf GKE-Knoten.
    • Vorhandene Lustre-Instanzen:Wenn Sie eine Verbindung zu einer vorhandenen Managed Lustre-Instanz herstellen, die mit dem Flag gke-support-enabled erstellt wurde, müssen Sie --enable-legacy-lustre-port weiterhin in Ihre gcloud-Befehle einfügen, unabhängig von Ihrer Clusterversion. Ohne dieses Flag kann in Ihrem GKE-Cluster die vorhandene Lustre-Instanz nicht eingebunden werden.

Sie können die neuen und vorhandenen Cluster so konfigurieren, dass entweder der Standardport 988 oder der Legacy-Port 6988 verwendet wird.

Hinweis

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Aktivieren Sie die Google Cloud Managed Lustre API und die Google Kubernetes Engine API.
    • APIs aktivieren
  • Wenn Sie die Google Cloud CLI für diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.

Umgebungsvariablen einrichten

Richten Sie die folgenden Umgebungsvariablen ein:

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

Ersetzen Sie Folgendes:

  • CLUSTER_NAME ist der Name des Clusters.
  • PROJECT_ID: Ihre Cloud de Confiance by S3NS Projekt-ID.
  • LUSTRE_NETWORK: Das freigegebene Virtual Private Cloud-Netzwerk, in dem sich sowohl der GKE-Cluster als auch die verwaltete Lustre-Instanz befinden.
  • ZONE: die geografische Zone Ihres GKE-Cluster, z. B. us-central1-a.

Verwalteten Lustre-CSI-Treiber konfigurieren

In diesem Abschnitt wird beschrieben, wie Sie den verwalteten Lustre-CSI-Treiber aktivieren und deaktivieren können.

Verwalteten Lustre-CSI-Treiber auf einem neuen GKE-Cluster aktivieren

In den folgenden Abschnitten wird beschrieben, wie Sie den verwalteten Lustre-CSI-Treiber in einem neuen GKE-Cluster aktivieren.

Standardport 988 verwenden

Führen Sie den folgenden Befehl aus, um den verwalteten Lustre-CSI-Treiber zu aktivieren, wenn Sie einen neuen GKE-Cluster mit Version 1.33.2-gke.4780000 oder höher erstellen:

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

Den alten Port 6988 verwenden

Führen Sie den folgenden Befehl aus, um den verwalteten Lustre-CSI-Treiber zu aktivieren, wenn Sie einen neuen GKE-Cluster erstellen, auf dem eine Version vor 1.33.2-gke.4780000 ausgeführt wird:

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

Verwalteten Lustre-CSI-Treiber auf vorhandenen GKE-Clustern aktivieren

In den folgenden Abschnitten wird beschrieben, wie Sie den Managed Lustre CSI-Treiber in vorhandenen GKE-Clustern aktivieren.

Standardport 988 verwenden

Führen Sie den folgenden Befehl aus, um den verwalteten Lustre-CSI-Treiber in einem vorhandenen GKE-Cluster zu aktivieren, auf dem Version 1.33.2-gke.4780000 oder höher ausgeführt wird:

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

Den alten Port 6988 verwenden

Wenn Sie den verwalteten Lustre-CSI-Treiber in einem vorhandenen GKE-Cluster aktivieren möchten, müssen Sie möglicherweise den Legacy-Port 6988 verwenden, indem Sie das Flag --enable-legacy-lustre-port hinzufügen. Dieses Flag ist in den folgenden Szenarien erforderlich:

  • Wenn Ihr GKE-Cluster eine ältere Version als 1.33.2-gke.4780000 verwendet.

  • Wenn Sie diesen Cluster mit einer vorhandenen Managed Lustre-Instanz verbinden möchten, die mit dem Flag gke-support-enabled erstellt wurde.

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

Knotenupgrade für vorhandene Cluster erforderlich

Wenn Sie den verwalteten Lustre-CSI-Treiber auf vorhandenen Clustern aktivieren, kann dies dazu führen, dass Knoten neu erstellt werden, um die erforderlichen Kernelmodule für den verwalteten Lustre-Client zu aktualisieren. Für eine sofortige Verfügbarkeit empfehlen wir, Ihre Knotenpools manuell zu aktualisieren.

GKE-Cluster in einem Release-Channel werden gemäß dem geplanten Rollout aktualisiert. Das kann je nach Wartungsfenster mehrere Wochen dauern. Wenn Sie eine statische GKE-Version verwenden, müssen Sie Ihre Knotenpools manuell aktualisieren.

Bis das Knotenupgrade vollständig abgeschlossen ist, kann es vorkommen, dass der CSI-Treiber-Pod auf Knoten, die auf ein Update warten, in einer Schleife abstürzt. Wenn in den CSI-Treiber-Pod-Logs ein Operation not permitted-Fehler angezeigt wird, ist ein Knoten-Upgrade oder eine Knoten-Neuerstellung erforderlich.

Nach dem Upgrade des Knotenpools wird für CPU-Knoten in der Cloud de Confiance -Konsole oder in der CLI-Ausgabe möglicherweise ein GPU-Image angezeigt. Dieses Verhalten ist so vorgesehen. Das GPU-Image wird auf CPU-Knoten wiederverwendet, um die verwalteten Lustre-Kernelmodule sicher zu installieren. Die GPU-Nutzung wird Ihnen nicht in Rechnung gestellt.

(Optional) Knotenpool mit mehreren NICs erstellen

Wenn Sie High-Performance Networking verwenden möchten, müssen Sie einen Knotenpool mit einem Instanztyp erstellen, der mehrere Netzwerkschnittstellen unterstützt. Die Unterstützung mehrerer NICs ist standardmäßig in GKE-Clustern mit Version 1.35.2-gke.1842000 oder höher aktiviert. Die sekundären Netzwerkschnittstellen müssen sich im selben VPC-Netzwerk wie die primäre Schnittstelle befinden.

Führen Sie dazu diesen Befehl aus:

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

Ersetzen Sie Folgendes:

  • NODE_POOL_NAME: Der Name des Knotenpools.
  • CLUSTER_NAME: Der Name Ihres Clusters.
  • LOCATION: Die Region oder Zone Ihres Clusters.
  • MACHINE_TYPE: Der Maschinentyp für den Knotenpool, z. B. a3-megagpu-8g, der häufig mit mehreren NICs für hohe Leistung verwendet wird. Multi-NIC wird auf allen Maschinentypen unterstützt.
  • NETWORK_NAME: der Name des VPC-Netzwerk.
  • SECONDARY_SUBNET: der Name des sekundären Subnetzes.

Multi-NIC für Lustre deaktivieren

Die Unterstützung mehrerer NICs wird für leistungsstarke Arbeitslasten empfohlen. In bestimmten Szenarien kann es jedoch sinnvoll sein, sie zu deaktivieren. Möglicherweise möchten Sie beispielsweise den Lustre-Traffic nicht auf alle verfügbaren Hardwareschnittstellen verteilen oder Sie müssen Verbindungsprobleme zu Fehlerbehebungszwecken auf einen einzelnen Netzwerkpfad beschränken.

Hinweis:Wenn Sie die Unterstützung für mehrere NICs auf laufenden Knoten deaktivieren, müssen Sie möglicherweise Ihre Knotenpools neu erstellen oder manuell aktualisieren, damit diese Änderung wirksam wird.

Für einen Cluster

Wenn Sie das Hochleistungsnetzwerk für den gesamten Cluster deaktivieren möchten, verwenden Sie beim Erstellen oder Aktualisieren des Clusters das Flag --disable-multi-nic-lustre. Beispiel:

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

Ersetzen Sie Folgendes:

  • CLUSTER_NAME: Der Name Ihres Clusters.
  • LOCATION: Die Region oder Zone Ihres Clusters.

Für einen Knotenpool

Wenn Sie High-Performance Networking für einen bestimmten Knotenpool deaktivieren möchten, aktualisieren Sie den Knotenpool, um das Label lustre.csi.storage.gke.io/multi-nic auf false zu setzen:

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

Ersetzen Sie Folgendes:

  • NODE_POOL_NAME: Der Name des Knotenpools.
  • CLUSTER_NAME: Der Name Ihres Clusters.
  • LOCATION: Die Zone Ihres Clusters.

Verwalteten Lustre-CSI-Treiber deaktivieren

Sie können den verwalteten Lustre-CSI-Treiber in einem vorhandenen GKE-Cluster mit der Google Cloud CLI deaktivieren.

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

Nachdem der CSI-Treiber deaktiviert wurde, erstellt GKE Ihre Knoten automatisch neu und deinstalliert die verwalteten Lustre-Kernelmodule.

Mit dem Managed Lustre-CSI-Treiber auf eine vorhandene Managed Lustre-Instanz zugreifen

Wenn Sie bereits eine Managed Lustre-Instanz im selben Netzwerk wie Ihren GKE-Cluster bereitgestellt haben, können Sie dieser Anleitung folgen, um ein PersistentVolume statisch bereitzustellen, das auf Ihre Instanz verweist.

In den folgenden Abschnitten wird das typische Verfahren für den Zugriff auf eine vorhandene Managed Lustre-Instanz mit dem Managed Lustre-CSI-Treiber beschrieben:

  1. PersistentVolume erstellen, das auf die Managed Lustre-Instanz verweist
  2. Greifen Sie mit einem PersistentVolumeClaim auf das Volume zu.
  3. Erstellen Sie eine Arbeitslast, die das Volume verbraucht.

PersistentVolume erstellen

  1. Führen Sie den folgenden Befehl aus, um Ihre verwaltete Lustre-Instanz zu finden.

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

    Die Ausgabe sollte ungefähr so aussehen: Bevor Sie mit dem nächsten Schritt fortfahren, notieren Sie sich die Felder Managed Lustre instance name (Name der Managed Lustre-Instanz), filesystem (Dateisystem) und mountPoint (Bereitstellungspunkt).

    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. Speichern Sie folgendes Manifest in einer Datei mit dem Namen 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

    Ersetzen Sie Folgendes:

    • storageClassName: ist der Name Ihrer StorageClass. Der Wert kann ein leerer String sein, muss aber der Spezifikation Ihres PersistentVolumeClaim entsprechen.
    • volumeHandle: die Kennung für dieses Volume.
      • PROJECT_ID: die Cloud de Confiance by S3NS Projekt-ID.
      • LOCATION: Der zonale Standort Ihrer Lustre-Instanz. Sie müssen eine unterstützte Zone für den Managed Lustre-CSI-Treiber angeben.
      • INSTANCE_NAME: Der Name Ihrer Lustre-Instanz.
    • ip: Die IP-Adresse Ihrer Lustre-Instanz. Sie erhalten diesen Wert aus dem Feld mountPoint in der Ausgabe des vorherigen Befehls.
    • filesystem: der Dateisystemname Ihrer Managed Lustre-Instanz.

    Eine vollständige Liste der Felder, die im PersistentVolume-Objekt unterstützt werden, finden Sie in der Referenzdokumentation zum Managed Lustre-CSI-Treiber.

  3. Erstellen Sie das PersistentVolume mit dem folgenden Befehl:

    kubectl apply -f lustre-pv.yaml

Mit dem PersistentVolumeClaim auf das Volume zugreifen

Sie können eine PersistentVolumeClaim-Ressource erstellen, die auf die StorageClass des CSI-Treibers für Managed Lustre verweist.

In der folgenden Manifestdatei wird ein Beispiel für das Erstellen eines PersistentVolumeClaims im ReadWriteMany-Zugriffsmodus gezeigt, der auf die zuvor erstellte StorageClass verweist.

  1. Speichern Sie folgendes Manifest in einer Datei mit dem Namen 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

    Ersetzen Sie STORAGE_SIZE durch die Speichergröße, z. B. 9000Gi. Sie muss mit der Spezifikation in Ihrem PersistentVolume übereinstimmen.

  2. Erstellen Sie den PersistentVolumeClaim mit dem folgenden Befehl:

    kubectl create -f lustre-pvc.yaml

Arbeitslast erstellen, die das Volume verbraucht

In diesem Abschnitt wird gezeigt, wie Sie einen Pod erstellen, der die zuvor erstellte PersistentVolumeClaim-Ressource verwendet.

Eine PersistentVolumeClaim-Ressource kann von mehreren Pods verwendet werden.

  1. Speichern Sie folgendes Manifest in einer Datei mit dem Namen 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. Führen Sie den folgenden Befehl aus, um das Manifest auf den Cluster anzuwenden:

    kubectl apply -f my-pod.yaml

    Der Pod wartet, bis GKE den PersistentVolumeClaim bereitstellt, bevor er ausgeführt wird. Dieser Vorgang kann einige Minuten dauern.

  3. Prüfen Sie, ob der Pod ausgeführt wird:

    kubectl get pods

    Es kann einige Minuten dauern, bis der Pod den Status Running erreicht.

    Die Ausgabe sieht etwa so aus:

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

fsGroup mit Managed Lustre-Volumes verwenden

Sie können das Gruppeneigentum des Stammverzeichnisses des eingebundenen Dateisystems so ändern, dass es einer vom Nutzer angeforderten fsGroup entspricht, die im SecurityContext des Pods angegeben ist.

Fehlerbehebung

Eine Anleitung zur Fehlerbehebung finden Sie in der Dokumentation zu Managed Lustre auf der Seite zur Fehlerbehebung.

Bereinigen

Damit Ihrem Cloud de Confiance by S3NS -Konto keine Gebühren in Rechnung gestellt werden, löschen Sie die in dieser Anleitung erstellten Speicherressourcen.

  1. Löschen Sie den Pod und den PersistentVolumeClaim.

    kubectl delete pod my-pod
kubectl delete pvc lustre-pvc

  2. Prüfen Sie den PersistentVolume-Status. Nach dem Löschen des Pods und des PersistentVolumeClaim sollte für das PersistentVolume der Status „Released“ (Freigegeben) angezeigt werden:

    kubectl get pv

    Die Ausgabe sieht etwa so aus:

    NAME        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     CLAIM                 STORAGECLASS   REASON   AGE
lustre-pv   9000Gi      RWX            Retain        Released   default/preprov-pvc                           2m28s

  3. PersistentVolume wiederverwenden Wenn Sie das PersistentVolume wiederverwenden möchten, entfernen Sie den Anspruchsverweis (claimRef):

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

    Das PersistentVolume sollte jetzt den Status „Available“ (Verfügbar) haben, was darauf hinweist, dass es bereit ist, an ein neues PersistentVolumeClaim gebunden zu werden. Prüfen Sie den PersistentVolume-Status:

    kubectl get pv

    Die Ausgabe sieht etwa so aus:

    NAME        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
lustre-pv   9000Gi      RWX           Retain         Available                                   19m

  4. Löschen Sie das PersistentVolume, wenn es nicht mehr benötigt wird. Wenn das PersistentVolume nicht mehr benötigt wird, löschen Sie es:

    kubectl delete pv lustre-pv

    Durch das Löschen des PersistentVolume wird die zugrunde liegende Managed Lustre-Instanz nicht entfernt.

Nächste Schritte