Anthos Clusters on Bare Metal sind jetzt Google Distributed Cloud (nur Software) für Bare Metal. Weitere Informationen finden Sie in der Produktübersicht.

Diese Seite wurde von der Cloud Translation API übersetzt.

Cluster mit bmctl sichern und wiederherstellen

Auf dieser Seite wird beschrieben, wie Sie mit bmctl Cluster sichern und wiederherstellen, die mit Google Distributed Cloud erstellt wurden. Diese Anleitung gilt für alle Clustertypen, die von Google Distributed Cloud unterstützt werden.

Der Sicherungs- und Wiederherstellungsprozess bmctl enthält keine nichtflüchtigen Volumes. Alle Volumes, die vom lokalen Volume-Bereitsteller (Local Volume Provisioner, LVP) erstellt werden, bleiben unverändert.

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.

Cluster sichern

Mit dem Befehl bmctl backup cluster werden die Clusterinformationen aus dem etcd-Speicher und die PKI-Zertifikate für den angegebenen Cluster einer TAR-Datei hinzugefügt. Der etcd-Speicher ist der Kubernetes-Sicherungsspeicher für alle Clusterdaten. Er enthält alle Kubernetes-Objekte und benutzerdefinierten Objekte, die zur Verwaltung des Clusterstatus erforderlich sind. Die PKI-Zertifikate werden für die Authentifizierung über TLS verwendet. Diese Daten werden von der Steuerungsebene des Clusters oder von einer der Steuerungsebenen für ein Deployment mit Hochverfügbarkeit gesichert.

Die TAR-Datei für die Sicherung enthält vertrauliche Anmeldedaten, einschließlich der Dienstkontoschlüssel und des SSH-Schlüssels. Speichern Sie Sicherungsdateien an einem sicheren Ort. Um eine unbeabsichtigte Offenlegung von Dateien zu vermeiden, verwendet der Google Distributed Cloud-Sicherungsprozess nur Dateien im Arbeitsspeicher.

Sichern Sie Ihre Cluster regelmäßig, um dafür zu sorgen, dass die Snapshot-Daten relativ aktuell sind. Passen Sie die Sicherungsrate entsprechend der Häufigkeit signifikanter Änderungen an Ihren Clustern an.

Die Version bmctl, mit der Sie einen Cluster sichern, muss mit der Version des Verwaltungsclusters übereinstimmen.

So sichern Sie einen Cluster:

Prüfen Sie, ob Ihr Cluster ordnungsgemäß mit funktionierenden Anmeldedaten und SSH-Verbindungen zu allen Knoten funktioniert.

Der Sicherungsprozess besteht darin, Ihren Cluster in einem als funktionierend bekannten Zustand zu erfassen, damit Sie den Vorgang wiederherstellen können, wenn ein schwerwiegender Fehler auftritt.

Prüfen Sie den Cluster mit dem folgenden Befehl:
```
bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME: der Name des Clusters, den Sie sichern möchten.
- ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei für den Administratorcluster.
Führen Sie den folgenden Befehl aus, um dafür zu sorgen, dass sich der Zielcluster nicht im Abgleichsstatus befindet:
```
kubectl describe cluster CLUSTER_NAME -n CLUSTER_NAMESPACE --kubeconfig ADMIN_KUBECONFIG
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME: der Name des zu sichernden Clusters.
- CLUSTER_NAMESPACE: der Namespace für den Cluster. Standardmäßig sind die Cluster-Namespaces für Google Distributed Cloud der Name des Clusters, dem cluster- vorangestellt wird. Wenn Sie Ihren Cluster beispielsweise test nennen, hat der Namespace einen Namen wie cluster-test.
- ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei für den Administratorcluster.

Suchen Sie im Abschnitt Status der Befehlsausgabe nach Conditions vom Typ Reconciling.

Wie im folgenden Beispiel gezeigt, bedeutet der Status False für diese Conditions, dass der Cluster stabil ist und gesichert werden kann.

...
Status:
  ...
  Cluster State:  Running
  ...
  Control Plane Node Pool Status:
    ...
    Conditions:
      Last Transition Time:  2023-11-03T16:37:15Z
      Observed Generation:   1
      Reason:                ReconciliationCompleted
      Status:                False
      Type:                  Reconciling
  ...

