Fehlerbehebung bei Speicherfehlern in Sicherung für GKE

Autopilot Standard

Auf dieser Seite werden speicherbezogene Fehler beschrieben, die bei der Verwendung von Sicherung für GKE auftreten können, sowie Punkte, die Sie bei der Ausführung der Aktion beachten sollten, und Schritte zur Fehlerbehebung.

Fehler 100010105: Fehler beim Sichern von PersistentVolumeClaim – Auf PersistentVolume verwiesene Festplatte nicht vorhanden

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

In Google Kubernetes Engine wird mit PersistentVolumeClaims Speicher von PersistentVolumes angefordert. Ein PersistentVolume stellt wiederum einen Speicherbereich dar, häufig einen zugrunde liegenden Compute Engine Persistent Disk. Ein Fehler kann auftreten, wenn ein PersistentVolumeClaim an ein PersistentVolume gebunden ist und in der Konfiguration des PersistentVolume eine Compute Engine Persistent Disk angegeben ist. Das tatsächliche Laufwerk mit dem in der PersistentVolume-Konfiguration angegebenen Namen und Speicherort kann jedoch nicht in Ihrem Google Cloud -Projekt gefunden werden. Daher kann Sicherung für GKE nicht mit der Sicherung eines nicht vorhandenen Laufwerks fortfahren und es tritt ein Fehler auf.

So beheben Sie diesen Fehler:

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

2. Prüfen Sie PersistentVolume. Verwenden Sie zum Beschreiben des PersistentVolume den Namen des PersistentVolume, den Sie im Feld „Statusgrund“ im folgenden Befehl identifiziert haben:

   kubectl describe pv PERSISTENTVOLUME_NAME
   

   Ersetzen Sie PERSISTENTVOLUME_NAME durch den Namen Ihres PersistentVolume.

3. Sehen Sie sich in der Ausgabe den Abschnitt source an, insbesondere unter csi. In diesem Abschnitt wird die VolumeHandle beschrieben, auf die die 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 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 die VolumeHandle aus der PersistentVolume-Beschreibung, um den Namen und die Zone des Laufwerks zu ermitteln.

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

   Zonales Laufwerk

   Wenn Sie einen zonalen Datenträger verwenden, führen Sie den Befehl gcloud compute disks describe mit der 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 von PersistentVolume erhalten haben.

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

   • PROJECT_ID: Projekt-ID in Google Cloud .

   Regionales Laufwerk

   Wenn Sie einen regionalen Datenträger verwenden, führen Sie den Befehl gcloud compute disks describe mit der 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 von PersistentVolume erhalten haben.

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

   • PROJECT_ID: Projekt-ID in Google Cloud .

   Wenn Sie die Fehlermeldung Resource not found oder The resource DISK_NAME was not found erhalten, 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 die PersistentVolume mit einem falschen Laufwerksnamen konfiguriert wurde, verwenden Sie eine der folgenden Methoden, um das Problem zu beheben:

     • Festplatte wiederherstellen: Wenn Sie ein Backup der Festplatte haben, stellen Sie sie mit genau demselben Namen und Speicherort wieder her, auf die PersistentVolume verweist.

     • Neues Laufwerk erstellen: Wenn das Wiederherstellen des Laufwerks nicht möglich ist, erstellen Sie ein neues Laufwerk mit demselben Namen und Speicherort wie in der PersistentVolume-Konfiguration.

   • Wenn die PersistentVolumeClaim oder PersistentVolume, ihre Daten oder die Anwendung nicht mehr benötigt werden, empfehlen wir, die nicht benötigte Einheit zu entfernen:

     • PersistentVolumeClaim löschen: Löschen Sie die PersistentVolumeClaim mit dem kubectl-Befehlszeilentool, indem Sie den Befehl kubectl delete pvc ausführen:

     kubectl delete pvc PVC_NAME -n NAMESPACE
     

     Ersetzen Sie Folgendes:

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

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

   • Die PersistentVolume ist nach dem Löschen der PersistentVolumeClaim weiterhin vorhanden: Wenn die PersistentVolumeReclaimPolicy der PersistentVolume auf Delete festgelegt ist, wird die PersistentVolume automatisch gelöscht, wenn die PersistentVolumeClaim gelöscht wird. Wenn persistentVolumeReclaimPolicy auf Retain festgelegt ist, müssen Sie PersistentVolume manuell löschen, nachdem PersistentVolumeClaim gelöscht wurde. Wenn Sie die PersistentVolume löschen möchten, führen Sie mit dem kubectl-Befehlszeilentool den Befehl kubectl delete pv aus:

     kubectl delete pv PV_NAME
     

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

