Moderaten Modus in einem Sicherungsplan aktivieren

Autopilot Standard

Auf dieser Seite wird erläutert, wie Sie den moderaten Modus in einem Sicherungsplan aktivieren.

Wenn Backup for GKE während der Sicherung Bedingungen erkennt, die wahrscheinlich zu einem Wiederherstellungsfehler führen, schlägt die Sicherung fehl. Der Grund für den Fehler wird im Feld state_reason der Sicherung angegeben. In der Google Cloud Console wird dieses Feld als Grund für den Status bezeichnet.

Wenn Sie den moderaten Modus aktivieren, wird die Beschreibung des Problems weiterhin im Feld Statusgrund angezeigt, die Sicherung schlägt jedoch nicht fehl. Sie können dieses Verhalten aktivieren, wenn Sie sich des Problems bewusst sind und bereit sind, bei der Wiederherstellung eine Umgehung zu verwenden.

Das folgende Beispiel zeigt eine Fehlermeldung, die im Feld Statusgrund der Sicherung angezeigt werden kann, die vorschlägt, den moderaten Modus zu aktivieren: If you cannot implement the recommended fix, you may create a new backup with Permissive Mode enabled.

gcloud

Moderaten Modus aktivieren:

gcloud beta container backup-restore backup-plans update BACKUP_PLAN \
    --project=PROJECT_ID \
    --location=LOCATION
    --permissive-mode

Ersetzen Sie Folgendes:

BACKUP_PLAN: der Name des Sicherungsplans, den Sie aktualisieren möchten.
PROJECT_ID: die ID Ihres Google Cloud-Projekts.
LOCATION: die Computing-Region für die Ressource, z. B. us-central1. Siehe Informationen zu Ressourcenstandorten.

Eine vollständige Liste der Optionen finden Sie in der Dokumentation zu gcloud beta container backup-restore backup-plans update.

Console

Gehen Sie nach der folgenden Anleitung vor, um den moderaten Modus in der Google Cloud Console zu aktivieren:

Rufen Sie in der Google Cloud Console die Seite Google Kubernetes Engine auf.

Zur Seite "Google Kubernetes Engine"
Klicken Sie im Navigationsmenü auf Sicherung für GKE.
Klicken Sie auf den Tab Sicherungspläne.
Maximieren Sie den Cluster und klicken Sie auf den Namen des Plans.
Klicken Sie auf den Tab Details, um die Plandetails zu bearbeiten.
Klicken Sie auf Bearbeiten, um den Bereich mit Sicherungsmodus zu bearbeiten.
Klicken Sie auf das Kästchen Moderater Modus und dann auf Änderungen speichern.

Terraform

Aktualisieren Sie die vorhandene google_gke_backup_backup_plan-Ressource.

resource "google_gke_backup_backup_plan" "NAME" {
   ...
   backup_config {
     permissive_mode = true
     ...
   }
}

Ersetzen Sie Folgendes:

NAME: Der Name der google_gke_backup_backup_plan, die Sie aktualisieren möchten.

Weitere Informationen finden Sie unter gke_backup_backup_plan.

Fehler bei der Sicherung beheben

In der folgenden Tabelle finden Sie Erklärungen und empfohlene Maßnahmen für verschiedene Fehlermeldungen bei Sicherungen, die im Feld Statusgrund der Sicherung angezeigt werden.

