Fehler bei Wiederherstellungsvorgängen in Sicherung für GKE beheben

In diesem Dokument werden die Fehler und die entsprechenden Codes beschrieben, die bei der Verwendung von Sicherung für GKE zum Ausführen von Wiederherstellungsvorgängen auftreten können. Jeder Abschnitt enthält Hinweise, die Sie bei der Behebung der Wiederherstellungsfehler beachten sollten, sowie eine Anleitung zur Behebung der Fehler bei der Wiederherstellung.

Fehler 200010301: Wiederherstellungsvorgang konnte aufgrund eines nicht verfügbaren Zugangs-Webhook-Dienstes nicht abgeschlossen werden

Der Fehler 200010301 tritt auf, wenn ein Wiederherstellungsvorgang fehlschlägt, weil ein Admission-Webhook-Dienst (auch als HTTP-Callback bezeichnet) nicht verfügbar ist. Dies führt zur folgenden Fehlermeldung. Die Fehlermeldung weist darauf hin, dass der GKE API-Server versucht hat, einen Admission-Webhook zu kontaktieren, als er versuchte, eine Ressource wiederherzustellen. Der Dienst, der den Webhook unterstützt, war jedoch entweder nicht verfügbar oder wurde nicht gefunden:

  resource [/example-group/ClusterSecretStore/example-store] restore failed:

  Internal error occurred: failed calling webhook "example-webhook.io":
  failed to call webhook: Post "https://example-webhook.example-namespace.svc:443/validate-example": service "example-webhook" not found.

Dieser Fehler tritt auf, wenn eine GKE-Ressource vom Typ ValidatingAdmissionWebhook oder MutatingAdmissionWebhook im Zielcluster aktiv ist, der GKE API-Server jedoch den im Webhook konfigurierten Endpunkt nicht erreichen kann. Zulassungs-Webhooks fangen Anfragen an den GKE API-Server ab. In ihrer Konfiguration wird festgelegt, wie der GKE API-Server die Anfragen abfragen soll.

Der clientConfig des Webhooks gibt das Backend an, das die Zulassungsanfragen verarbeitet. Das kann ein interner Clusterdienst oder eine externe URL sein. Die Wahl zwischen diesen beiden Optionen hängt von den spezifischen Betriebs- und Architekturanforderungen Ihres Webhooks ab. Je nach Optionstyp ist der Wiederherstellungsvorgang möglicherweise aus den folgenden Gründen fehlgeschlagen:

  • In-Cluster-Dienste: Der GKE-Dienst und die zugehörigen Pods werden nicht wiederhergestellt oder sind nicht bereit, wenn der GKE API-Server versucht, den Webhook aufzurufen. Dies geschieht bei Wiederherstellungsvorgängen, bei denen Webhook-Konfigurationen auf Clusterebene angewendet werden, bevor die Namespace-bezogenen Dienste vollständig den Status ready erreicht haben.

  • Externe URLs: Der externe Endpunkt ist aufgrund von Problemen mit der Netzwerkverbindung zwischen dem GKE-Cluster und dem externen Endpunkt, Problemen mit der DNS-Auflösung oder Firewallregeln vorübergehend nicht verfügbar.

