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

In dieser Anleitung wird beschrieben, wie Sie in GKE mit dynamischer Bereitstellung ein neues Kubernetes Volume erstellen, das vom Managed Lustre-CSI-Treiber unterstützt wird. Mit dem Managed Lustre-CSI-Treiber können Sie on demand Speicherplatz mit Managed Lustre-Instanzen erstellen und als Volumes für Ihre zustandsorientierten Arbeitslasten darauf zugreifen.

Unterstützung für mehrere NICs für Hochleistungsnetzwerke

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 Netzwerkschnittstellenkarten (Network Interface Cards, NICs) für einen höheren Durchsatz zu verwenden. Diese Unterstützung aggregiert die Bandbreite, indem der TCP-Speichertraffic auf die Netzwerkschnittstellen verteilt wird.

Damit die Unterstützung für mehrere NICs verwendet werden kann, müssen Ihre Knoten die folgenden Anforderungen erfüllen:

  • Standard-NICs für TCP: Ihre Knoten müssen Standard-NICs wie die virtuelle Google-NIC (gVNIC) oder VirtIO-Net verwenden, um den TCP-Speichertraffic zu verarbeiten.
  • Dasselbe VPC-Netzwerk: 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 Managed Lustre-CSI-Treiber verwendet jedoch nur die Standard-NICs für den TCP-Speichertraffic.

Informationen zum Deaktivieren der Unterstützung für mehrere NICs finden Sie unter 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) : Für neue GKE-Cluster mit Version 1.33.2-gke.4780000 oder höher verwendet der Treiber standardmäßig Port 988 für die Lustre-Kommunikation.

  • Legacy-Port (veraltet) : Verwenden Sie Port 6988, indem Sie den Befehlen gcloud in den folgenden Szenarien das Flag --enable-legacy-lustre-port anhängen:

    • Ä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 dem 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 unabhängig von Ihrer Clusterversion in Ihre gcloud-Befehle einfügen. Ohne dieses Flag kann Ihr GKE-Cluster die vorhandene Lustre-Instanz nicht einbinden.

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, installieren und dann initialisieren Sie die gcloud CLI. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem gcloud components update Befehl ab. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.
  • Informationen zu Einschränkungen und Anforderungen finden Sie in der Übersicht zum CSI-Treiber.
  • Achten Sie darauf, dass der Managed Lustre-CSI-Treiber aktiviert ist. Er ist in Standard- und Autopilot-Clustern standardmäßig deaktiviert.

Umgebungsvariablen einrichten

Richten Sie die folgenden Umgebungsvariablen ein:

export CLUSTER_NAME=CLUSTER_NAME
export PROJECT_ID=PROJECT_ID
export NETWORK_NAME=LUSTRE_NETWORK
export IP_RANGE_NAME=LUSTRE_IP_RANGE
export FIREWALL_RULE_NAME=LUSTRE_FIREWALL_RULE
export LOCATION=ZONE
export CLUSTER_VERSION=CLUSTER_VERSION

Ersetzen Sie Folgendes:

  • CLUSTER_NAME: Der Name des Clusters.
  • PROJECT_ID: Ihre Cloud de Confiance by S3NS Projekt-ID.
  • LUSTRE_NETWORK: Das freigegebene VPC-Netzwerk (Virtual Private Cloud), in dem sich sowohl der GKE-Cluster als auch die Managed Lustre-Instanz befinden.
  • LUSTRE_IP_RANGE: Der Name des IP-Adressbereichs, der für das VPC-Netzwerk-Peering mit Managed Lustre erstellt wurde.
  • LUSTRE_FIREWALL_RULE: Der Name der Firewallregel, mit der TCP-Traffic aus dem IP-Adressbereich zugelassen wird.
  • ZONE: Die geografische Zone Ihres GKE-Cluster, z. B. us-central1-a.
  • CLUSTER_VERSION: Die GKE-Clusterversion.

VPC-Netzwerk einrichten

