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. Außerdem werden Aspekte erläutert, die beim Sichern von Ressourcen zu berücksichtigen sind, und Schritte zur Fehlerbehebung.

Fehler 100020102: Strenger permissiver Modus – CRD konnte nicht gesichert werden – Nicht unterstützte v1beta1-API-Version

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 zur folgenden Fehlermeldung: Strict permissive mode - Failed to backup CRD - Unsupported v1beta1 API Version.

Dieser Fehler tritt auf, weil die apiextensions.k8s.io/v1 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 strengen Sicherungsplan schlägt der Sicherungsvorgang fehl, wenn eine Ressource gefunden wird, die nicht gesichert werden kann, z. B. eine CustomResourceDefinition, die mit der v1beta1 API erstellt wurde. Dieser Fehler tritt auf, weil der Ressource das strukturelle Schema fehlt, 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 wird.

So beheben Sie diesen Fehler:

  1. Ermitteln Sie das problematische CustomResourceDefinition mit dem Befehl kubectl get crd:

    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 spec.versions-Bedingung, indem Sie jede Version durchgehen, die unter dem Feld spec.versions aufgeführt ist. Wenn für eines der spec.versions das Feld schema.openAIV3Schema fehlt, ist für die entsprechende Version kein strukturelles Schema für CustomResourceDefinition definiert.

    2. status.conditions: Suchen Sie die Bedingung status.conditions, indem Sie die Bedingung type:NonStructuralSchema 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 das Upgrade erfolgreich ist, versuchen Sie es noch einmal mit der Sicherung. Andernfalls können Sie das Problem mit einer der folgenden Methoden 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 für den Sicherungsplan. Dadurch kann Sicherung für GKE die Ressource, einschließlich CustomResourceDefinitions in der v1beta1 API-Version, überspringen und mit dem Rest des Sicherungsvorgangs fortfahren. Weitere Informationen zum Aktivieren des moderaten Modus finden Sie unter Moderaten Modus in einem Sicherungsplan aktivieren.

  5. Wiederholen Sie den Sicherungsvorgang. Wenn der Vorgang weiterhin fehlschlägt, wenden Sie sich an 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 selectedNamespaces-Liste 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. Wenn der Namespace wirklich nicht mehr vorhanden ist und nicht gesichert werden muss, entfernen Sie ihn aus der Liste selectedNamespaces in der Konfiguration BackupPlan.

  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