So beheben Sie diesen Fehler:

  1. Identifizieren Sie den fehlgeschlagenen Webhook, der in der Fehlermeldung erwähnt wird. Beispiel: failed calling webhook "..."

  2. Prüfen Sie den Webhook mit dem Befehl kubectl get validatingwebhookconfigurations:

    kubectl get validatingwebhookconfigurations WEBHOOK_NAME -o yaml

    Ersetzen Sie WEBHOOK_NAME durch den Namen des Webhooks, der in der Fehlermeldung angegeben ist.

    Sie können auch den Befehl kubectl get mutatingwebhookconfigurations ausführen, um den Webhook zu prüfen:

    kubectl get mutatingwebhookconfigurations WEBHOOK_NAME -o yaml

    Ersetzen Sie WEBHOOK_NAME durch den Namen des Webhooks, der in der Fehlermeldung angegeben wurde.

  3. Führen Sie je nach Konfigurationstyp die folgenden Schritte zur Fehlerbehebung aus:

    Dienstbasiert clientConfig

    Definieren Sie eine benutzerdefinierte Wiederherstellungsreihenfolge, indem Sie die Ressource RestorePlan so ändern, dass sie eine RestoreOrder mit GroupKindDependency-Einträgen enthält. Dadurch können die Komponenten, die den Webhook unterstützen, z. B. Deployment, StatefulSet oder Service, vor dem ValidatingWebhookConfiguration oder MutatingWebhookConfiguration wiederhergestellt und bereitgestellt werden.

    Eine Anleitung zum Definieren einer benutzerdefinierten Wiederherstellungsreihenfolge finden Sie unter Reihenfolge der Ressourcenwiederherstellung während der Wiederherstellung angeben.

    Dieser Ansatz kann fehlschlagen, weil die Pods des Dienstes auch nach dem Erstellen des Service-Objekts nicht in den Status ready wechseln. Ein weiterer Grund für einen Fehler könnte sein, dass die Webhook-Konfiguration unerwartet von einer anderen Anwendung erstellt wurde. Alternativ können Sie eine zweistufige Wiederherstellung mit den folgenden Schritten durchführen:

    1. Erstellen Sie eine Restore-Ressource mit dem Backup, indem Sie den Wiederherstellungsvorgang mit einem detaillierten Wiederherstellungsfilter konfigurieren, der die spezifischen Ressourcen enthält, die für die Funktion des Webhooks erforderlich sind, z. B. Namespaces, Deployments, StatefulSets oder Services.

      Weitere Informationen zum Konfigurieren der Wiederherstellung mit einem detaillierten Wiederherstellungsfilter finden Sie unter Detaillierte Wiederherstellung aktivieren.

    2. Erstellen Sie eine weitere Restore-Ressource für den Sicherungsvorgang und konfigurieren Sie die restlichen Ressourcen, die Sie auswählen.

    URL-basiert clientConfig

    1. Prüfen Sie den externen HTTPS-Endpunkt und stellen Sie sicher, dass er aktiv, erreichbar und funktionsfähig ist.

    2. Prüfen Sie, ob eine Netzwerkverbindung von den Knoten und der Steuerungsebene Ihres GKE-Clusters zur externen URL besteht. Möglicherweise müssen Sie auch Firewallregeln prüfen, z. B. wenn Sie Virtual Private Cloud, eine lokale Umgebung oder einen Cloud-Anbieter verwenden, der den Webhook, Netzwerkrichtlinien und die DNS-Auflösung hostet.

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

Fehler 200010302: Wiederherstellungsvorgang konnte nicht abgeschlossen werden, da die Anfrage zum Erstellen von Ressourcen abgelehnt wurde

Der Fehler 200010302 tritt auf, wenn ein Versuch, einen Wiederherstellungsvorgang abzuschließen, fehlschlägt, weil ein Zulassungs-Webhook eine Anfrage zum Erstellen einer Ressource ablehnt. Dies führt zu der folgenden Fehlermeldung, die angibt, dass eine Ressource aus Ihrem Backup nicht im Zielcluster erstellt werden konnte, weil ein aktiver Zulassungs-Webhook die Anfrage abgefangen und auf Grundlage einer benutzerdefinierten Richtlinie abgelehnt hat:

  [KubeError]; e.g. resource

  [/example-namespace/example-api/ExampleResource/example-name]

  restore failed: admission webhook "example-webhook.example.com" denied the request: {reason for denial}

Dieser Fehler wird durch die Konfiguration im Ziel-GKE-Cluster verursacht, die entweder ValidatingAdmissionWebhook oder MutatingAdmissionWebhook enthält, wodurch bestimmte Regeln für das Erstellen und Ändern von Ressourcen erzwungen werden und die Anfrage zum Erstellen von Ressourcen blockiert wird. Ein Webhook verhindert beispielsweise die Erstellung einer Ressource, weil im Cluster bereits eine zugehörige, aber in Konflikt stehende Ressource vorhanden ist. Ein Webhook kann beispielsweise die Erstellung einer Bereitstellung ablehnen, wenn sie bereits von einer HorizontalPodAutoscaler-GKE API-Ressource verwaltet wird.

So beheben Sie diesen Fehler:

  1. Ermitteln Sie den Webhook, der die Anfrage ablehnt, anhand der Fehlermeldung, die beim Fehlschlagen des Wiederherstellungsvorgangs angezeigt wird. Beispiel: webhook WEBHOOK_NAME denied the request Die Fehlermeldung enthält die folgenden Informationen:

    • Webhook-Name: Der Name des Webhooks, der die Anfrage ablehnt.

    • Grund für Ablehnung: Der genaue Grund für die Ablehnung des Antrags.

  2. Prüfen Sie den Webhook mit dem Befehl kubectl get validatingwebhookconfigurations:

    kubectl get validatingwebhookconfigurations WEBHOOK_NAME -o yaml

    Ersetzen Sie WEBHOOK_NAME durch den Namen des Webhooks, den Sie in der Fehlermeldung gefunden haben.

    Sie können auch den Befehl kubectl get mutatingwebhookconfigurations ausführen, um den Webhook zu prüfen:

    kubectl get mutatingwebhookconfigurations WEBHOOK_NAME -o yaml

    Ersetzen Sie WEBHOOK_NAME durch den Namen des Webhooks, den Sie in der Fehlermeldung gefunden haben.

  3. Beheben Sie das zugrunde liegende Problem im Zielcluster. Die richtige Maßnahme hängt vom jeweiligen Fehler ab. Wenn im Beispiel ein HorizontalPodAutoscaler-Konflikt auftritt, müssen Sie das vorhandene HorizontalPodAutoscaler im Zielcluster löschen, bevor Sie die Wiederherstellung ausführen, damit die gesicherten Arbeitslasten und die zugehörigen Ressourcen erstellt werden können.

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

