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

Cluster mit bmctl sichern und wiederherstellen

Mit dem bmctl-Befehlszeilentool können Sie Cluster sichern und wiederherstellen, die mit Distributed Cloud-Software nur für Bare Metal erstellt wurden, um sich auf die Notfallwiederherstellung vorzubereiten oder einen beschädigten Cluster für alle Clustertypen wiederherzustellen. Die Wiederherstellung aus einer Sicherung ist ein letzter Ausweg, bei dem der Cluster zurückgesetzt und vorhandene Clusterinformationen überschrieben werden. Stellen Sie nur dann eine Sicherung wieder her, wenn ein Cluster katastrophal ausfällt. Wenden Sie sich an Cloud Customer Care, wenn Sie Hilfe bei der Entscheidung benötigen.

Was wird gesichert und was nicht?

Der Sicherungs- und Wiederherstellungsprozess von bmctl erfolgt auf der Ebene der Kubernetes-Steuerungsebene und unterscheidet sich von anderen Sicherungslösungen. Nicht-Kubernetes-Sicherungslösungen erfassen Arbeitslastdaten, nichtflüchtigen Speicher und die Hostbetriebssysteme der physischen Maschinen. Beim Sicherungs- und Wiederherstellungsprozess von bmctl werden Ihre Kubernetes-Cluster wiederhergestellt, ohne dass diese anderen Komponenten gesichert werden.

Status der Steuerungsebene (gesichert durch den Sicherungsprozess `bmctl`)

bmctl sichert die folgenden Objekte:

etcd-Speicher. Alle Kubernetes-Ressourcen und benutzerdefinierten Objekte, die die Konfiguration und den ausgewählten Status des Clusters definieren (z. B. Pod-Spezifikationen, Deployments, ConfigMaps und Secrets).
PKI-Zertifikate Zertifikate, die für die sichere Kommunikation innerhalb des Clusters verwendet werden.
Konfigurationsdateien und Manifeste für Knoten. Konfigurationen, die sich auf die Clusterknoten beziehen.

Arbeitslast- und VM-Laufzeitspeicher (nicht durch den `bmctl`-Sicherungsprozess gesichert)

bmctl sichert die folgenden Daten nicht:

Live-Pod- und Containerlaufzeitstatus. bmctl speichert keine aktiven Prozesse und Anwendungsdaten im Arbeitsspeicher. Nach einer Wiederherstellung startet Kubernetes Pods aus den etcd-Spezifikationen neu. Nicht gespeicherte Status im Arbeitsspeicher gehen verloren.
Nichtflüchtiger Volume-Speicher. bmctl sichert keine Daten, die in nichtflüchtigen Volumes, von Local Volume Provisioner (LVP) erstellten Volumes oder externen Speichertreibern gespeichert sind.
VM-Laufwerke bmctl sichert nicht den Inhalt der virtuellen Festplatte der VM, z. B. Datenbanken, Dateien oder den Betriebssystemstatus innerhalb der VM.

Sie müssen Kubernetes-native oder In-Guest-Sicherungsmechanismen verwenden, um Anwendungsdaten und den Status der virtuellen Maschine zu schützen. Wenn der zugrunde liegende Speichertreiber CSI-Volume-Snapshots unterstützt, verwenden Sie Kubernetes-Standard-Volume-Snapshots, um zeitpunktbezogene Kopien von nichtflüchtigen Volumes zu erstellen. Weitere Informationen zum Konfigurieren des Speichers finden Sie unter Speicher – Übersicht.

Führen Sie Sicherungs-Agents im Gastbetriebssystem von VM Runtime-VMs aus oder stellen Sie anwendungsspezifische Sicherungstools in Kubernetes-Arbeitslasten bereit.

Physische Hostbetriebssysteme (nicht unterstützt)

Behandeln Sie physische Linux-Betriebssysteme auf Google Distributed Cloud-Knoten als Einweg-Infrastruktur. Die Kubernetes-Netzwerkarchitektur unterstützt die Wiederherstellung von Betriebssystem-Images auf Hostebene nicht. Daher unterstützt Google nicht die Installation von Sicherungs-Agents von Drittanbietern auf Hostebene direkt auf dem Host-Betriebssystem oder die Wiederherstellung physischer Knoten aus Image-Sicherungen auf Betriebssystemebene oder Laufwerk-Snapshots.

Wenn Sie physische Sicherungs-Agents von Drittanbietern direkt auf dem Linux-Hostbetriebssystem installieren, kann dies zu ernsthaften Risiken führen.

