Berechtigungsfehler in Sicherung für GKE beheben

In diesem Dokument werden die Fehler und entsprechenden Codes beschrieben, die bei der Verwendung von Sicherung für GKE für Wiederherstellungsvorgänge auftreten können. In jedem Abschnitt finden Sie Hinweise dazu, was 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 Zulassungs-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 ValidatingAdmissionWebhook- oder MutatingAdmissionWebhook-GKE-Ressource 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 angegeben, wie der GKE API-Server die Anfragen abfragen soll.

Im clientConfig des Webhooks wird das Backend angegeben, 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 betrieblichen und architektonischen Anforderungen Ihres Webhooks ab. Je nach Optionstyp kann der Wiederherstellungsvorgang aus folgenden Gründen fehlgeschlagen sein:

  • In-Cluster-Dienste: Der GKE-Dienst und die zugehörigen Pods wurden nicht wiederhergestellt oder sind nicht bereit, als der GKE API-Server versucht hat, den Webhook aufzurufen. Dies geschieht bei Wiederherstellungsvorgängen, bei denen Webhook-Konfigurationen auf Clusterebene angewendet werden, bevor die Namespaces-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 oder aufgrund von Problemen mit der DNS-Auflösung oder Firewallregeln vorübergehend nicht verfügbar.

So beheben Sie diesen Fehler:

  1. Ermitteln 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 wurde.

    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 die folgenden Schritte zur Fehlerbehebung entsprechend Ihrer Konfiguration aus:

    Dienstbasiert clientConfig

    Sie können eine benutzerdefinierte Wiederherstellungsreihenfolge definieren, indem Sie die RestorePlan-Ressource so ändern, dass sie ein RestoreOrder mit GroupKindDependency-Einträgen enthält. So können die Komponenten, die den Webhook unterstützen, z. B. Deployment, StatefulSet oder Service, wiederhergestellt und bereit sein, bevor ValidatingWebhookConfiguration oder MutatingWebhookConfiguration.

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

    Dieser Ansatz kann fehlschlagen, da die Pods des Dienstes auch nach der Erstellung des Service-Objekts nicht in den Status ready wechseln. Ein weiterer Grund für den 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 sorgen Sie dafür, 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, lokale oder einen Cloud-Anbieter verwenden, der den Webhook hostet, Netzwerkrichtlinien und DNS-Auflösung.

  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 eine ValidatingAdmissionWebhook oder MutatingAdmissionWebhook enthält, die bestimmte Regeln für die Ressourcenerstellung und -änderung erzwingt und die Anfrage zur Ressourcenerstellung blockiert. Ein Webhook verhindert beispielsweise die Erstellung einer Ressource, weil eine zugehörige, aber in Konflikt stehende Ressource bereits im Cluster 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 die 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 angegeben 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 es im Beispiel einen HorizontalPodAutoscaler-Konflikt gibt, müssen Sie den vorhandenen 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: Fehler beim Wiederherstellungsvorgang aufgrund einer fehlenden GKE-Ressource während der Arbeitslastvalidierung

Der Fehler 200060202 tritt während der Arbeitslastvalidierungsphase 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 wenn die Validierungsphase beginnt, ist eine oder mehrere der GKE-Ressourcen nicht mehr im Zielcluster vorhanden, da die Ressource gelöscht wurde, nachdem sie ursprünglich vom Wiederherstellungsvorgang erstellt oder aktualisiert wurde, aber bevor die Arbeitslastvalidierung für die GKE-Ressource abgeschlossen werden konnte. 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 Clusterverwaltungstools haben die Ressource zurückgesetzt oder gelöscht, um einem gewünschten Status in einem Repository zu entsprechen.

  • 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 zu Garbage Collection oder der automatische Bereinigungsprozess von GKE löscht abhängige Ressourcen, 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: Untersuchen Sie die GKE-Audit-Logs, die beim Versuch, den Wiederherstellungsvorgang auszuführen, 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.

    • Back-up-Details: Hier können Sie den Umfang des Wiederherstellungsvorgangs und den Inhalt des Back-ups ansehen. Der Sicherungsindex enthält den ursprünglichen Namespace der Ressource. Sie können auch prüfen, ob RestorePlan eine TransformationRule enthält, in der 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 Löschung erfolgt ist, 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 wird angegeben, welche Entität die Löschanfrage gestellt hat. Das kann beispielsweise der Nutzer, das Dienstkonto oder der Controller sein.

    • Konfigurierte Automatisierungen überprü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. Beispielsweise können Sie 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 einen detaillierten Wiederherstellungsvorgang durch, um nur die fehlende Ressource aus derselben Sicherung selektiv wiederherzustellen. So stellen Sie sicher, dass Sie den richtigen Namespace angeben. Weitere Informationen zum Ausführen eines detaillierten Wiederherstellungsvorgangs 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: Wiederherstellungsvorgang konnte aufgrund eines Zeitüberschreitungsfehlers bei der Arbeitslastvalidierung nicht abgeschlossen werden

