Fehlerbehebung bei Managed Lustre-Volumes

Auf dieser Seite finden Sie Schritte zur Fehlerbehebung für häufige Probleme und Fehler bei der Verwendung des Google Cloud Managed Lustre-CSI-Treibers in Google Kubernetes Engine.

Bevor Sie die Schritte zur Fehlerbehebung in diesem Abschnitt ausführen, lesen Sie die Einschränkungen beim Herstellen einer Verbindung zu Managed Lustre über GKE.

Aktualisierte Mindestkapazität für Instanzen

Die Mindestkapazität für verwaltete Lustre-Instanzen wurde auf 9.000 GiB aktualisiert. Wenn Sie Instanzen mit 9.000 GiB mit dem verwalteten Lustre-CSI-Treiber erstellen möchten, aktualisieren Sie Ihre Clusterversion auf 1.34.0-gke.2285000 oder höher.

Falsche Leistungsstufe für dynamisch bereitgestellte Lustre-Instanzen

Beim dynamischen Bereitstellen einer Lustre-Instanz schlägt die Instanzerstellung mit einem InvalidArgument-Fehler für „PerUnitStorageThroughput“ fehl, unabhängig vom in der API-Anfrage angegebenen „perUnitStorageThroughput“-Wert. Dies betrifft GKE 1.33-Versionen vor 1.33.4-gke.1036000.

Workaround:

Führen Sie ein Upgrade des GKE-Cluster auf Version 1.33.4-gke.1036000 oder höher durch. Wenn Sie den Stable Channel verwenden, ist möglicherweise noch keine neuere Version verfügbar. In diesem Fall können Sie manuell eine Version aus den Kanälen „Regelmäßig“ oder „Schnell“ auswählen, die den Fix enthält.

Kommunikationsports für Managed Lustre

Der 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 (988): Bei neuen GKE-Clustern, auf denen Version 1.33.2-gke.4780000 oder höher ausgeführt wird, verwendet der Treiber standardmäßig Port 988 für die Lustre-Kommunikation.

  • Legacy-Port (6988): Der Treiber verwendet Port 6988 in den folgenden Szenarien:

    • Frühere GKE-Versionen:Wenn auf Ihrem GKE-Cluster eine Version vor 1.33.2-gke.4780000 ausgeführt wird, ist das Flag --enable-legacy-lustre-port erforderlich, wenn Sie den CSI-Treiber aktivieren. Wenn Sie dieses Flag aktivieren, wird ein Portkonflikt mit dem gke-metadata-server auf GKE-Knoten umgangen.
    • Vorhandene Managed Lustre-Instanzen mit GKE-Unterstützung: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 einfügen, wenn Sie den CSI-Treiber aktivieren, unabhängig von Ihrer Clusterversion. Ohne dieses Flag kann in Ihrem GKE-Cluster die vorhandene Lustre-Instanz nicht eingebunden werden.

    Weitere Informationen zum Aktivieren des CSI-Treibers mit dem Legacy-Port finden Sie unter Lustre-Kommunikationsports.

Logabfragen

Führen Sie die folgende Abfrage im Log-Explorer aus, um die Logs zu prüfen.

So geben Sie Knotenserverprotokolle für den Managed Lustre CSI-Treiber zurück:

resource.type="k8s_container"
resource.labels.pod_name=~"lustre-csi-node*"

Fehlerbehebung bei der Bereitstellung von Volumes

Wenn der PersistentVolumeClaim (PVC) im Status Pending bleibt und nach 20 bis 30 Minuten kein PersistentVolume (PV) erstellt wird, ist möglicherweise ein Fehler aufgetreten.

  1. PVC-Ereignisse prüfen:

    kubectl describe pvc PVC_NAME
    
  2. Wenn der Fehler auf Konfigurationsprobleme oder ungültige Argumente hinweist, prüfen Sie die StorageClass-Parameter.

  3. Erstellen Sie das PVC neu.

  4. Wenn das Problem weiterhin besteht, wenden Sie sich an Cloud Customer Care.

Fehlerbehebung bei der Volume-Bereitstellung

Nachdem der Pod für einen Knoten geplant wurde, wird das Volume bereitgestellt. Wenn dies fehlschlägt, prüfen Sie die Pod-Ereignisse und Kubelet-Logs.

kubectl describe pod POD_NAME

Probleme bei der Aktivierung von CSI-Treibern

Symptom:

MountVolume.MountDevice failed for volume "yyy" : kubernetes.io/csi: attacher.MountDevice failed to create newCsiDriverClient: driver name lustre.csi.storage.gke.io not found in the list of registered CSI drivers

oder

MountVolume.SetUp failed for volume "yyy" : kubernetes.io/csi: mounter.SetUpAt failed to get CSI client: driver name lustre.csi.storage.gke.io not found in the list of registered CSI drivers

Ursache:Der CSI-Treiber ist nicht aktiviert oder wird noch nicht ausgeführt.

