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 von der v1 API erforderliche strukturelle Schema fehlt. 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.

Nächste Schritte