Einige oder alle Informationen auf dieser Seite gelten möglicherweise nicht für Cloud de Confiance von S3NS. Weitere Informationen finden Sie unter Unterschiede zu Google Cloud.

Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Systemfehler in Sicherung für GKE beheben

Autopilot Standard

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 100010108: PersistentVolumeClaim konnte nicht gesichert werden – CMEK-Sicherungsplan für verschlüsselte Festplatte fehlt

Der Fehler 100010108 tritt beim Erstellen von regionalen Volumensicherungen auf und der CMEK-Schlüssel für den Sicherungsplan ist erforderlich, da der GKE-Cluster auf eine verschlüsselte Festplatte verweist.

Fehler nachvollziehen

Wenn Sie regional begrenzte Volume-Sicherungen erstellen, ist der CMEK des Sicherungsplans 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 Snapshot-Erstellung fehl und Sie erhalten 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

Fehlende CMEK-Konfiguration identifizieren: Die Fehlermeldung bestätigt, dass der gesicherte PVC verschlüsselt ist, aber in der Sicherungsplan-Konfiguration fehlt ein Verschlüsselungsschlüssel.
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.
Richtige Berechtigungen zuweisen: Prüfen Sie, ob dem Sicherung für GKE-Dienst-Agent (service-PROJECT_NUMBER@gcp-sa-gkebackup.s3ns-system.iam.gserviceaccount.com) die Rolle roles/cloudkms.cryptoKeyEncrypterDecrypter für den neu hinzugefügten CMEK zugewiesen ist.
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: 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 der API 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:

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.
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 im Feld spec.versions aufgeführt ist. Wenn für eines 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 Bedingung status.conditions, indem Sie die Bedingung type:NonStructuralSchema finden. Wenn der status des status.conditions true ist, wird explizit bestätigt, dass das Schema nicht strukturell ist.
So stellen Sie die CustomResourceDefinition auf die API-Version v1 um:
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.
  
  Hinweis :In einigen Fällen müssen Sie möglicherweise die zuvor erstellte CustomResourceDefinition ohne strukturelles Schema löschen und die v1-Version noch einmal anwenden, damit der API-Server die Ressourcenkonvention richtig verarbeitet.
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.
  
  Hinweis: Sie sollten nicht versuchen, ein CustomResourceDefinition zu löschen, wenn es aktiv eine vorhandene benutzerdefinierte Ressource im Cluster bereitstellt. Sie müssen entweder noch einmal versuchen, die CustomResourceDefinition-API auf die Version v1 zu aktualisieren, oder den permissiven Modus aktivieren.
```
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 API-Version v1beta1, überspringen und mit dem Rest des Sicherungsvorgangs fortfahren. Weitere Informationen zum Aktivieren des moderaten Modus finden Sie unter Moderaten Modus in einem Sicherungsplan aktivieren.
  
  Warnung :Das problematische CustomResourceDefinition und die zugehörigen benutzerdefinierten Ressourcen werden nicht gesichert und sind bei der Wiederherstellung nicht enthalten. Wenn Sie eine solche Sicherung wiederherstellen möchten, müssen Sie die von der CustomResourceDefinition bereitgestellten Ressourcen von der Wiederherstellung ausschließen oder die CustomResourceDefinition im Zielcluster erstellen, bevor Sie mit der Wiederherstellung beginnen.
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:

Prüfen Sie, ob der Namespace richtig eingegeben wurde, indem Sie die selectedNamespaces-Liste in Ihrer BackupPlan-Konfiguration aufrufen.
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.
Korrigieren Sie die BackupPlan. Wenn der Namespace falsch geschrieben wurde, aktualisieren Sie BackupPlan mit dem richtigen Namespace-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.
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

Übersichtsseite zu Sicherung für GKE-Fehlercodes