Fehler 200060202: Wiederherstellungsvorgang konnte nicht abgeschlossen werden, da bei der Arbeitslastvalidierung eine GKE-Ressource gefehlt hat

Der Fehler 200060202 tritt während der Phase der Arbeitslastvalidierung eines Wiederherstellungsvorgangs auf, wenn eine GKE-Ressource, die von Sicherung für GKE zur Validierung erwartet wird, im Zielcluster nicht gefunden werden kann. Dies führt zur folgenden Fehlermeldung:

  Workload Validation Error: [KIND] "[NAME]" not found

Beispiel: Example: Workload Validation Error: pods "jenkins-0" not found

Dieser Fehler tritt auf, wenn Sicherung für GKE die GKE-Ressource im Rahmen des Wiederherstellungsvorgangs erfolgreich erstellt oder aktualisiert, aber zu Beginn der Validierungsphase eine oder mehrere der GKE-Ressourcen nicht mehr im Zielcluster vorhanden sind, weil die Ressource nach dem Erstellen oder Aktualisieren durch den Wiederherstellungsvorgang, aber vor Abschluss der Arbeitslastvalidierung für die GKE-Ressource gelöscht wurde. Ein solcher Fehler kann folgende Ursachen haben:

  • Manuelles Löschen: Ein Nutzer oder Administrator hat die Ressource manuell mit kubectl oder anderen Google Cloud -Tools gelöscht.

  • Externe Automatisierung: GitOps-Controller wie Config Sync, ArgoCD, Flux, benutzerdefinierte Skripts oder andere Cluster-Managementtools haben die Ressource zurückgesetzt oder gelöscht, um einen gewünschten Zustand in einem Repository zu erreichen.

  • GKE-Controller: Ein GKE-Controller hat eine Ressource gelöscht, weil sie mit anderen Ressourcen oder Richtlinien in Konflikt steht, oder eine OwnerReference-Kette führt zur automatischen Speicherbereinigung oder zum automatischen Bereinigungsprozess von GKE, bei dem abhängige Ressourcen gelöscht werden, wenn ihre owner-Ressource gelöscht wird.

So beheben Sie diesen Fehler:

  1. Ermitteln Sie die fehlende Ressource anhand der Fehlermeldung, die angezeigt wird, wenn der Wiederherstellungsvorgang nicht abgeschlossen werden kann.

  2. Suchen Sie den Namespace, zu dem die Ressource gehört, mit einer der folgenden Methoden:

    • GKE-Audit-Logs: Prüfen Sie die GKE-Audit-Logs, die beim Versuch des Wiederherstellungsvorgangs generiert wurden. Sie können Logs für Löschvorgänge für die Ressourcen Kind und Name filtern. Der Audit-Logeintrag enthält den ursprünglichen Namespace.

    • Sicherungsdetails: Hier können Sie den Umfang des Wiederherstellungsvorgangs und den Inhalt der Sicherung prüfen. Der Sicherungsindex enthält den ursprünglichen Namespace der Ressource. Sie können auch prüfen, ob das RestorePlan ein TransformationRule enthält, in dem Regeln zum Wiederherstellen der Ressource im ausgewählten Namespace angegeben sind.

    • Namespaceübergreifend suchen: Führen Sie den Befehl kubectl get aus, um die Ressource in allen Namespaces zu suchen:

      kubectl get KIND --all-namespaces | grep NAME

      Ersetzen Sie KIND und NAME durch die Werte aus der Fehlermeldung. Wenn die Ressource noch vorhanden ist, wird mit diesem Befehl ihr Namespace angezeigt.

  3. Prüfen Sie, ob die Datei gelöscht wurde, indem Sie den Befehl kubectl get ausführen:

    kubectl get KIND NAME -n [NAMESPACE]

    Ersetzen Sie KIND und NAME durch die Werte aus der Fehlermeldung. Sie sollten die Fehlermeldung not found erhalten.

  4. Ermitteln Sie die Ursache für das Löschen mit einer der folgenden Methoden:

    • GKE-Audit-Logs: Hier können Sie ermitteln, welche Entität die Löschanfrage gestellt hat. Beispiel: Nutzer, Dienstkonto oder Controller.

    • Konfigurierte Automatisierungen prüfen: Wenn Sie GitOps oder andere Automatisierungstools verwenden, prüfen Sie deren Logs und Status, um festzustellen, ob sie die wiederhergestellten Ressourcen beeinträchtigt haben.

    • Zugehörige Ereignisse untersuchen: Prüfen Sie GKE-Ereignisse im ermittelten Namespace, indem Sie den Befehl kubectl get events ausführen:

      kubectl get events -n NAMESPACE_NAME --sort-by='.lastTimestamp'

      Ersetzen Sie NAMESPACE_NAME durch den Namen des Namespace.

  5. Beheben Sie die Ursache für das Löschen der Ressource anhand der Ergebnisse des vorherigen Schritts. Sie können beispielsweise in Konflikt stehende Automatisierungen pausieren, Fehlkonfigurationen korrigieren oder Nutzerberechtigungen anpassen.

  6. Stellen Sie die fehlende Ressource mit einer der folgenden Methoden wieder her:

    • Manifestdateien noch einmal anwenden: Wenn Sie das Manifest für die fehlende Ressource haben, können Sie es noch einmal auf den richtigen Namespace anwenden.

    • Detaillierte Wiederherstellung durchführen: Führen Sie eine detaillierte Wiederherstellung durch, um nur die fehlende Ressource aus derselben Sicherung wiederherzustellen. So stellen Sie sicher, dass Sie den richtigen Namespace angeben. Weitere Informationen zum Ausführen einer detaillierten Wiederherstellung finden Sie unter Detaillierte Wiederherstellung aktivieren.

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