Wichtig: Wenn reclaimPolicy auf Retain gesetzt ist und das zugrunde liegende Laufwerk vorhanden ist, wird das Laufwerk beim Löschen von PersistentVolume nicht gelöscht. Sie müssen das Laufwerk manuell aus Google Cloud löschen, wenn es wirklich nicht mehr benötigt wird.

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

Fehler 100010202: Erstellen von Snapshots für Volume fehlgeschlagen

Der Fehler 100010202 tritt auf, wenn die Erstellung eines Snapshots für einen Compute Engine Persistent Disk fehlschlägt. Es wird die Fehlermeldung Snapshotting volume failed angezeigt.

Ein Snapshot-Vorgang für einen Compute Engine Persistent Disk schlägt fehl, wenn sich der Status des Laufwerksanhangs an eine VM-Instanz während des Snapshot-Erstellungsvorgangs ändert, der vom Sicherung für GKE-Dienst initiiert wurde. Häufige Szenarien, die dies auslösen, sind:

• Automatische Knotenreparatur: Fehlerhafte Knoten werden neu erstellt. Dadurch werden Pods neu geplant und Laufwerke getrennt und wieder angehängt.
• Knotenupgrades: Bei Knotenpoolupgrades werden Knoten in der Regel geleert und ersetzt. Pods werden ordnungsgemäß beendet und auf den neuen Knoten neu geplant. Dadurch werden Zyklen zum Trennen und erneuten Anhängen von Laufwerken ausgelöst.
• Cluster-Autoscaling: Wenn Cluster Autoscaler beim Herunterskalieren einen Knoten entfernt, werden alle Pods auf diesem Knoten mit nichtflüchtigen Speichern entfernt, was zu einer Trennung der Laufwerke führt. Wenn diese Pods an anderer Stelle neu geplant werden, werden die Anhänge auf den neuen Knoten erstellt. Bei Scale-up-Ereignissen führen neue Knoten nicht direkt zu erneuten Anhängen, aber Pods, die auf ihnen geplant sind, lösen die ersten Anhänge aus.

Es handelt sich dabei nur um einen vorübergehenden Fehler. Die Sicherung ist in der Regel beim nächsten automatischen Durchlauf erfolgreich, sobald sich die Laufwerksverbindung stabilisiert hat. Damit Clusterereignisse keine Auswirkungen auf Ihre Sicherungen haben, sollten Sie die folgenden Empfehlungen beachten:

1. Smartprogramm aktivieren: Konfigurieren Sie Ihren Sicherungsplan mit dem Smartprogramm (ein RPO-basierter Zeitplan). So kann das System vorübergehende Fehler innerhalb des angegebenen Zeitfensters automatisch wiederholen, ohne dass sich dies auf das RPO des Sicherungsplans auswirkt.

2. Ausschlussfenster für Sicherungen einrichten: Wenn Sie Knotenpool-Upgrades oder Clustergrößenänderungen durchführen, fügen Sie Ihren Sicherungseinstellungen während dieser Intervalle ein Ausschlussfenster für Sicherungen hinzu. Dadurch wird sichergestellt, dass der Sicherung für GKE-Dienst pausiert und keine Snapshots plant, während Ihr Cluster aktiv Laufwerksanhänge ändert.

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

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

Nächste Schritte

• Übersichtsseite zu Sicherung für GKE-Fehlercodes