Systemfehler in Sicherung für GKE beheben

Auf dieser Seite werden systembezogene Fehler beschrieben, die bei der Verwendung von Sicherung für GKE auftreten können, sowie Aspekte, die Sie beim Sichern von Ressourcen berücksichtigen sollten, und Schritte zur Fehlerbehebung.

Fehler 100010108: PersistentVolumeClaim konnte nicht gesichert werden – CMEK für verschlüsseltes Laufwerk fehlt im Sicherungsplan

Der Fehler 100010108 tritt auf, wenn Sie regionale Volume-Sicherungen erstellen und der CMEK-Schlüssel des Sicherungsplans erforderlich ist, weil der GKE-Cluster auf ein verschlüsseltes Laufwerk verweist.

Fehler verstehen

Wenn Sie regional begrenzte Volume-Sicherungen erstellen, ist der CMEK-Schlüssel für den Sicherungsplan erforderlich, wenn der GKE-Cluster auf ein verschlüsseltes Laufwerk verweist. Dies ist eine strenge Anforderung für regional begrenzte Volumesicherungen. Wenn das Quelllaufwerk verschlüsselt ist, ist der Snapshot für dieses Laufwerk nur möglich, wenn ein CMEK für den Sicherungsplan angegeben wird. Wenn in Ihrem Sicherungsplan diese CMEK-Konfiguration fehlt, schlägt die Erstellung des Snapshots fehl und Sie sehen eine Fehlermeldung wie die folgende:

failed to create snapshot as disk "pvc-1" is encrypted with CMEK "projects/proj1/locations/us-east1/keyRings/keyring1/cryptoKeys/key1/cryptoKeyVersions/1", but no Backup Plan CMEK is provided. Please add CMEK to the Backup Plan.

Schritte zur Fehlerbehebung

  1. Fehlende CMEK-Konfiguration identifizieren: Die Fehlermeldung bestätigt, dass der gesicherte PVC verschlüsselt ist, aber in der Konfiguration des Sicherungsplans ein Verschlüsselungsschlüssel fehlt.
  2. CMEK zum Sicherungsplan hinzufügen: Aktualisieren Sie die Konfiguration Ihres Sicherungsplans, um einen kundenverwalteten Verschlüsselungsschlüssel (CMEK) einzuschließen. Mit diesem Schlüssel werden die Sicherungsdaten verschlüsselt, einschließlich der regionalen Volume-Sicherungen.
  3. Richtige Berechtigungen zuweisen: Prüfen Sie, ob dem Sicherung für GKE-Dienst-Agent (service-PROJECT_NUMBER@gcp-sa-gkebackup.iam.gserviceaccount.com) die Rolle roles/cloudkms.cryptoKeyEncrypterDecrypter für den neu hinzugefügten CMEK zugewiesen ist.
  4. Sicherungsvorgang noch einmal testen: Nachdem der Sicherungsplan mit dem CMEK aktualisiert und Berechtigungen erteilt wurden, versuchen Sie es noch einmal mit dem Sicherungsvorgang.

Fehler 100020102: CustomResourceDefinition – Ungültiges Schema – Nicht unterstützte API-Version v1beta1

Der Fehler 100020102 tritt auf, wenn der Versuch, ein CustomResourceDefinition zu sichern, das ursprünglich als apiextensions.k8s.io/v1beta1-Version angewendet wurde, fehlschlägt, weil es das strukturelle Schema nicht enthält, das in der apiextensions.k8s.io/v1-API-Version erforderlich ist. Dieser Fehler führt zu folgender Fehlermeldung: CustomResourceDefinition - has an invalid schema. The resource was originally applied as v1beta1, which has been removed from Kubernetes 1.22+.

Dieser Fehler tritt auf, weil die apiextensions.k8s.io/v1beta1 API-Version in Google Kubernetes Engine-Version 1.22 entfernt wurde. Weitere Informationen zum Entfernen von APIs für GKE-Version 1.22 finden Sie unter API-Entfernungen für GKE v1.22.

Verhalten von Sicherungsvorgängen im nicht moderaten Modus

Im nicht permissiven Modus oder in einem strikten Sicherungsplan schlägt der Sicherungsvorgang fehl, wenn eine Ressource gefunden wird, die nicht gesichert werden kann, z. B. ein CustomResourceDefinition, der mit der v1beta1 API erstellt wurde. Dieser Fehler tritt auf, weil die Ressource nicht das strukturelle Schema hat, das für die v1 API erforderlich ist. Das Vorhandensein dieses CustomResourceDefinition wird als kritischer Fehler betrachtet, da es möglicherweise nicht korrekt in einem neueren Cluster wiederhergestellt werden kann.