Fehler 200060201: Fehler beim Abschließen des Wiederherstellungsvorgangs aufgrund von Zeitüberschreitung bei der Arbeitslastvalidierung

Der Fehler 200060201 tritt auf, wenn eine oder mehrere wiederhergestellte Arbeitslasten während eines Wiederherstellungsvorgangs innerhalb des erwarteten Zeitlimits nach dem Erstellen der Ressourcen im Cluster nicht vollständig ready werden. Dies führt zu folgender Fehlermeldung:

Workload Validation Error: Timedout waiting for workloads to be ready - [namespace/workload_name, ...]

Dieser Fehler tritt auf, weil Sicherung für GKE nach dem Wiederherstellen von GKE-Ressourcenkonfigurationen einen Validierungsschritt ausführt, um sicherzustellen, dass kritische Arbeitslasten ordnungsgemäß funktionieren. Sicherung für GKE wartet, bis bestimmte Arbeitslasten den Status ready erreichen. Mindestens eine Arbeitslast hat das folgende Bereitschaftskriterium jedoch nicht innerhalb des zugewiesenen Zeitlimits erfüllt:

  • Für Pods: status.Phase ist Running

  • Für Deployments: status.ReadyReplicas = spec.Replicas

  • Für StatefulSets: status.ReadyReplicas = spec.Replicas

  • Für DaemonSets: status.NumberReady = status.DesiredNumberScheduled

So beheben Sie diesen Fehler:

  1. Identifizieren Sie die Arbeitslasten, die sich nicht im Status ready befinden. Die Fehlermeldung enthält eine Liste der Arbeitslasten und ihrer Namespaces, die nicht in den Status ready wechseln konnten.

  2. Mit dem Befehl kubectl describe können Sie den Status der Arbeitslasten prüfen und Details und Ereignisse für die fehlgeschlagenen Arbeitslasten abrufen:

    kubectl describe WORKLOAD_TYPE WORKLOAD_NAME -n NAMESPACE_NAME