Der Fehler 200060201 tritt auf, wenn eine oder mehrere wiederhergestellte Arbeitslasten während eines Wiederherstellungsvorgangs innerhalb des erwarteten Zeitlimits nach der Erstellung der Ressourcen im Cluster nicht vollständig ready werden. Dies führt zur folgenden 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. Ermitteln Sie die Arbeitslasten, die sich nicht im Status ready befinden, anhand der Fehlermeldung, in der die Arbeitslasten und ihre Namespaces aufgeführt sind, die nicht in den Status ready wechseln konnten.

  2. Mit dem Befehl kubectl describe können Sie den Status von 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 zum Suchen von Pods, die mit der Arbeitslast verknüpft sind. 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 Protokolle in der describe-Ausgabe 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: Im Cluster sind nicht genügend CPU, Arbeitsspeicher oder andere Ressourcen verfügbar oder es werden Kontingentlimits erreicht.

    • Probleme mit Init-Containern: Fehler in Init-Containern, die verhindern, dass Hauptcontainer gestartet werden.

    • 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. Wir empfehlen daher, 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 eine PersistentVolume verwalten, während der Phase der Volume-Validierung eines Wiederherstellungsvorgangs den Status failed oder deleting erreicht haben. Die fehlgeschlagene Wiederherstellung des Volumes 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 sind die vollständigen Ressourcennamen der fehlgeschlagenen VolumeRestore aufgeführt, einschließlich des Namens und Namespace des Ziels 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: Dem vom Sicherung für GKE verwendeten Dienstkonto fehlen die erforderlichen Berechtigungen zum Erstellen von Laufwerken oder zum Zugriff auf Snapshots.

  • Netzwerkprobleme: Es gibt vorübergehende oder dauerhafte Netzwerkprobleme, die den Prozess der Speichererstellung 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 behindern die Bereitstellung von Volumes.

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

So beheben Sie diesen Fehler:

  1. Ermitteln Sie den fehlgeschlagenen PersistentVolumeClaims, der in der Fehlermeldung aufgeführt ist. Dort finden Sie die vollständigen Ressourcennamen der fehlgeschlagenen VolumeRestore-Objekte.

  2. Rufen Sie Details zu jeder fehlgeschlagenen VolumeRestore-Ressource mit dem Befehl gcloud beta container backup-restore volume-restores describe ab:

    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 Google Cloud Projekts.

    • 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 das PersistentVolumeClaim befindet.

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

  6. Sehen Sie im YAML-Output im Abschnitt Events nach, ob Nachrichten zu Bereitstellungsfehlern vorhanden sind, z. B. ProvisioningFailed:

    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 Laufwerkerstellung ein Berechtigungsproblem aufgetreten ist. Um die compute service agent-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 vom Speicherbereitsteller enthalten, z. B. pd.csi.storage.gke.io.

  9. Prüfen Sie die Persistent Disk-Logs, indem Sie in Cloud Logging die Cloud-Audit-Logs und die Persistent Disk-Logs auf Fehler im Zusammenhang mit Vorgängen zur Erstellung von Laufwerken zum Zeitpunkt des Fehlers untersuchen.

  10. Beheben Sie anhand der generierten Fehlermeldungen die folgenden zugrunde liegenden Probleme:

    • Erhöhen Sie die Kontingente für nichtflüchtige Speicher, falls erforderlich, 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 wiederholt. Um dieses Problem zu beheben, sollten Sie einen Wiederherstellungsvorgang für den Deployment- oder StatefulSet-Arbeitslast auslösen, der das betroffene PersistentVolumeClaim verwendet.

    • Verwenden Sie eine detaillierte Wiederherstellung, um die mit dem fehlgeschlagenen PersistentVolumeClaim verknüpfte Arbeitslast Deployment oder StatefulSet selektiv wiederherzustellen. 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 für den VolumeRestore-Fehler 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, innerhalb des zugewiesenen Zeitlimits keinen succeeded-Status erreicht hat. Auch andere VolumeRestore-Ressourcen sind möglicherweise unvollständig.

Die Fehlermeldung im Feld stateReason der Restore-Ressource zeigt die erste VolumeRestore-Ressource, die beim Prüfen des Zeitlimits noch nicht im Status succeeded war. Es enthält den Namen und Namespace des Ziels PersistentVolumeClaim für das jeweilige VolumeRestore, 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)]

Sicherung für GKE initiiert die Bereitstellung von VolumeRestore-Ressourcen PersistentVolumes aus VolumeBackups. Der Fehler weist darauf hin, dass die Erstellung des zugrunde liegenden 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 VolumeRestore. Andere VolumeRestores für denselben Wiederherstellungsvorgang befinden sich möglicherweise auch in einem nicht abgeschlossenen Status.

Auch wenn das Zeitlimit aus Sicht von Sicherung für GKE erreicht wurde, kann der zugrunde liegende Prozess zum Erstellen von Festplatten für die erwähnte VolumeRestore-Ressource und möglicherweise auch für VolumeRestore-Ressourcen noch laufen oder fehlgeschlagen sein.

So beheben Sie das Problem:

  1. Ermitteln Sie in der Fehlermeldung den 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 nicht den Status succeeded haben.

  4. 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 Google Cloud Projekts.

    • LOCATION: der Google Cloud Standort der Wiederherstellung.

    • RESTORE_PLAN_NAME: der Name des Wiederherstellungsplans.

    • RESTORE_NAME: der Name des Wiederherstellungsvorgangs.

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

  6. Prüfen Sie den Status des ermittelten 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 ist wahrscheinlich 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 erstellt und geplant wird, das den PersistentVolumeClaim verwendet. Das Problem liegt möglicherweise an der Pod-Planung und nicht an der Bereitstellung des Volumes selbst. Daher empfehlen wir, herauszufinden, warum die Pods, die die PersistentVolumeClaim nutzen, nicht geplant oder gestartet werden.

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

  7. Sehen Sie sich GKE-Ereignisse in den relevanten Namespaces an, 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.

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

  9. Ü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 Bound werden 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 Volume-Validierung 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