Viele Sicherungs-Agents installieren proprietäre Kernel-Module oder Filtertreiber auf Blockebene, um Änderungen zu verfolgen und lokale Laufwerksblöcke während Snapshot-Vorgängen zu sperren. Dies kann zu folgenden Problemen führen:

Die etcd-Datenbank kann ihre Write-Ahead-Logs nicht anhängen, Knoten-Heartbeats werden abgebrochen, der Raft-Konsens schlägt fehl und Cluster werden instabil.
Nicht unterstützte Kernel-Treiber von Drittanbietern stehen im Konflikt mit Low-Level-Kernel-Routinen und der Containerlaufzeit, was zu Fehlern bei Clusterupgrades führt.
Das Wiederherstellen eines physischen Knotens aus einer Image-Sicherung oder einem Laufwerk-Snapshot verstößt gegen das Raft-Konsensprotokoll. Die etcd-Datenbank ist nicht mehr mit den Logs auf den Knoten der Steuerungsebene synchronisiert und es kommt zu einer schwerwiegenden Beschädigung des Clusterstatus.
Worker-Knoten sind nicht mehr mit der Source of Truth des API-Servers synchron, Dataplane V2-IP-Adressen (Cilium) kollidieren und Traffic wird verworfen.

Wenn Sie einen physischen Knoten wiederherstellen möchten, bei dem ein Betriebssystem- oder Hardwarefehler aufgetreten ist, sollten Sie kein Betriebssystem-Image wiederherstellen. Entfernen Sie stattdessen den Knoten sauber aus dem Cluster, installieren Sie ein sauberes Basisbetriebssystem neu und fügen Sie den Knoten wieder dem Knotenpool hinzu. Eine ausführliche Anleitung zur Wiederherstellung finden Sie unter Fehlgeschlagenen Knoten zurücksetzen.

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care. Weitere Informationen zu Supportressourcen finden Sie unter Support erhalten, einschließlich der folgenden:

Anforderungen für das Erstellen einer Supportanfrage.
Tools zur Fehlerbehebung, z. B. Umgebungskonfiguration, Logs und Messwerte.
Unterstützte Komponenten.

Cluster sichern

Mit dem Befehl bmctl backup cluster werden die etcd-Daten und PKI-Zertifikate des Clusters in einer TAR-Datei verpackt. Die etcd-Datenbank ist der zentrale Datenspeicher für alle Clusterdaten und enthält alle Kubernetes-Objekte und benutzerdefinierten Ressourcen, die zum Verwalten des Clusterstatus erforderlich sind. Die PKI-Zertifikate werden über TLS authentifiziert. Diese Daten werden von der Steuerungsebene des Clusters oder von einer der Steuerungsebenen für eine Hochverfügbarkeitsbereitstellung 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 Dateisichtbarkeit zu verhindern, verwendet der Sicherungsprozess von Google Distributed Cloud nur speicherinterne Dateien.

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.

Wenn Sie den Knoten-Agent auf Ihren Clustern installiert haben, muss das Verzeichnis /tmp auf dem Admin-Knoten und allen Zielknoten 12 GB freien Speicherplatz haben. Wenn Sie die Größe des Verzeichnisses /tmp für Ihre Zielknoten nicht ändern können, lesen Sie den Hilfeartikel Lokale Speicherkapazität für Zielknoten ändern. Wenn Sie die Größe des Verzeichnisses /tmp für den Admin-Knoten nicht ändern können, lesen Sie den Abschnitt Lokale Speicherkapazität für einen Admin-Knoten ändern.

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.
- Ersetzen Sie dabei ADMIN_KUBECONFIG durch den 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
```
Dabei gilt:
- 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 ist. Wenn Sie Ihren Cluster beispielsweise test nennen, hat der Namespace einen Namen wie cluster-test.
- Ersetzen Sie dabei ADMIN_KUBECONFIG durch den Pfad der kubeconfig-Datei für den Administratorcluster.

Prüfen Sie in der Befehlsausgabe im Abschnitt Status, ob Conditions vom Typ Reconciling ist.

Wie im folgenden Beispiel gezeigt, bedeutet ein Status von False für diese Conditions, dass der Cluster stabil und für die Sicherung bereit ist.

...
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
```
Dabei gilt:
- 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 Dateisichtbarkeit zu verhindern, verwendet der Wiederherstellungsprozess von Google Distributed Cloud nur speicherinterne Dateien.

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 zu 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.

Wenn die Wiederherstellung abgeschlossen ist, prüfen Sie mit den folgenden Schritten, ob sie erfolgreich war:

Führen Sie die folgenden Befehle aus, um die Knotenbereitschaft und die System-Pods zu prüfen, die mit der generierten kubeconfig-Datei ausgeführt werden:

Es gibt zwei Arten von etcd-Pods:
- etcd-HOST_NAME, der dem Haupt-etcd-Pod entspricht
- etcd-events-HOST_NAME, was dem Pod etcd-events entspricht
```
kubectl get pods -n kube-system --kubeconfig GENERATED_KUBECONFIG
kubectl get nodes --kubeconfig GENERATED_KUBECONFIG
```

Führen Sie für jeden etcd-Pod Folgendes aus, um den Zustand von etcd zu prüfen:

kubectl exec ETCD_POD_NAME -n kube-system \
    --kubeconfig GENERATED_KUBECONFIG \
    -- /bin/sh -c 'ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt --key=/etc/kubernetes/pki/etcd/peer.key \
    --cert=/etc/kubernetes/pki/etcd/peer.crt endpoint health'

Für ein fehlerfreies etcd-Mitglied sollte die Antwort so aussehen:

https://127.0.0.1:2379 is healthy: successfully committed proposal: took = 11.514177ms

Führen Sie für jeden etcd-events-Pod den folgenden Befehl aus, um den Zustand von etcd-events zu prüfen:

kubectl exec ETCD_EVENTS_POD_NAME -n kube-system \
    --kubeconfig GENERATED_KUBECONFIG \
    -- /bin/sh -c 'ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2382 \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt --key=/etc/kubernetes/pki/etcd/peer.key \
    --cert=/etc/kubernetes/pki/etcd/peer.crt endpoint health'

Für ein fehlerfreies etcd-events-Mitglied sollte die Antwort so aussehen:

https://127.0.0.1:2382 is healthy: successfully committed proposal: took = 14.308148ms

Fehlerbehebung

Wenn Sie Probleme mit dem Sichern oder Wiederherstellen haben, können Ihnen die folgenden Abschnitte bei der Fehlerbehebung helfen.

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

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

Während der Sicherung oder Wiederherstellung erhalten Sie möglicherweise Fehlermeldungen, die nicht sehr selbsterklärend sind oder nicht klar die nächsten Schritte angeben. Wenn die Workstation, auf der Sie den Befehl bmctl ausführen, nicht viel RAM hat, ist möglicherweise nicht genügend Arbeitsspeicher für die Sicherung oder Wiederherstellung verfügbar.

In Google Distributed Cloud Version 1.13 und höher kann der Parameter --use-disk im Befehl „backup“ verwendet werden. Um die Dateiberechtigungen beizubehalten, werden mit diesem Parameter die Berechtigungen der Dateien geändert. Daher muss der Nutzer, der den Befehl ausführt, ein Root-Nutzer sein (oder sudo verwenden).

Fehlende Berechtigungen für Dateien bei der Wiederherstellung

Nach einer erfolgreichen Wiederherstellung kann das Löschen des Bootstraps mit einer Fehlermeldung wie der folgenden fehlschlagen:

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

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

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

Aktualisierung des SSH-Schlüssels nach einer Sicherung bricht den Wiederherstellungsprozess ab

SSH-bezogene Vorgänge während der Wiederherstellung können fehlschlagen, wenn der SSH-Schlüssel nach der Sicherung aktualisiert wird. In diesem Fall ist der neue SSH-Schlüssel für die Wiederherstellung 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.

Für einen Knoten-Agent-Knoten kann kein Backup erstellt werden

Wenn Sie den Node-Agent verwenden und eine Fehlermeldung erhalten, dass beim Erstellen der Sicherung keine Archivdatei erstellt werden kann, sieht diese in etwa so aus:

  I0508 15:29:36.831790  657351 backup_cluster.go:255] Retrying backup node: 128.187.102.133, due to error: failed receive chunk data: rpc error: code = Unknown desc = archiver.CreateArchiveWithList
  failed: failed to create archive file: failed to copy data from file: var/lib/etcd-events/member/snap/db, file size: 26136576, copy bytes: 12478464,
  error: write /tmp/uploadFileTemp1561164777: no space left on device

Prüfen Sie, ob im Verzeichnis /tmp auf dem Admin-Knoten und allen Zielknoten 12 GB freier Speicherplatz vorhanden sind. Wenn Sie die Größe des Verzeichnisses /tmp für Ihre Zielknoten nicht ändern können, lesen Sie den Abschnitt Lokale Speicherkapazität für Node Agent-Sicherungen erhöhen.

Nachdem Sie bestätigt haben, dass im Verzeichnis /tmp für den Admin-Knoten und alle Zielknoten 12 GB freier Speicherplatz vorhanden sind, versuchen Sie die Sicherung noch einmal.