kubectl get pods -n NAMESPACE_NAME -l SELECTOR_FOR_WORKLOAD

    Ersetzen Sie Folgendes:

    • WORKLOAD_TYPE: der Typ der Arbeitslast, z. B. Deployment, StatefulSet oder DaemonSet.

    • WORKLOAD_NAME: der Name der spezifischen Arbeitslastinstanz.

    • NAMESPACE_NAME: der Namespace, in dem sich die Arbeitslast befindet.

    • SELECTOR_FOR_WORKLOAD: die Labelauswahl, um die mit der Arbeitslast verknüpfte Pods zu finden. Beispiel: app=my-app

    Prüfen Sie für Pods in den Arbeitslasttypen Deployments oder StatefulSets den Status einzelner Pods, indem Sie den Befehl kubectl describe pod ausführen:

    kubectl describe pod POD_NAME -n NAMESPACE_NAME

    Ersetzen Sie Folgendes:

    • POD_NAME: der Name des jeweiligen Pods.

    • NAMESPACE_NAME: der Namespace, in dem sich der Pod befindet.

  3. Analysieren Sie im Abschnitt Events Ereignisse und Logs in der Ausgabe von describe und suchen Sie nach den folgenden Informationen:

    • ImagePullBackOff / ErrImagePull: Gibt an, dass beim Abrufen von Container-Images Probleme aufgetreten sind.

    • CrashLoopBackOff: Gibt an, dass Container gestartet werden und abstürzen.

  4. Analysieren Sie im Abschnitt Containers die Containerlogs in der describe-Ausgabe, um den Containernamen zu ermitteln. Führen Sie dazu den Befehl kubectl logs aus:

    kubectl logs POD_NAME -n NAMESPACE_NAME -c CONTAINER_NAME

    Ersetzen Sie Folgendes:

    • POD_NAME: der Name des jeweiligen Pods.

    • NAMESPACE_NAME: der Namespace, in dem sich der Pod befindet.

    • CONTAINER_NAME: der Name des Containers im Pod.

    Laut der describe-Ausgabe kann es mehrere Gründe dafür geben, dass der Pod nicht in der Ressourcenausgabe angezeigt wird. Dazu gehören:

    • Fehler bei Bereitschaftsprüfungen: Die Bereitschaftsprüfungen des Containers sind nicht erfolgreich.

    • Ressourcenprobleme: Es sind nicht genügend CPU, Arbeitsspeicher oder andere Ressourcen im Cluster vorhanden oder die Kontingentlimits wurden erreicht.

    • Probleme mit Init-Containern: Fehler in Init-Containern, die das Starten von Hauptcontainern verhindern.

    • Konfigurationsfehler: Fehler in ConfigMaps, Secrets oder Umgebungsvariablen.

    • Netzwerkprobleme: Pods kann nicht mit den erforderlichen Diensten kommunizieren.

  5. Prüfen Sie die GKE-Clusterressourcen, um sicherzustellen, dass der GKE-Cluster über genügend Knotenkapazität, CPU und Arbeitsspeicher verfügt, um die wiederhergestellten Arbeitslasten auszuführen. In Autopilot-Clustern kann die automatische Knotenbereitstellung zusätzliche Zeit in Anspruch nehmen. Daher empfehlen wir, nach Einschränkungen oder Fehlern bei der Knotenskalierung zu suchen. Beheben Sie die zugrunde liegenden Probleme anhand Ihrer Ergebnisse und beseitigen Sie die Probleme, die verhindern, dass die Arbeitslasten den Status ready erreichen. Dazu kann es erforderlich sein, Manifeste zu korrigieren, Ressourcenanfragen oder ‑limits anzupassen, Netzwerkrichtlinien zu korrigieren oder dafür zu sorgen, dass Abhängigkeiten erfüllt werden.

  6. Nachdem die zugrunde liegenden Probleme behoben wurden, warten Sie, bis die Arbeitslasten den Status ready erreichen. Sie müssen den Wiederherstellungsvorgang nicht noch einmal ausführen.

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

Fehler 200060102: Wiederherstellungsvorgang konnte aufgrund eines Volume-Validierungsfehlers nicht abgeschlossen werden

Der Fehler 200060102 tritt auf, weil eine oder mehrere VolumeRestore-Ressourcen, die den Prozess der Wiederherstellung von Daten aus VolumeBackup in ein PersistentVolume verwalten, während der Phase der Volume-Validierung eines Wiederherstellungsvorgangs den Status failed oder deleting erreicht haben. Die fehlgeschlagene Volume-Wiederherstellung führt zu der folgenden Fehlermeldung im Feld „stateReason“ der Wiederherstellungsressource:

Volume Validation Error: Some of the volume restores failed - [projects/PROJECT_ID/locations/LOCATION/restorePlans/RESTORE_PLAN_ID/restores/RESTORE_ID/volumeRestores/VOLUME_RESTORE_ID (PVC: NAMESPACE/PVC_NAME), ...]

In der Fehlermeldung werden die vollständigen Ressourcennamen der fehlgeschlagenen VolumeRestore aufgeführt, einschließlich des Namens und Namespace des Ziel-PersistentVolumeClaim. Die Fehlermeldung gibt an, dass die Datenwiederherstellung für die betroffene PersistentVolumeClaim nicht erfolgreich abgeschlossen wurde, als Sicherung für GKE VolumeRestore-Ressourcen zum Bereitstellen von PersistentVolumes aus VolumeBackups initiiert hat und die zugrunde liegende Erstellung der Persistent Disk aus dem Snapshot fehlgeschlagen ist. VolumeRestore-Fehler können aus folgenden Gründen auftreten:

  • Unzureichendes Kontingent: Im Projekt oder in der Region ist nicht genügend Kontingent für nichtflüchtige Speicher zugewiesen, z. B. SSD_TOTAL_GB.

  • Berechtigungsprobleme: Das von Sicherung für GKE verwendete Dienstkonto hat nicht die erforderlichen Berechtigungen zum Erstellen von Laufwerken oder zum Zugriff auf Snapshots.

  • Netzwerkprobleme: Es gibt vorübergehende oder dauerhafte Netzwerkprobleme, die den Prozess der Laufwerkerstellung unterbrechen.

  • Ungültiger Snapshot: Die Quelle VolumeBackup oder der zugrunde liegende Persistent Disk-Snapshot ist beschädigt oder nicht zugänglich.

  • Ressourceneinschränkungen: Andere Clusterressourceneinschränkungen verhindern die Bereitstellung von Volumes.

  • Interne Fehler: Es gibt interne Probleme im Persistent Disk-Dienst.

