Diese Seite wurde von der Cloud Translation API übersetzt.

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

Autopilot Standard

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 verwalteten Lustre-CSI-Treiber können Sie on demand Speicherplatz mit verwalteten Lustre-Instanzen erstellen und als Volumes für Ihre zustandsorientierten Arbeitslasten darauf zugreifen.

Hinweise

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 gcloud components update ab.
Hinweis:Legen Sie für vorhandene Installationen der gcloud CLI das compute/region-Attribut fest. Wenn Sie hauptsächlich zonale Cluster verwenden, legen Sie stattdessen compute/zone fest. Durch das Festlegen eines Standardspeicherorts können Sie in der gcloud CLI Fehler wie One of [--zone, --region] must be supplied: Please specify location vermeiden. Bei bestimmten Befehlen müssen Sie möglicherweise den Speicherort angeben, wenn er sich von dem von Ihnen festgelegten Standard unterscheidet.

Informationen zu Einschränkungen und Anforderungen finden Sie in der CSI-Treiberübersicht.
Aktivieren Sie den verwalteten Lustre-CSI-Treiber. Sie 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

Ersetzen Sie Folgendes:

CLUSTER_NAME ist der Name des Clusters.
PROJECT_ID: Ihre Trusted Cloud by S3NS Projekt-ID.
LUSTRE_NETWORK: Das freigegebene VPC-Netzwerk (Virtual Private Cloud), in dem sich sowohl der GKE-Cluster als auch die verwaltete Lustre-Instanz befinden.
LUSTRE_IP_RANGE: Der Name des IP-Adressbereichs, der für das VPC-Network-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.

VPC-Netzwerk einrichten

Sie müssen beim Erstellen der verwalteten Lustre-Instanz und Ihrer GKE-Cluster dasselbe VPC-Netzwerk angeben.

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

gcloud services enable servicenetworking.googleapis.com \
    --project=${PROJECT_ID}

VPC-Netzwerk erstellen. Wenn Sie das Flag --mtu auf 8896 festlegen, ergibt sich eine Leistungssteigerung von 10 %.

gcloud compute networks create ${NETWORK_NAME} \
    --subnet-mode=auto --project=${PROJECT_ID} \
    --mtu=8896

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}

Rufen Sie den CIDR-Bereich ab, der dem Bereich zugeordnet ist, den Sie im vorherigen Schritt erstellt haben.

CIDR_RANGE=$(
  gcloud compute addresses describe ${IP_RANGE_NAME} \
      --global  \
      --format="value[separator=/](address, prefixLength)" \
      --project=${PROJECT_ID}
)

Erstellen Sie eine Firewallregel, die den TCP-Traffic aus dem von Ihnen erstellten IP-Adressbereich zulässt.

gcloud compute firewall-rules create ${FIREWALL_RULE_NAME} \
    --allow=tcp:988,tcp:6988 \
    --network=${NETWORK_NAME} \
    --source-ranges=${CIDR_RANGE} \
    --project=${PROJECT_ID}

Prüfen Sie, ob Sie die erforderlichen IAM-Berechtigungen haben, insbesondere die Rolle compute.networkAdmin oder servicenetworking.networksAdmin, um das Netzwerk-Peering für Ihr Projekt einzurichten.
1. Rufen Sie die Trusted Cloud Console > IAM & Verwaltung auf und suchen Sie nach dem Prinzipal 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.

Stellen Sie die Peering-Verbindung her.

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

Verwalteten Lustre-CSI-Treiber konfigurieren

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

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

So aktivieren Sie den verwalteten Lustre-CSI-Treiber beim Erstellen eines neuen GKE-Cluster:

Autopilot

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

Standard

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

Wenn das Flag enable-legacy-lustre-port angegeben ist, konfiguriert der CSI-Treiber LNet (die virtuelle Netzwerkschicht für das verwaltete Lustre-Kernelmodul) für die Verwendung von Port 6988. Dieses Flag ist erforderlich, um einen Portkonflikt mit gke-metadata-server auf GKE-Knoten zu umgehen.

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

Verwenden Sie den folgenden Befehl, um den verwalteten Lustre-CSI-Treiber in einem vorhandenen GKE-Cluster zu aktivieren:

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

Wenn Sie den verwalteten Lustre-CSI-Treiber 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 einer Release-Version werden gemäß dem geplanten Rollout aktualisiert. Das kann je nach Wartungszeitraum mehrere Wochen dauern. Wenn Sie eine statische GKE-Version verwenden, müssen Sie Ihre Knotenpools manuell aktualisieren.

Nach dem Upgrade des Knotenpools kann es vorkommen, dass CPU-Knoten in derTrusted Cloud -Konsole oder in der CLI-Ausgabe ein GPU-Image verwenden. Beispiel:

config:
  imageType: COS_CONTAINERD
  nodeImageConfig:
    image: gke-1330-gke1552000-cos-121-18867-90-4-c-nvda

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

Managed Lustre-CSI-Treiber deaktivieren

Sie können den Managed 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 ein neues Volume erstellen

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

StorageClass erstellen
Greifen Sie mit einem PersistentVolumeClaim auf das Volume zu.
Erstellen Sie eine Arbeitslast, die das Volume verbraucht.

StorageClass erstellen

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

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 Leistungsstufe von Managed Lustre eine Standard-StorageClass. Dies vereinfacht die dynamische Bereitstellung von Managed Lustre-Instanzen, 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.

Das folgende Beispiel zeigt, wie Sie eine benutzerdefinierte StorageClass mit bestimmten Topologieanforderungen erstellen:

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 verwalteten Lustre-CSI-Treiber.

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.

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: 18000Gi
  storageClassName: lustre-class
```
Eine vollständige Liste der Felder, die im PersistentVolumeClaim unterstützt werden, finden Sie in der Referenzdokumentation zum Managed Lustre-CSI-Treiber.
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 nutzt.

Eine PersistentVolumeClaim-Ressource kann von mehreren Pods verwendet werden.

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

Wenden Sie das Manifest auf den Cluster an.
```
kubectl apply -f my-pod.yaml
```
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 die Gruppenzugehörigkeit des Verzeichnisses auf Stammebene des eingebundenen Dateisystems so ändern, dass sie einer vom Nutzer angeforderten fsGroup entspricht, die im SecurityContext des Pods angegeben ist. fsGroup ändert die Zugehörigkeit des gesamten eingebundenen Managed Lustre-Dateisystems nicht rekursiv, sondern nur das Stammverzeichnis des Mount-Points.

Fehlerbehebung

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

Bereinigen

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

Löschen Sie den Pod und den PersistentVolumeClaim.

Hinweis :Wenn Sie das PersistentVolume mit der persistentVolumeReclaimPolicy „Delete“ erstellen, werden beim Löschen des PersistentVolumeClaim auch das PersistentVolume und die zugrunde liegende Managed Lustre-Instanz gelöscht.
```
kubectl delete pod my-pod
kubectl delete pvc lustre-pvc
```
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 verwaltete Lustre-Instanz vollständig gelöscht ist.

Nächste Schritte

Managed Lustre-Dokumentation ansehen