Fehlermeldung bei der Sicherung	Beschreibung der Nachricht und Fehlerursache	Empfohlene Maßnahmen
`CustomResourceDefinitions "..." have invalid schemas`	Beschreibung: Eine benutzerdefinierte Ressourcendefinition (CRD) im Cluster wurde ursprünglich als `apiextensions.k8s.io/v1beta1` angewendet und es fehlt ein strukturelles Schema, das in `apiextensions.k8s.io/v1` erforderlich ist. Grund: Backup for GKE kann das Strukturschema nicht automatisch definieren. Wenn Sie die CRD in Kubernetes-Clustern der Version 1.22 oder höher wiederherstellen, in denen `apiextensions.k8s.io/v1beta1` nicht verfügbar ist, schlägt die Wiederherstellung fehl. Dieser Fehler tritt beim Wiederherstellen benutzerdefinierter Ressourcen auf, die von der CRD definiert wurden.	Wir empfehlen die folgenden Optionen: Wenn Sie die CRD verwalten, folgen Sie der Anleitung in der Kubernetes-Dokumentation, um ein Strukturschema für Ihre CRD anzugeben. Wenn es sich um eine von GKE verwaltete CRD handelt, können Sie `kubectl delete crd` aufrufen, wenn keine Ressourcen vorhanden sind, die von der CRD bereitgestellt werden. Wenn über die CRD vorhandene Ressourcen bereitgestellt werden, können Sie den permissiven Modus aktivieren, wenn Sie mit dem Wiederherstellungsverhalten vertraut sind. Empfehlungen zu gängigen CRDs finden Sie in der Dokumentation. Wenn es sich um eine CRD eines Drittanbieters handelt, lesen Sie die entsprechende Dokumentation, um zu `apiextensions.k8s.io/v1` zu migrieren. Wenn der permissive Modus aktiviert ist, wird die CRD ohne strukturelles Schema in einem Kubernetes-Cluster der Version 1.22 oder höher nicht gesichert. Wenn Sie eine solche Sicherung wiederherstellen möchten, müssen Sie die von der CRD bereitgestellten Ressourcen von der Wiederherstellung ausschließen oder die CRD im Zielcluster erstellen, bevor Sie mit der Wiederherstellung beginnen.
`PersistentVolumeClaims "..." are bound to PersistentVolumes of unsupported types "..." and cannot be backed up`	Beschreibung: Im Quellcluster ist ein PVC an ein PV gebunden, das kein Persistent Disk-Volume ist. Erläuterung: Backup for GKE unterstützt nur die Sicherung von Daten von nichtflüchtigen Volumes. Bei PVCs für nichtflüchtige Laufwerke, die mit der Richtlinie Neue Volumes bereitstellen und Volume-Daten aus der Sicherung wiederherstellen wiederhergestellt werden, werden keine Volume-Daten wiederhergestellt. Mit der Richtlinie Vorhandene Volumes mit Ihren Daten wiederverwenden können PVCs jedoch wieder mit dem ursprünglichen Volume-Handle verbunden werden. Dies ist nützlich für Volumetypen, die von einem externen Server unterstützt werden, z. B. NFS.	Aktivieren Sie den permissiven Modus, wenn Sie die verfügbaren Wiederherstellungsoptionen für die Volumes ohne nichtflüchtigen Speicher im Quellcluster kennen. Informationen zum Sichern von Filestore-Volumes finden Sie unter Filestore-Volumes mit Backup for GKE verarbeiten. Wenn der permissive Modus aktiviert ist, wird die PVC-Konfiguration gesichert, die Volume-Daten jedoch nicht.
`PersistentVolumeClaims "..." are not bound to PersistentVolumes and cannot be backed up`	Beschreibung: Ein PVC im Cluster ist nicht an ein PV gebunden. Erläuterung: Backup for GKE kann das PVC sichern, es gibt jedoch keine Volume-Daten, die gesichert werden können. Dies kann auf eine fehlerhafte Konfiguration oder eine Abweichung zwischen angefordertem und verfügbarem Speicherplatz hinweisen.	Prüfen Sie, ob das unverbundene PVC in einem akzeptablen Zustand ist. Falls ja, aktivieren Sie den permissiven Modus. Beachten Sie die Auswirkungen auf das Sicherungsverhalten. Wenn der permissive Modus aktiviert ist, wird die PVC-Konfiguration gesichert, es gibt jedoch keine Volume-Daten, die gesichert werden müssen.
`Failed to query API resources ...`	Beschreibung: Ein API-Dienst im Cluster ist falsch konfiguriert. Dadurch wird bei Anfragen an den API-Pfad die Meldung „Abfrage der API-Ressourcen fehlgeschlagen“ zurückgegeben. Der zugrunde liegende Dienst existiert möglicherweise nicht oder ist noch nicht bereit. Grund: Backup for GKE kann keine Ressourcen sichern, die über die nicht verfügbare API bereitgestellt werden.	Prüfen Sie den zugrunde liegenden Dienst in der `spec.service` des API-Dienstes, um sicherzustellen, dass er bereit ist. Wenn der permissive Modus aktiviert ist, werden Ressourcen aus den API-Gruppen, die nicht geladen werden konnten, nicht gesichert.
`Secret ... is an auto-generated token from ServiceAccount ... referenced in Pod specs`	Beschreibung: In Kubernetes v1.23 und niedriger generieren Dienstkonten automatisch ein Token, das von einem Secret unterstützt wird. In späteren Versionen wurde diese Funktion für automatisch generierte Tokens jedoch entfernt. Ein Pod im Cluster hat möglicherweise das Secret-Volume im Dateisystem seiner Container bereitgestellt. Erläuterung: Wenn Backup for GKE versucht, ein Dienstkonto zusammen mit seinem automatisch generierten Secret und einem Pod wiederherzustellen, der das Secret-Volume bereitstellt, scheint die Wiederherstellung erfolgreich zu sein. Kubernetes entfernt das Secret jedoch, wodurch der Pod bei der Containererstellung hängen bleibt und nicht gestartet werden kann.	Definieren Sie das Feld `spec.serviceAccountName` im Pod. Dadurch wird sichergestellt, dass das Token automatisch in den Containern auf `/var/run/secrets/kubernetes.io/serviceaccount` bereitgestellt wird. Weitere Informationen finden Sie in der Dokumentation Dienstkonten für Pods konfigurieren. Wenn der permissive Modus aktiviert ist, wird das Secret gesichert, kann aber nicht in Pods in Kubernetes-Clustern ab Version 1.24 oder höher bereitgestellt werden.

Häufige CRDs mit Problemen und empfohlene Maßnahmen

Im Folgenden finden Sie einige gängige CRDs mit Sicherungsproblemen und die empfohlenen Maßnahmen zur Behebung der Probleme:

capacityrequests.internal.autoscaling.k8s.io: Diese CRD wurde vorübergehend in Clustern der Version 1.21 verwendet. Führen Sie kubectl delete crd capacityrequests.internal.autoscaling.k8s.io aus, um die CRD zu entfernen.
scalingpolicies.scalingpolicy.kope.io: Diese CRD wurde zur Steuerung von fluentd-Ressourcen verwendet. In GKE wird jedoch jetzt fluentbit verwendet. Führen Sie kubectl delete crd scalingpolicies.scalingpolicy.kope.io aus, um die CRD zu entfernen.
memberships.hub.gke.io: kubectl delete crd memberships.hub.gke.io ausführen, um die CRD zu entfernen, wenn keine Mitgliedschaftsressourcen vorhanden sind. Aktivieren Sie den permissiven Modus, wenn es Mitgliedschaftsressourcen gibt.
applications.app.k8s.io: Moderaten Modus aktivieren und das Wiederherstellungsverhalten kennen.