So beheben Sie diesen Fehler:

  1. Suchen Sie in der Fehlermeldung nach dem fehlgeschlagenen PersistentVolumeClaims. Dort sind die vollständigen Ressourcennamen der fehlgeschlagenen VolumeRestore-Objekte aufgeführt.

  2. Rufen Sie Details zu jeder fehlgeschlagenen VolumeRestore-Ressource ab, indem Sie den Befehl gcloud beta container backup-restore volume-restores describe ausführen:

    gcloud beta container backup-restore volume-restores describe VOLUME_RESTORE_ID \
--project=PROJECT_ID \
--location=LOCATION \
--restore-plan=RESTORE_PLAN_ID \
--restore=RESTORE_ID

    Ersetzen Sie Folgendes:

    • VOLUME_RESTORE_ID: die ID der fehlgeschlagenen VolumeRestore-Ressource.

    • PROJECT_ID: die ID Ihres Projekts in Google Cloud .

    • LOCATION: Der Google Cloud -Standort der Wiederherstellung.

    • RESTORE_PLAN_ID: die ID des Wiederherstellungsplans.

    • RESTORE_ID: die ID des Wiederherstellungsvorgangs.

  3. Sehen Sie sich die Felder state und stateMessage in der Ausgabe an, um Details zum Fehler zu erhalten.

  4. Prüfen Sie den Status des Ziels PersistentVolumeClaim mit dem Befehl kubectl get pvc:

    kubectl get pvc PVC_NAME -n NAMESPACE_NAME -o yaml

    Ersetzen Sie Folgendes:

    • PVC_NAME: der Name der PersistentVolumeClaim-Ressource.

    • NAMESPACE_NAME: der Namespace, in dem sich die PersistentVolumeClaim befindet.

  5. Prüfen Sie, ob im Abschnitt status.phase der Ausgabe eine Pending-Phase angegeben ist. Diese Phase bedeutet, dass der PersistentVolumeClaim noch nicht an ein PersistentVolume gebunden ist. Das ist zu erwarten, wenn der VolumeRestore fehlschlägt.

  6. Sehen Sie im Abschnitt Events der YAML-Ausgabe nach, ob Meldungen zu Bereitstellungsfehlern wie ProvisioningFailed vorhanden sind. Beispiel:

    Cloud KMS error when using key projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/CRYPTO_KEY:  Permission 'cloudkms.cryptoKeyVersions.useToEncrypt' denied  on resource 'projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/CRYPTO_KEY' (or it may not exist).

    Die Ausgabe weist darauf hin, dass beim Zugriff auf den Verschlüsselungsschlüssel während der Erstellung des Laufwerks ein Berechtigungsproblem aufgetreten ist. compute service agentUm die entsprechende Berechtigung für den Zugriff auf den Schlüssel zu erteilen, folgen Sie der Anleitung in der Sicherung für GKE-Dokumentation zum Aktivieren der CMEK-Verschlüsselung.

  7. Sehen Sie sich die GKE-Ereignisse im Namespace PersistentVolumeClaim an. Sie enthalten detaillierte Fehlermeldungen vom PersistentVolume-Controller oder CSI-Treiber. Führen Sie dazu den Befehl kubectl get events aus:

    kubectl get events -n NAMESPACE_NAME --sort-by='.lastTimestamp'

    Ersetzen Sie NAMESPACE_NAME durch den Namespace des PersistentVolumeClaim.

  8. Suchen Sie nach Ereignissen, die mit dem Namen PersistentVolumeClaim zusammenhängen und Keywords wie FailedProvisioning oder ExternalProvisioning enthalten. Die Ereignisse können auch Fehler des Speicherbereitstellers enthalten, z. B. pd.csi.storage.gke.io.

  9. Prüfen Sie die Persistent Disk-Logs auf Fehler im Zusammenhang mit der Erstellung von Laufwerken zum Zeitpunkt des Fehlers. Suchen Sie dazu in Cloud Logging nach Cloud-Audit-Logs und Persistent Disk-Logs.

  10. Beheben Sie die folgenden zugrunde liegenden Probleme basierend auf den generierten Fehlermeldungen:

    • Erhöhen Sie die Kontingente für nichtflüchtige Speicher, wenn dies angegeben ist, z. B. (QUOTA_EXCEEDED}: Quota SSD_TOTAL_GB exceeded.

    • IAM-Berechtigungen prüfen und korrigieren

    • Netzwerkprobleme untersuchen und beheben

    • Wenden Sie sich an Cloud Customer Care, um Probleme mit dem Snapshot oder dem Persistent Disk-Dienst zu beheben.

    • Die PersistentVolumeClaim bleibt im Status Pending.

    • Beim Wiederherstellungsvorgang wird die VolumeRestore nicht automatisch noch einmal versucht. Um dieses Problem zu beheben, sollten Sie einen Wiederherstellungsvorgang für die Deployment- oder StatefulSet-Arbeitslast auslösen, die die betroffene PersistentVolumeClaim verwendet.

    • Verwenden Sie eine detaillierte Wiederherstellung, um die Deployment- oder StatefulSet-Arbeitslast wiederherzustellen, die mit dem fehlgeschlagenen PersistentVolumeClaim verknüpft ist. Bei diesem Ansatz können die Standard-GKE-Mechanismen den Prozess zum Erstellen und Binden von PersistentVolumeClaim wieder übernehmen, wenn das zugrunde liegende Problem behoben ist. Weitere Informationen zur detaillierten Wiederherstellung finden Sie unter Detaillierte Wiederherstellung aktivieren.

