Berechtigungsfehler in Backup for GKE beheben

In diesem Dokument werden die Fehler und entsprechenden Codes beschrieben, die bei der Verwendung von Sicherung für GKE zum Ausführen von Wiederherstellungsvorgängen 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 den im Webhook konfigurierten Endpunkt jedoch 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.

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 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 Namespaced-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 verwenden, 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 dem Erstellen 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 ValidatingAdmissionWebhook oder MutatingAdmissionWebhook enthält und bestimmte Regeln für die Ressourcenerstellung und -änderung erzwingt, wodurch die Anfrage zur Ressourcenerstellung blockiert wird. 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 verwenden, um den Webhook zu prüfen:

    kubectl get mutatingwebhookconfigurations WEBHOOK_NAME -o yaml

    Ersetzen Sie WEBHOOK_NAME durch den Namen des Webhooks, den Sie anhand der Fehlermeldung ermittelt 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 zur automatischen Bereinigung 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: Verwenden Sie den Befehl kubectl get, 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 das Löschen mit dem Befehl kubectl get:

    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 mit dem Befehl kubectl get events:

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

      Ersetzen Sie NAMESPACE 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.

Nächste Schritte