Führen Sie den folgenden Befehl aus, um den Cluster zu sichern:
```
bmctl backup cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME: der Name des zu sichernden Clusters.
- ADMIN_KUBECONFIG: der Pfad zur kubeconfig-Datei des Administratorclusters.
Standardmäßig wird die TAR-Sicherungsdatei, die im Workspace-Verzeichnis gespeichert ist (standardmäßig bmctl-workspace), auf Ihrer Administrator-Workstation gespeichert. Die TAR-Datei heißt CLUSTER_NAME_backup_TIMESTAMP.tar.gz, wobei CLUSTER_NAME der Name des zu sichernden Clusters und TIMESTAMP das Datum und die Uhrzeit der Sicherung sind. Wenn der Clustername beispielsweise testuser lautet, hat die Sicherungsdatei einen Namen wie testuser_backup_2006-01-02T150405Z0700.tar.gz.

Verwenden Sie das Flag --backup-file, um einen anderen Namen und einen anderen Speicherort für Ihre Sicherungsdatei anzugeben.

Die Sicherungsdatei läuft nach einem Jahr ab und der Clusterwiederherstellungsprozess funktioniert nicht mit abgelaufenen Sicherungsdateien.

Cluster wiederherstellen

Die Wiederherstellung eines Clusters aus einer Sicherung ist das letzte Mittel, das angewendet werden sollte, wenn ein Cluster komplett fehlgeschlagen ist und nicht auf andere Weise wieder funktionsfähig gemacht werden kann. Dies kann beispielsweise der Fall sein, wenn die etcd-Daten beschädigt sind oder wenn sich der etcd-Pod in einer Absturzschleife befindet.

Die TAR-Datei für die Sicherung enthält vertrauliche Anmeldedaten, einschließlich der Dienstkontoschlüssel und des SSH-Schlüssels. Um eine unbeabsichtigte Offenlegung von Dateien zu vermeiden, verwendet der Wiederherstellungsprozess von Google Distributed Cloud nur Dateien im Arbeitsspeicher.

Die Version bmctl, mit der Sie einen Cluster wiederherstellen, muss mit der Version des Verwaltungsclusters übereinstimmen.

So stellen Sie einen Cluster wieder her:

Achten Sie darauf, dass alle Knotenmaschinen, die zum Zeitpunkt der Sicherung für den Cluster verfügbar waren, ordnungsgemäß funktionieren und erreichbar sind.
Achten Sie darauf, dass die SSH-Verbindung zwischen den Knoten mit den SSH-Schlüsseln funktioniert, die zum Zeitpunkt der Sicherung verwendet wurden.

Diese SSH-Schlüssel werden im Rahmen des Wiederherstellungsprozesses wiederhergestellt.
Achten Sie darauf, dass die zum Zeitpunkt der Sicherung verwendeten Dienstkontoschlüssel weiterhin aktiv sind.

Diese Dienstkontoschlüssel werden für den wiederhergestellten Cluster reaktiviert.
Führen Sie den folgenden Befehl aus, um einen Administrator-, Hybrid- oder eigenständigen Cluster wiederherzustellen:
```
bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME: der Name des Clusters, den Sie wiederherstellen.
- BACKUP_FILE: der Pfad und der Name der Sicherungsdatei, die Sie verwenden.
Führen Sie den folgenden Befehl aus, um einen Nutzercluster wiederherzustellen:
```
bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE \
    --kubeconfig ADMIN_KUBECONFIG
```
Ersetzen Sie Folgendes:
- CLUSTER_NAME: der Name des Clusters, den Sie wiederherstellen.
- BACKUP_FILE: der Pfad und der Name der Sicherungsdatei, die Sie verwenden.
- ADMIN_KUBECONFIG: der Pfad zur kubeconfig-Datei des Administratorclusters.

Am Ende des Wiederherstellungsprozesses wird eine neue kubeconfig-Datei für den wiederhergestellten Cluster generiert.

Fehlerbehebung

Wenn Sie Probleme mit dem Sicherungs- oder Wiederherstellungsprozess haben, helfen Ihnen die folgenden Abschnitte möglicherweise bei der Fehlerbehebung.

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Google-Support.

Nicht genügend Arbeitsspeicher während einer Sicherung oder Wiederherstellung

Möglicherweise erhalten Sie während des Sicherungs- oder Wiederherstellungsprozesses Fehlermeldungen, die nicht sehr selbsterklärend sind oder keine klaren Informationen zu den nächsten Schritten haben. Wenn die Workstation, auf der Sie den Befehl bmctl ausführen, nicht viel RAM hat, ist möglicherweise nicht genügend Arbeitsspeicher vorhanden, um den Sicherungs- oder Wiederherstellungsprozess durchzuführen.

Google Distributed Cloud Version 1.13 und höher kann den Parameter --use-disk im Sicherungsbefehl verwenden. Damit die Dateiberechtigungen erhalten bleiben, ändert dieser Parameter die Berechtigungen der Dateien. Der Nutzer, der den Befehl ausführt, muss also ein Root-Nutzer sein (oder sudo verwenden).

Fehlende Berechtigungen für Dateien während der Wiederherstellung

Nach einer erfolgreichen Wiederherstellungsaufgabe kann das Löschen von Bootstrap mit einer Fehlermeldung ähnlich dem folgenden Beispiel fehlschlagen:

Error: failed to restore node config files: sftp: "Failure" (SSH_FX_FAILURE)

Dieser Fehler kann bedeuten, dass einige der für die Wiederherstellung erforderlichen Verzeichnisse nicht beschreibbar sind.

In Google Distributed Cloud Version 1.14 und höher werden deutlichere Fehlermeldungen angezeigt, in denen Verzeichnisse beschreibbar sein müssen. Achten Sie darauf, dass die gemeldeten Verzeichnisse beschreibbar sind, und aktualisieren Sie die Berechtigungen für die Verzeichnisse nach Bedarf.

SSH-Schlüssel aktualisieren, nachdem eine Sicherung den Wiederherstellungsprozess unterbrochen hat

SSH-bezogene Vorgänge während des Wiederherstellungsprozesses können fehlschlagen, wenn der SSH-Schlüssel nach der Sicherung aktualisiert wird. In diesem Fall wird der neue SSH-Schlüssel für den Wiederherstellungsprozess ungültig.

Um dieses Problem zu beheben, können Sie den ursprünglichen SSH-Schlüssel vorübergehend wieder hinzufügen und dann die Wiederherstellung ausführen. Nach Abschluss der Wiederherstellung können Sie den SSH-Schlüssel rotieren.