Wenn das Problem weiterhin besteht oder die Ursache des VolumeRestore-Fehlers unklar ist, wenden Sie sich an Cloud Customer Care.

Fehler 200060101: Wiederherstellungsvorgang konnte aufgrund eines Zeitüberschreitungsfehlers bei der Volume-Validierung nicht abgeschlossen werden

Der Fehler 200060101 tritt während der Volume-Validierungsphase eines Wiederherstellungsvorgangs auf, wenn Sicherung für GKE das Warten beendet, weil mindestens eine VolumeRestore-Ressource, die die Wiederherstellung von Daten aus einem VolumeBackup verwaltet, den Status succeeded nicht innerhalb des zugewiesenen Zeitlimits erreicht hat. Auch andere VolumeRestore-Ressourcen sind möglicherweise unvollständig.

Die Fehlermeldung im Feld stateReason der Ressource Restore enthält die Liste der VolumeRestore-Ressourcen, die beim Prüfen des Zeitlimits noch nicht den Status succeeded hatten. Sie enthält den Namen und Namespace des Ziels PersistentVolumeClaim für diese VolumeRestore-Ressourcen, z. B.:

Volume Validation Error: Timed out waiting for volume restore [projects/PROJECT_ID/locations/LOCATION/restorePlans/RESTORE_PLAN_NAME/restores/RESTORE_NAME/volumeRestores/VOLUME_RESTORE_ID (PVC: PVC_NAMESPACE/PVC_NAME), ...]

Wenn außerdem Volume-Wiederherstellungen fehlgeschlagen sind, enthält die Fehlermeldung diese Fehler, z. B.:

Volume Validation Error: Timed out waiting for volume restore [projects/PROJECT_ID/locations/LOCATION/restorePlans/RESTORE_PLAN_NAME/restores/RESTORE_NAME/volumeRestores/VOLUME_RESTORE_ID (PVC: PVC_NAMESPACE/PVC_NAME), ...] and some of the volume restores failed - [projects/PROJECT_ID/locations/LOCATION/restorePlans/RESTORE_PLAN_ID/restores/RESTORE_ID/volumeRestores/VOLUME_RESTORE_ID (PVC: NAMESPACE/PVC_NAME), ...]

Sicherung für GKE initiiert VolumeRestore-Ressourcen, um PersistentVolumes aus VolumeBackups bereitzustellen. Der Fehler weist darauf hin, dass die zugrunde liegende Erstellung des nichtflüchtigen Speichers aus dem Snapshot und die anschließende Bindung von PersistentVolumeClaim an PersistentVolume länger gedauert haben als das berechnete Zeitlimit für die angegebene VolumeRestores. Andere VolumeRestores für denselben Wiederherstellungsvorgang befinden sich möglicherweise auch in einem nicht abgeschlossenen Zustand.

Auch wenn die Zeitüberschreitung aus Sicht von Sicherung für GKE erreicht wurde, kann der zugrunde liegende Laufwerkserstellungsprozess für die genannte VolumeRestore-Ressource und möglicherweise für VolumeRestore-Ressourcen noch laufen oder fehlgeschlagen sein.

So beheben Sie das Problem:

  1. Suchen Sie in der Fehlermeldung nach dem Namen und Namespace des Zeitüberschreitungs-PersistentVolumeClaim, z. B. (PVC: PVC_NAMESPACE/PVC_NAME).

  2. Listen Sie alle VolumeRestores auf, die mit dem Wiederherstellungsvorgang verknüpft sind, um ihren aktuellen Status zu sehen. Führen Sie dazu den Befehl gcloud beta container backup-restore volume-restores list aus:

    gcloud beta container backup-restore volume-restores list \
