Fehlerbehebung bei Speicherfehlern in Sicherung für GKE

Auf dieser Seite werden speicherbezogene Fehler beschrieben, die bei der Verwendung von Sicherung für GKE auftreten können. Außerdem werden die zu berücksichtigenden Aspekte bei der Ausführung der Aktion und die Schritte zur Fehlerbehebung erläutert.

Fehler 100010105: Fehler beim Sichern von PersistentVolumeClaim – das von PersistentVolume referenzierte Laufwerk ist nicht vorhanden

Der Fehler 100010105 tritt auf, wenn der Versuch, ein PersistentVolumeClaim fehlschlägt, weil es auf ein nicht vorhandenes Laufwerk verweist. In diesem Fall wird eine Fehlermeldung angezeigt: Failed to backup PersistentVolumeClaim - Disk referenced by PersistentVolume does not exist.

In Google Kubernetes Engine fordern PersistentVolumeClaims Speicher von PersistentVolumes an. Ein PersistentVolume stellt wiederum eine Speichereinheit dar, oft ein zugrunde liegender nichtflüchtiger Compute Engine-Speicher. Ein Fehler kann auftreten wenn ein PersistentVolumeClaim an ein PersistentVolume gebunden ist und in der Konfiguration des PersistentVolume' ein nichtflüchtiger Compute Engine-Speicher angegeben ist. Das tatsächliche Laufwerk mit dem in der PersistentVolume Konfiguration angegebenen Namen und Speicherort kann jedoch nicht in your Cloud de Confiance by S3NS project gefunden werden. Daher kann Sicherung für GKE das nicht vorhandene Laufwerk nicht sichern und es tritt ein Fehler auf.

So beheben Sie diesen Fehler:

  1. Identifizieren Sie das problematische PersistentVolumeClaim und PersistentVolume. Die Namen des problematischen PersistentVolumeClaim und des zugehörigen PersistentVolume sind im Feld state reason des fehlgeschlagenen Sicherung für GKE-Vorgangs aufgeführt. Wir empfehlen, sowohl den PersistentVolumeClaim Namen als auch den zugehörigen Namespace und den Namen des PersistentVolume zu dokumentieren.

  2. Prüfen Sie das PersistentVolume. Verwenden Sie den Namen des PersistentVolume, den Sie im Feld „state reason“ gefunden haben, um das PersistentVolume mit dem folgenden Befehl zu beschreiben:

    kubectl describe pv PERSISTENTVOLUME_NAME

    Ersetzen Sie PERSISTENTVOLUME_NAME durch den Namen Ihres PersistentVolume.

  3. Prüfen Sie in der Ausgabe den Abschnitt source, insbesondere unter csi. In diesem Abschnitt wird das VolumeHandle beschrieben, auf das das PersistentVolume verweist. Beispiel:

    Source:
  Type: GCEPersistentDisk (a Persistent Disk resource in Google Compute Engine)
PDName: my-non-existent-disk
FSType: ext4
Partition: 0
ReadOnly: false
            In this example, the PD name is my-non-existent-disk.

    Source:
  Type:       CSI (a Container Storage Interface (CSI) volume)
  Driver:     pd.csi.storage.gke.io
  VolumeHandle: projects/PROJECT_ID/zones/ZONE/disks/DISK_NAME
...

    In diesem Beispiel enthält das VolumeHandle den vollständigen Pfad zum Laufwerk, einschließlich Name und Speicherort. Beispiel: projects/my-gcp-project/zones/us-central1-a/disks/my-disk-name.

  4. Verwenden Sie das VolumeHandle aus der Beschreibung des PersistentVolume, um den Laufwerksnamen und die Zone zu ermitteln.

  5. Prüfen Sie mit einer der folgenden Methoden, ob das Laufwerk in Ihrem Cloud de Confiance by S3NS Projekt vorhanden ist:

    Zonales Laufwerk

    Wenn Sie ein zonales Laufwerk verwenden, führen Sie den Befehl gcloud compute disks describe über die Google Cloud CLI aus:

    gcloud compute disks describe DISK_NAME \
    --zone=ZONE_NAME \
    --project=PROJECT_ID

    Ersetzen Sie Folgendes:

    • DISK_NAME: der Name des Laufwerks, den Sie aus der Beschreibung des PersistentVolume erhalten haben.

    • ZONE_NAME: die Zone des Laufwerks, die Sie aus der Beschreibung des PersistentVolume erhalten haben.

    • PROJECT_ID: Ihre Cloud de Confiance by S3NS Projekt-ID.

    Regionales Laufwerk

    Wenn Sie ein regionales Laufwerk verwenden, führen Sie den Befehl gcloud compute disks describe über die Google Cloud CLI aus:

    gcloud compute disks describe DISK_NAME \
    --region=REGION_NAME \
    --project=PROJECT_ID

    Ersetzen Sie Folgendes:

    • DISK_NAME: der Name des Laufwerks, den Sie aus der Beschreibung des PersistentVolume erhalten haben.

    • REGION_NAME: die Region des Laufwerks, die Sie aus der Beschreibung des PersistentVolume erhalten haben.

    • PROJECT_ID: Ihre Cloud de Confiance by S3NS Projekt-ID.

    Wenn die Fehlermeldung Resource not found oder The resource DISK_NAME was not found angezeigt wird, ist das Laufwerk nicht vorhanden. Verwenden Sie eine der folgenden Methoden, um das Problem zu beheben, je nachdem, welches Szenario am besten zu Ihren Anforderungen passt:

    • Wenn das Laufwerk versehentlich gelöscht oder falsch benannt wurde und Sie die Daten oder PersistentVolumeClaim behalten möchten oder wenn das PersistentVolume mit einem falschen Laufwerksnamen konfiguriert wurde, verwenden Sie eine der folgenden Methoden, um das Problem zu beheben:

      • Laufwerk wiederherstellen: Wenn Sie eine Sicherung des Laufwerks haben, stellen Sie es mit genau demselben Namen und Speicherort wieder her, auf die das PersistentVolume verweist.

      • Neues Laufwerk erstellen: Wenn das Wiederherstellen des Laufwerks keine Option ist, erstellen Sie ein neues Laufwerk mit demselben Namen und Speicherort, die in der PersistentVolume Konfiguration angegeben sind.

    • Wenn das PersistentVolumeClaim oder PersistentVolume, die zugehörigen Daten oder die Anwendung nicht mehr benötigt werden, empfehlen wir, die nicht benötigte Entität zu entfernen:

      • Löschen Sie das PersistentVolumeClaim: Löschen Sie das PersistentVolumeClaim, indem Sie mit dem kubectl-Befehlszeilentool den kubectl delete pvc-Befehl ausführen:
      kubectl delete pvc PVC_NAME -n NAMESPACE

      Ersetzen Sie Folgendes:

      • PVC_NAME: der Name des PersistentVolumeClaim, das Sie löschen möchten.

      • NAMESPACE: der Namespace des PersistentVolumeClaim, das Sie löschen möchten.

    • Das PersistentVolume ist nach dem Löschen des PersistentVolumeClaim: Wenn die PersistentVolumeReclaimPolicy des PersistentVolume auf Delete gesetzt ist, wird das PersistentVolume automatisch gelöscht, wenn das PersistentVolumeClaim gelöscht wird. Wenn die persistentVolumeReclaimPolicy auf Retain gesetzt ist, müssen Sie das PersistentVolume manuell löschen, nachdem das PersistentVolumeClaim gelöscht wurde. Verwenden Sie das PersistentVolume, um das kubectl Befehlszeilentool zu löschen, und führen Sie das kubectl delete pv Befehl aus:

      kubectl delete pv PV_NAME

      Ersetzen Sie PV_NAME durch den Namen des PersistentVolume, das Sie löschen möchten.