Sie müssen dasselbe VPC-Netzwerk angeben, wenn Sie die Managed Lustre Instanz und Ihre GKE-Cluster erstellen. Wenn Sie ein VPC-Netzwerk mit Peering verwenden, müssen Sie die Verbindung über das Network Connectivity Center herstellen.

  1. Führen Sie den folgenden Befehl aus, um das Dienstnetzwerk zu aktivieren:

    gcloud services enable servicenetworking.googleapis.com \
        --project=${PROJECT_ID}
    
  2. VPC-Netzwerk erstellen. Wenn Sie das Flag --mtu auf 8896 setzen, erzielen Sie eine Leistungssteigerung von 10 %.

    gcloud compute networks create ${NETWORK_NAME} \
        --subnet-mode=auto --project=${PROJECT_ID} \
        --mtu=8896
    
  3. Erstellen Sie einen IP-Adressbereich.

    gcloud compute addresses create ${IP_RANGE_NAME} \
        --global \
        --purpose=VPC_PEERING \
        --prefix-length=20 \
        --description="Managed Lustre VPC Peering" \
        --network=${NETWORK_NAME} \
        --project=${PROJECT_ID}
    
  4. Rufen Sie den CIDR-Bereich ab, der dem im vorherigen Schritt erstellten Bereich zugeordnet ist.

    CIDR_RANGE=$(
      gcloud compute addresses describe ${IP_RANGE_NAME} \
          --global  \
          --format="value[separator=/](address, prefixLength)" \
          --project=${PROJECT_ID}
    )
    
  5. Erstellen Sie eine Firewallregel, um TCP-Traffic aus dem von Ihnen erstellten IP-Adressbereich zuzulassen.

    gcloud compute firewall-rules create ${FIREWALL_RULE_NAME} \
        --allow=tcp:988,tcp:6988 \
        --network=${NETWORK_NAME} \
        --source-ranges=${CIDR_RANGE} \
        --project=${PROJECT_ID}
    
  6. Wenn Sie das Netzwerk-Peering für Ihr Projekt einrichten möchten, prüfen Sie, ob Sie die erforderlichen IAM-Berechtigungen haben, insbesondere die Rolle compute.networkAdmin oder servicenetworking.networksAdmin.

    1. Rufen Sie die Cloud de Confiance Console > IAM & Verwaltung auf und suchen Sie nach dem Hauptkonto des Projektinhabers.
    2. Klicken Sie auf das Stiftsymbol und dann auf + WEITERE ROLLE HINZUFÜGEN.
    3. Wählen Sie Compute-Netzwerkadministrator oder Service Networking-Administrator aus.
    4. Klicken Sie auf Speichern.
  7. Verbinden Sie das Peering.

    gcloud services vpc-peerings connect \
        --network=${NETWORK_NAME} \
        --project=${PROJECT_ID} \
        --ranges=${IP_RANGE_NAME} \
        --service=servicenetworking.googleapis.com
    

Managed Lustre-CSI-Treiber konfigurieren

In diesem Abschnitt wird beschrieben, wie Sie den Managed Lustre-CSI-Treiber aktivieren und deaktivieren.

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

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

Standardport 988 verwenden

Führen Sie den folgenden Befehl aus, um den Managed 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

Legacy-Port 6988 verwenden

Führen Sie den folgenden Befehl aus, um den Managed Lustre-CSI-Treiber zu aktivieren, wenn Sie einen neuen GKE-Cluster mit einer Version vor 1.33.2-gke.4780000 erstellen:

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

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

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

Standardport 988 verwenden

Führen Sie den folgenden Befehl aus, um den Managed Lustre-CSI-Treiber auf einem vorhandenen GKE-Cluster mit Version 1.33.2-gke.4780000 oder höher zu aktivieren:

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

Legacy-Port 6988 verwenden

Wenn Sie den Managed Lustre-CSI-Treiber auf 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 auf Ihrem GKE-Cluster eine Version vor 1.33.2-gke.4780000 ausgeführt wird.
  • Wenn Sie diesen Cluster mit einer vorhandenen Managed Lustre-Instanz verbinden möchten, die mit dem gke-support-enabled Flag erstellt wurde.

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

Knotenupgrade für vorhandene Cluster erforderlich

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

GKE-Cluster in einer Release-Version werden gemäß dem geplanten Rollout aktualisiert. Das kann je nach Ihrem Wartungsfenster mehrere Wochen dauern. Wenn Sie eine statische GKE-Version verwenden, müssen Sie ein manuelles Upgrade Ihrer Knotenpools durchführen.

Bis das Knotenupgrade vollständig abgeschlossen ist, kann es zu einem Crashloop des CSI-Treiber-Pods auf Knoten kommen, die auf ein Update warten. Wenn in den Logs des CSI-Treiber-Pods der Fehler Operation not permitted angezeigt wird, ist ein Knotenupgrade oder eine Neuerstellung erforderlich.

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

(Optional) Knotenpool mit mehreren NICs erstellen

Wenn Sie Hochleistungsnetzwerke verwenden möchten, müssen Sie einen Knotenpool mit einem Instanztyp erstellen, der mehrere Netzwerkschnittstellen unterstützt. Die Unterstützung für mehrere NICs ist standardmäßig auf GKE-Clustern mit Version 1.35.2-gke.1842000 oder höher aktiviert. Achten Sie darauf, dass sich Ihre sekundären Netzwerkschnittstellen im selben VPC-Netzwerk wie Ihre 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 Hochleistung verwendet wird. Mehrere NICs werden für jeden Maschinentyp unterstützt.
  • NETWORK_NAME: Der Name des VPC-Netzwerk.
  • SECONDARY_SUBNET: Der Name des sekundären Subnetzes.

Mehrere NICs für Lustre deaktivieren

Die Unterstützung für mehrere NICs wird zwar für Hochleistungsarbeitslasten empfohlen, Sie sollten sie jedoch in bestimmten Szenarien deaktivieren. Beispielsweise möchten Sie möglicherweise nicht, dass der Lustre-Traffic auf alle verfügbaren Hardwareschnittstellen verteilt wird, oder Sie müssen Konnektivitätsprobleme zur Fehlerbehebung auf einen einzelnen Netzwerkpfad beschränken.