--project=PROJECT_ID \
--location=LOCATION \
--restore-plan=RESTORE_PLAN_NAME \
--restore=RESTORE_NAME

    Ersetzen Sie Folgendes:

    • PROJECT_ID: die ID des Google Cloud -Projekts.

    • LOCATION: der Google Cloud -Standort der Wiederherstellung.

    • RESTORE_PLAN_NAME: der Name des Wiederherstellungsplans.

    • RESTORE_NAME: der Name des Wiederherstellungsvorgangs.

  3. Suchen Sie nach VolumeRestores, die sich nicht im Status succeeded befinden.

  4. Wenn sich Volumes im Status failed befinden, müssen Sie Schritte zur Fehlerbehebung ausführen, um den Fehler bei der Volume-Validierung zu beheben. Weitere Informationen finden Sie unter Fehler 200060102: Wiederherstellungsvorgang konnte aufgrund eines Volume-Validierungsfehlers nicht abgeschlossen werden. Wenn Volumes fehlgeschlagen sind, werden sie im zweiten Teil der Fehlermeldung aufgeführt.

  5. Rufen Sie mit dem Befehl gcloud beta container backup-restore volume-restores describe Details zum VolumeRestore ab, der im Fehler erwähnt wird, und zu allen anderen VolumeRestores, die sich nicht im Status succeeded befinden:

    gcloud beta container backup-restore volume-restores describe VOLUME_RESTORE_ID \
--project=PROJECT_ID \
--location=LOCATION \
--restore-plan=RESTORE_PLAN_NAME \
--restore=RESTORE_NAME

    Ersetzen Sie Folgendes:

    • VOLUME_RESTORE_ID: die ID der VolumeRestore-Ressource.

    • PROJECT_ID: die ID Ihres Projekts in Google Cloud .

    • LOCATION: Der Google Cloud -Standort der Wiederherstellung.

    • RESTORE_PLAN_NAME: der Name des Wiederherstellungsplans.

    • RESTORE_NAME: der Name des Wiederherstellungsvorgangs.

  6. Prüfen Sie die Felder state und stateMessage. Der Wert des Felds state ist wahrscheinlich creating oder restoring. Das Feld stateMessage bietet möglicherweise mehr Kontext und enthält die Details zum Ziel-PersistentVolumeClaim.

  7. Prüfen Sie den Status des identifizierten Ziels PersistentVolumeClaims, indem Sie den Befehl kubectl get pvc ausführen:

    kubectl get pvc PVC_NAME -n PVC_NAMESPACE -o yaml

    Ersetzen Sie Folgendes:

    • PVC_NAME ist der Name des PersistentVolumeClaim.

    • PVC_NAMESPACE: der Namespace des PersistentVolumeClaim.

    Der Wert von PersistentVolumeClaim's status.phase liegt wahrscheinlich bei Pending. Prüfen Sie den Abschnitt Events auf die folgenden Fehler:

    • Waiting for first consumer to be created before binding: Gibt an, dass die StorageClass volumeBindingMode: WaitForFirstConsumer hat.

      Die Bereitstellung des PersistentVolume wird verzögert, bis ein Pod, der den PersistentVolumeClaim verwendet, erstellt und geplant wird. Das Problem liegt möglicherweise an der Pod-Planung und nicht an der Bereitstellung des Volumes selbst. Daher empfehlen wir, zu prüfen, warum die Pods, die die PersistentVolumeClaim verbrauchen, nicht geplant oder nicht gestartet werden.

    • FailedProvisioning oder Fehler vom Speicherbereitsteller: Zum Beispiel pd.csi.storage.gke.io.

  8. Prüfen Sie GKE-Ereignisse in den relevanten Namespaces, indem Sie den Befehl kubectl get events ausführen:

    kubectl get events -n PVC_NAMESPACE --sort-by='.lastTimestamp'

    Ersetzen Sie PVC_NAMESPACE durch den Namespace des PersistentVolumeClaim.

    Suchen Sie nach Ereignissen, die mit den PersistentVolumeClaim-Namen zusammenhängen, z. B. Bereitstellungsmeldungen oder ‑fehler.

  9. Prüfen Sie die Cloud-Audit-Logs und Persistent Disk-Logs in Cloud Logging.

  10. Überwachen Sie den Status aller VolumeRestores im Status creating und restoring.

    Nachdem das Problem behoben wurde, kann der Status von VolumeRestores in succeeded oder failed geändert werden. Wenn die VolumeRestores den Status succeeded erreichen, sollte die PersistentVolumeClaims den Status Bound annehmen und die Arbeitslasten sollten funktionieren. Wenn ein VolumeRestore in den Status failed wechselt, müssen Sie Schritte zur Fehlerbehebung ausführen, um den Fehler bei der Lautstärkevalidierung zu beheben. Weitere Informationen finden Sie unter Fehler 200060102: Wiederherstellungsvorgang konnte aufgrund eines Volume-Validierungsfehlers nicht abgeschlossen werden.

Wenn VolumeRestores für einen längeren Zeitraum im Status creating oder restoring verbleiben, wenden Sie sich an Cloud Customer Care.

Nächste Schritte