Cloud de Confiance by S3NS

Wenn der Vorgang weiterhin fehlschlägt, wenden Sie sich an den Cloud Customer Care.

Fehler 100010202: Fehler beim Erstellen eines Snapshots des Volumes

Der Fehler 100010202 tritt auf, wenn die Erstellung eines Snapshots eines nichtflüchtigen Compute Engine-Speichers fehlschlägt. In diesem Fall wird die Fehlermeldung Snapshotting volume failed angezeigt.

Ein Snapshot-Vorgang für einen nichtflüchtigen Compute Engine-Speicher schlägt fehl, wenn sich der Anhängestatus des Laufwerks an eine VM-Instanz während der Snapshot-Erstellung ändert, die vom Sicherung für GKE-Dienst initiiert wurde. Häufige Szenarien, die dies auslösen, sind:

  • Automatische Knotenreparatur: Fehlerhafte Knoten werden neu erstellt, wodurch Pods neu geplant und Laufwerke getrennt und wieder angehängt werden.
  • Knoten-Upgrades: Bei Knotenpool-Upgrades werden Knoten in der Regel geleert und ersetzt. Pods werden ordnungsgemäß beendet und auf den neuen Knoten neu geplant, wodurch Zyklen zum Trennen und Anhängen von Laufwerken ausgelöst werden.
  • Cluster-Autoscaling: Wenn der Cluster-Autoscaler bei Herunterskalierungsereignissen einen Knoten entfernt, werden alle Pods auf diesem Knoten mit nichtflüchtigen Speichern entfernt, was zu Trennungen von Laufwerken führt. Wenn diese Pods an anderer Stelle neu geplant werden, werden Anhänge auf den neuen Knoten erstellt. Bei Hochskalierungsereignissen verursachen neue Knoten nicht direkt erneute Anhänge, aber Pods, die auf ihnen geplant sind, lösen anfängliche Anhänge aus.

Es handelt sich dabei nur um einen vorübergehenden Fehler. Die Sicherung wird in der Regel beim nächsten automatischen Ausführen erfolgreich abgeschlossen, sobald die Laufwerksanhänge stabil sind. So verhindern Sie, dass sich Clusterereignisse auf Ihre Sicherungen auswirken:

  1. Intelligente Planung aktivieren: Konfigurieren Sie Ihren Sicherungsplan mit der intelligenten Planung (einem RPO-basierten Zeitplan). So kann das System vorübergehende Fehler innerhalb des angegebenen Zeitfensters automatisch wiederholen, ohne das Gesamt-RPO des Sicherungsplans zu beeinträchtigen.

  2. Ausschlussfenster für Sicherungen einrichten: Wenn Sie Knotenpool Upgrades oder Cluster-Größenänderungen durchführen, fügen Sie Ihren Sicherungseinstellungen für diese Zeiträume ein Ausschlussfenster für Sicherungen hinzu. So wird sichergestellt, dass der Sicherung für GKE-Dienst pausiert und keine Snapshots geplant werden, während Ihr Cluster Laufwerksanhänge aktiv ändert.

  3. Manuelle Sicherungen wiederholen: Bei manuellen oder On-Demand-Sicherungen wiederholen Sie den Sicherungsvorgang, sobald das Clusterereignis abgeschlossen ist.

Wenn der Vorgang weiterhin fehlschlägt, wenden Sie sich an den Cloud Customer Care.

Nächste Schritte