So beheben Sie diesen Fehler:

  1. Ermitteln Sie das problematische CustomResourceDefinition, indem Sie den Befehl kubectl get crd ausführen:

    kubectl get crd CRD_NAME

    Ersetzen Sie CRD_NAME durch den Namen des CustomResourceDefinition aus Ihrer Fehlermeldung.

  2. Prüfen Sie in der YAML-Ausgabe, ob CustomResourceDefinition korrekt von der vbeta1 API in die v1 API konvertiert wurde. Suchen Sie dazu nach den folgenden Bedingungen:

    1. spec.versions: Suchen Sie die Bedingung spec.versions, indem Sie jede Version durchgehen, die im Feld spec.versions aufgeführt ist. Wenn in einem der spec.versions das Feld schema.openAIV3Schema fehlt, ist für diese Version kein strukturelles Schema für das CustomResourceDefinition definiert.

    2. status.conditions: Suchen Sie die status.conditions-Bedingung, indem Sie die type:NonStructuralSchema-Bedingung finden. Wenn die status von status.conditions gleich true ist, wird explizit bestätigt, dass das Schema nicht strukturell ist.

  3. So aktualisieren Sie die CustomResourceDefinition- auf die v1-API-Version:

    1. Bearbeiten Sie die vorhandene CustomResourceDefinition, um sie mit dem v1-Standard kompatibel zu machen. Fügen Sie dazu ein strukturelles Schema hinzu, das jedes Feld und seinen Typ in der benutzerdefinierten Ressource definiert. Weitere Informationen zum Hinzufügen eines strukturellen Schemas finden Sie unter Strukturelles Schema angeben.

    2. Wenden Sie das kompatible v1-Manifest auf Ihren Cluster an.

  4. Wenn die Umstellung erfolgreich ist, versuchen Sie noch einmal, die Sicherung durchzuführen. Andernfalls verwenden Sie eine der folgenden Methoden, um das Problem zu beheben:

    • Löschen Sie die CustomResourceDefinition mit dem Befehl kubectl delete crd, wenn die CustomResourceDefinition nicht im Cluster verwendet wird.

      kubectl delete crd CRD_NAME

      Ersetzen Sie CRD_NAME durch den Namen des CustomResourceDefinition, den Sie löschen möchten.

    • Aktivieren Sie den moderaten Modus im Sicherungsplan, damit Sicherung für GKE die Ressource überspringen kann, einschließlich CustomResourceDefinitions in der API-Version v1beta1, und mit dem Rest des Sicherungsvorgangs fortfahren kann. Weitere Informationen zum Aktivieren des moderaten Modus finden Sie unter Moderaten Modus in einem Sicherungsplan aktivieren.

  5. Versuchen Sie noch einmal, die Sicherung zu erstellen. Wenn der Vorgang weiterhin fehlschlägt, wenden Sie sich an Cloud Customer Care, um weitere Unterstützung zu erhalten.

Fehler 100020103: Abfrage der API-Ressourcen fehlgeschlagen

Der Fehler 100020103 tritt auf, wenn Sicherung für GKE vor dem Erstellen einer Sicherung keine benutzerdefinierten oder aggregierten Kubernetes API-Dienste finden kann. Dies führt zu der Fehlermeldung Failed to query API resources. Please check if any API service is unavailable by using 'kubectl get apiservice'. Das passiert, wenn ein aggregierter API-Dienst falsch konfiguriert ist oder seine zugrunde liegenden Dienste und Pods fehlerhaft oder nicht erreichbar sind. Im nicht permissiven Modus oder in einem strengen Sicherungsplan beendet Sicherung für GKE den Sicherungsvorgang, wenn ein nicht verfügbarer APIService gefunden wird, um zu vermeiden, dass ein unvollständiger oder inkonsistenter Clusterstatus erfasst wird.