Hinweis: Wenn Sie die Unterstützung für mehrere NICs auf ausgeführten 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 Hochleistungsnetzwerke 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 Hochleistungsnetzwerke 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.

Managed Lustre-CSI-Treiber deaktivieren

Sie können den Managed Lustre-CSI-Treiber auf 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 Managed Lustre-Kernelmodule.

Neues Volume mit dem Managed Lustre-CSI-Treiber erstellen

In den folgenden Abschnitten wird das typische Verfahren zur Erstellung eines Kubernetes-Volumes beschrieben, das von einer Managed Lustre-Instanz in GKE unterstützt wird:

  1. StorageClass erstellen.
  2. Mit einem PersistentVolumeClaim auf das Volume zugreifen.
  3. Arbeitslast erstellen, die das Volume verbraucht.

StorageClass erstellen

Wenn der Managed Lustre-CSI-Treiber aktiviert ist, erstellt GKE automatisch eine StorageClass für die Bereitstellung von Managed Lustre-Instanzen. Die StorageClass hängt von der Managed Lustre Leistungsklasse, und ist eine der folgenden:

  • lustre-rwx-125mbps-per-tib
  • lustre-rwx-250mbps-per-tib
  • lustre-rwx-500mbps-per-tib
  • lustre-rwx-1000mbps-per-tib

GKE bietet für jede unterstützte Managed Lustre-Leistungsklasse eine Standard-StorageClass. Dadurch wird die dynamische Bereitstellung von Managed Lustre-Instanzen vereinfacht, da Sie die integrierten StorageClasses verwenden können, ohne eigene definieren zu müssen.

Bei zonalen Clustern stellt der CSI-Treiber Managed Lustre-Instanzen in derselben Zone wie der Cluster bereit. Bei regionalen Clustern wird die Instanz in einer der Zonen innerhalb der Region bereitgestellt.

Im folgenden Beispiel wird gezeigt, wie Sie eine benutzerdefinierte StorageClass mit bestimmten Topologieanforderungen erstellen:

  1. Speichern Sie folgendes Manifest in einer Datei mit dem Namen lustre-class.yaml:

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: lustre-class
    provisioner: lustre.csi.storage.gke.io
    volumeBindingMode: Immediate
    reclaimPolicy: Delete
    parameters:
      perUnitStorageThroughput: "1000"
      network: LUSTRE_NETWORK
    allowedTopologies:
    - matchLabelExpressions:
      - key: topology.gke.io/zone
        values:
        - us-central1-a
    

    Eine vollständige Liste der in der StorageClass unterstützten Felder finden Sie in der Referenzdokumentation zum Managed Lustre-CSI-Treiber.

  2. Erstellen Sie die StorageClass mit dem folgenden Befehl:

    kubectl apply -f lustre-class.yaml
    

Mit einem PersistentVolumeClaim auf das Volume zugreifen

In diesem Abschnitt wird beschrieben, wie Sie eine PersistentVolumeClaim Ressource erstellen, die auf die StorageClass des Managed Lustre-CSI-Treibers verweist.

  1. Speichern Sie folgendes Manifest in einer Datei mit dem Namen lustre-pvc.yaml:

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: lustre-pvc
    spec:
      accessModes:
      - ReadWriteMany
      resources:
        requests:
          storage: 9000Gi
      storageClassName: lustre-class
    

    Eine vollständige Liste der in der PersistentVolumeClaim unterstützten Felder finden Sie in der Referenzdokumentation zum Managed Lustre-CSI-Treiber.

  2. Erstellen Sie den PersistentVolumeClaim mit dem folgenden Befehl:

    kubectl apply -f lustre-pvc.yaml
    

Arbeitslast erstellen, die das Volume verbraucht

In diesem Abschnitt wird ein Beispiel für das Erstellen eines Pods gezeigt, der die zuvor erstellte PersistentVolumeClaim-Ressource verbraucht.

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. Wenden Sie das Manifest auf den Cluster an.

    kubectl apply -f my-pod.yaml
    
  3. Prüfen Sie, ob der Pod ausgeführt wird. Der Pod wird ausgeführt, nachdem der PersistentVolumeClaim bereitgestellt wurde. Dieser Vorgang kann einige Minuten dauern.

    kubectl get pods
    

    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 den Gruppeninhaber des Verzeichnisses auf Stammebene des eingebundenen Dateisystems so ändern, dass er einer vom Nutzer angeforderten fsGroup entspricht, die im Pod's SecurityContext angegeben ist. fsGroup ändert nicht rekursiv den Inhaber des gesamten eingebundenen Managed Lustre-Dateisystems. Nur das Stammverzeichnis des Einbindungspunkts ist betroffen.

Fehlerbehebung

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

Bereinigen

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

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

    kubectl delete pod my-pod
    kubectl delete pvc lustre-pvc
    
  2. Prüfen Sie den Status des PersistentVolume.

    kubectl get pv
    

    Die Ausgabe sieht etwa so aus:

    No resources found
    

    Es kann einige Minuten dauern, bis die zugrunde liegende Managed Lustre-Instanz vollständig gelöscht wurde.

Nächste Schritte