Lösung:

  1. Prüfen Sie, ob der CSI-Treiber aktiviert ist.
  2. Wenn der Cluster vor Kurzem skaliert oder aktualisiert wurde, warten Sie einige Minuten, bis der Treiber funktioniert.
  3. Wenn der Fehler weiterhin auftritt, suchen Sie in den lustre-csi-node-Logs nach „Operation not permitted“ (Vorgang nicht zulässig). Das bedeutet, dass die Knotenversion zu alt ist, um Managed Lustre zu unterstützen. Aktualisieren Sie Ihren Knotenpool auf Version 1.33.2-gke.1111000 oder höher, um dieses Problem zu beheben.
  4. Wenn in den Logs „LNET_PORT mismatch“ angezeigt wird, führen Sie ein Upgrade Ihres Knotenpools durch, um sicherzustellen, dass kompatible Lustre-Kernelmodule installiert sind.

Mountpoint ist bereits vorhanden

Symptom:

MountVolume.MountDevice failed for volume "yyy" : rpc error: code = AlreadyExists
desc = A mountpoint with the same lustre filesystem name "yyy" already exists on
node "yyy". Please mount different lustre filesystems

Ursache:Das Einbinden mehrerer Volumes aus verschiedenen Managed Lustre-Instanzen mit demselben Dateisystemnamen auf einem einzelnen Knoten wird nicht unterstützt.

Lösung:Verwenden Sie für jede Managed Lustre-Instanz einen eindeutigen Dateisystemnamen.

Mounting fehlgeschlagen: Datei oder Verzeichnis nicht vorhanden

Symptom:

MountVolume.MountDevice failed for volume "yyy" : rpc error: code = Internal desc = Could not mount ... failed: No such file or directory

Ursache:Der angegebene Dateisystemname ist falsch oder nicht vorhanden.

Lösung:Prüfen Sie, ob die fs_name in Ihrer StorageClass- oder PV-Konfiguration mit der Managed Lustre-Instanz übereinstimmt.

Bereitstellung fehlgeschlagen: Fehler bei Eingabe/Ausgabe

Symptom:

MountVolume.MountDevice failed for volume "yyy" : rpc error: code = Internal desc = Could not mount ... failed: Input/output error

Ursache:Der Cluster kann keine Verbindung zur Managed Lustre-Instanz herstellen.

Lösung:

  1. Prüfen Sie die IP-Adresse der Managed Lustre-Instanz.
  2. Achten Sie darauf, dass sich der GKE-Cluster und die Managed Lustre-Instanz im selben VPC-Netzwerk befinden oder richtig per Peering verbunden sind.

Interne Fehler

Symptom: rpc error: code = Internal desc = ...

Lösung:Wenn der Fehler weiterhin auftritt, wenden Sie sich an Cloud Customer Care.

Fehlerbehebung beim Trennen von Volumes

Symptom:

UnmountVolume.TearDown failed for volume "yyy" : rpc error: code = Internal desc = ...

Lösung:

  1. Erzwingen Sie das Löschen des Pods:

    kubectl delete pod POD_NAME --force
    
  2. Wenn das Problem weiterhin besteht, wenden Sie sich an Cloud Customer Care.

Fehlerbehebung beim Löschen von Volumes

Wenn sich der PV nach dem Löschen des PVC über einen längeren Zeitraum (z. B. mehr als eine Stunde) im Status „Freigegeben“ befindet, wenden Sie sich an Cloud Customer Care.

Fehlerbehebung bei der Volume-Erweiterung

PVC bleibt in ExternalExpanding hängen

Problem:Der PVC-Status ändert sich nicht in Resizing und in den Ereignissen wird ExternalExpanding angezeigt.

Ursache:Das Feld allowVolumeExpansion fehlt möglicherweise oder ist auf false gesetzt.

Lösung:Achten Sie darauf, dass StorageClass allowVolumeExpansion: true hat.

kubectl get storageclass STORAGE_CLASS_NAME -o yaml

Fehler bei der Erweiterung: Ungültiges Argument

Symptom: VolumeResizeFailed: rpc error: code = InvalidArgument ...

Ursache:Die angeforderte Größe ist ungültig, z. B. kein Vielfaches der Schrittweite oder außerhalb der Grenzwerte.

Lösung:Prüfen Sie die gültigen Kapazitätsbereiche und aktualisieren Sie den PVC mit einer gültigen Größe.

Erweiterung fehlgeschlagen: Interner Fehler

Symptom: VolumeResizeFailed ... rpc error: code = Internal

Lösung:Wiederholen Sie die Erweiterung, indem Sie das PVC noch einmal anwenden. Wenn die Synchronisierung wiederholt fehlschlägt, wenden Sie sich an Cloud Customer Care.

Frist überschritten

Symptom:VolumeResizeFailed mit DEADLINE_EXCEEDED.

Ursache:Der Vorgang dauert länger als erwartet, wird aber möglicherweise noch ausgeführt.

Lösung:Warten Sie, bis der Vorgang abgeschlossen ist. Der Resizer versucht es automatisch noch einmal. Wenn der Vorgang lange Zeit (z. B. länger als 90 Minuten) nicht abgeschlossen wird, wenden Sie sich an den Support.

Kontingent überschritten

Symptom:Die Erweiterung schlägt aufgrund von Kontingentlimits fehl.

Lösung: Fordern Sie eine Kontingenterhöhung oder eine geringere Kapazitätserhöhung an.