So beheben Sie diesen Fehler:

  1. Ermitteln Sie nicht verfügbare API-Dienste mit dem folgenden Befehl:

    kubectl get apiservice

    Suchen Sie in der Ausgabe nach API-Diensten, bei denen die Spalte AVAILABLE den Wert False hat.

  2. Prüfen Sie die Details des fehlgeschlagenen APIService mit dem folgenden Befehl:

    kubectl describe apiservice APISERVICE_NAME

    Ersetzen Sie APISERVICE_NAME durch den Namen des API-Dienstes, bei dem ein Fehler aufgetreten ist, z. B. v1beta1.custom.metrics.k8s.io.

    Sehen Sie sich in der Ausgabe das Feld Service unter spec.service und den Abschnitt Conditions an, um den zugrunde liegenden Dienst, seinen Namespace und die Ursache des Fehlers zu ermitteln (z. B. fehlende Endpunkte oder ein nicht erreichbarer Zielport).

  3. Verwenden Sie eine der folgenden Methoden, um den Fehler zu beheben:

    • Unterstützenden Dienst wiederherstellen: Prüfen Sie mit dem folgenden Befehl, ob der unterstützende Dienst über bereite Endpunkte verfügt:

      kubectl get endpoints -n NAMESPACE SERVICE_NAME

      Ersetzen Sie Folgendes:

      • NAMESPACE: Der Namespace des Backing-Dienstes.
      • SERVICE_NAME: der Name des unterstützenden Dienstes.

      Prüfen Sie, ob die Pods, die den Dienst unterstützen, vorhanden sind und sich im Status Running befinden. Beheben Sie alle Pod-Abstürze, Fehler beim Abrufen von Images oder Fehlkonfigurationen von Netzwerkrichtlinien, die verhindern, dass Traffic den unterstützenden Dienst erreicht.

    • Verwaiste APIService löschen: Wenn die APIService zu einer Anwendung, einem Operator oder einem Monitoring-Tool gehört, das entfernt wurde oder nicht mehr verwendet wird, löschen Sie die veraltete APIService:

      kubectl delete apiservice APISERVICE_NAME

      Ersetzen Sie APISERVICE_NAME durch den Namen des verwaisten API-Dienstes.

    • Moderaten Modus aktivieren: Wenn Sie den nicht verfügbaren API-Dienst nicht sofort beheben oder entfernen können, aktivieren Sie den moderaten Modus im Sicherungsplan. Wenn der permissive Modus aktiviert ist, wird der Sicherungsvorgang von Sicherung für GKE fortgesetzt. Ressourcen, die zur nicht verfügbaren API-Gruppe gehören, werden jedoch nicht gesichert. Weitere Informationen zum Aktivieren des moderaten Modus finden Sie unter Moderaten Modus in einem Sicherungsplan aktivieren.

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

Fehler 100040102: Namespace nicht gefunden

Der Fehler 100040102 tritt auf, wenn ein Sicherungsvorgang fehlschlägt, weil ein im Sicherungsbereich angegebener Namespace im Cluster nicht gefunden werden kann. Der Sicherung für GKE-Agent konnte einen oder mehrere Namespaces nicht finden, die explizit im Feld selectedNamespaces der BackupPlan-Konfiguration aufgeführt waren. Sicherung für GKE müssen alle angegebenen Namespaces im Cluster vorhanden sein, wenn der Sicherungsvorgang gestartet wird. Wenn der Namespace nicht gefunden wird, wird die folgende Fehlermeldung angezeigt:

Namespace [NAMESPACE_NAME] is not found.

So beheben Sie das Problem:

  1. Prüfen Sie, ob der Namespace richtig eingegeben wurde, indem Sie die Liste selectedNamespaces in Ihrer BackupPlan-Konfiguration aufrufen.

  2. Prüfen Sie mit dem Befehl kubectl get namespace, ob der in der Fehlermeldung angegebene Namespace vorhanden ist:

    kubectl get namespace NAMESPACE_NAME

    Ersetzen Sie NAMESPACE_NAME durch den Namen des Namespace, der in der Fehlermeldung angegeben ist.

    Wenn der Namespace nicht vorhanden ist, wird eine Meldung angezeigt, dass der Namespace nicht gefunden wurde, z. B. Error from server (NotFound): namespaces "[NAMESPACE_NAME]" not found.

  3. Korrigieren Sie die BackupPlan. Wenn der Namespace falsch geschrieben wurde, aktualisieren Sie BackupPlan mit dem richtigen Namen des Namespace. Wenn der Namespace wirklich nicht mehr vorhanden ist und nicht gesichert werden muss, entfernen Sie ihn aus der Liste selectedNamespaces in der BackupPlan-Konfiguration.

  4. Versuchen Sie noch einmal, die Sicherung durchzuführen, nachdem Sie die erforderlichen Korrekturen an der BackupPlan vorgenommen haben, und starten Sie eine neue Sicherung.

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

Nächste Schritte