Cluster sichern und wiederherstellen

Auf dieser Seite wird beschrieben, wie Sie Cluster sichern und wiederherstellen, die mit Anthos-Cluster on Bare Metal erstellt wurden. Diese Anleitung gilt für alle Clustertypen, die von Anthos-Cluster on Bare Metal unterstützt werden.

Cluster sichern

Der Sicherungsvorgang besteht aus zwei Teilen. Zuerst wird ein Snapshot aus dem etcd-Speicher erstellt. Anschließend werden die zugehörigen PKI-Zertifikate in einer TAR-Datei gespeichert. 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.

Wir empfehlen, die Cluster regelmäßig zu sichern. Dies gewährleistet ist, dass Ihre Snapshot-Daten relativ aktuell sind. Die Rate der Sicherungen hängt von der Häufigkeit ab, mit der in den Clustern signifikante Änderungen vorgenommen werden.

Snapshot des etcd-Speichers erstellen

In Anthos-Cluster on Bare Metal führt ein Pod namens etcd-CONTROL_PLANE_NAME im Namespace kube-system den etcd-Speicher für diese Steuerungsebene aus. Um den etcd-Speicher des Clusters zu sichern, führen Sie die folgenden Schritte von Ihrer Administrator-Workstation aus:

Verwenden Sie zum Ermitteln des etcd-Pods kubectl get po.
```
kubectl --kubeconfig CLUSTER_KUBECONFIG get po -n kube-system \
    -l 'component=etcd,tier=control-plane'
```
Die Antwort enthält den Namen des etcd-Pods sowie seinen Status.
Verwenden Sie kubectl describe pod, um die im etcd-Pod ausgeführten Container einschließlich des etcd-Containers aufzurufen.
```
kubectl --kubeconfig CLUSTER_KUBECONFIG describe pod ETCD_POD_NAME -n kube-system
```

Führen Sie eine Bash-Shell im etcd-Container aus:

kubectl --kubeconfig CLUSTER_KUBECONFIG exec -it \
    ETCD_POD_NAME --container etcd --namespace kube-system \
    -- bin/sh

Verwenden Sie in der Shell innerhalb des etcd-Containers etcdctl (Version 3 der API), um einen Snapshot snapshot.db des etcd-Speichers zu speichern.
```
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt \
    --cert=/etc/kubernetes/pki/etcd/peer.crt \
    --key=/etc/kubernetes/pki/etcd/peer.key \
    snapshot save /tmp/snapshotDATESTAMP.db
```
Ersetzen Sie dabei DATESTAMP durch das aktuelle Datum, damit nachfolgende Snapshots nicht überschrieben werden.
Beenden Sie die Shell im Container und führen Sie den folgenden Befehl aus, um die Snapshot-Datei auf die Administrator-Workstation zu kopieren.
```
kubectl --kubeconfig CLUSTER_KUBECONFIG cp \
    kube-system/ETCD_POD_NAME:/tmp/snapshot.db \
    --container etcd snapshot.db
```

Kopieren Sie die Binärdatei etcdctl aus dem etcd-Pod, damit sie während der Wiederherstellung verwendet werden kann.

kubectl --kubeconfig CLUSTER_KUBECONFIG cp \
  kube-system/ETCD_POD_NAME:/usr/local/bin/etcdctl \
  --container etcd etcdctl

Speichern Sie die Snapshot-Datei und die Binärdatei etcdctl an einem Speicherort, der sich außerhalb des Clusters befindet und nicht von der Funktion des Clusters abhängig ist.

PKI-Zertifikate archivieren

Die zu sichernden Zertifikate befinden sich im Verzeichnis /etc/kubernetes/pki der Steuerungsebene. Die PIK-Zertifikate werden zusammen mit der etcd-Speicher-Datei snapshot.db benötigt, um einen Cluster wiederherzustellen, falls die Steuerungsebene vollständig ausfällt. Mit den folgenden Schritten erstellen Sie eine TAR-Datei, die die PKI-Zertifikate enthält.

Verwenden Sie ssh, um als Root eine Verbindung zur Steuerungsebene des Clusters herzustellen.
```
ssh root@CONTROL_PLANE_NAME
```
Erstellen Sie über die Steuerungsebene eine TAR-Datei certs_backup.tar.gz mit dem Inhalt des Verzeichnisses /etc/kubernetes/pki.
```
tar -czvf certs_backup.tar.gz -C /etc/kubernetes/pki .
```
Durch das Erstellen der TAR-Datei in der Steuerungsebene werden alle Berechtigungen der Zertifikatsdatei beibehalten.
Beenden Sie die Steuerungsebene und kopieren Sie von der Workstation aus die TAR-Datei mit den Zertifikaten an einen bevorzugten Speicherort auf der Workstation.
```
sudo scp root@CONTROL_PLANE_NAME:certs_backup.tar.gz BACKUP_PATH
```

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.

Der Wiederherstellungsvorgang für Cluster besteht aus zwei Teilen. Zuerst werden die PKI-Zertifikate auf der Steuerungsebene wiederhergestellt. Anschließend werden die etcd-Speicherdaten wiederhergestellt.

PKI-Zertifikate wiederherstellen

Unter der Annahme, dass Sie die PKI-Zertifikate wie unter PKI-Zertifikate archivieren beschrieben gesichert haben, beschreiben die folgenden Schritte, wie Sie die Zertifikate aus der tar-Datei auf einer Steuerungsebene wiederherstellen.

Kopieren Sie die TAR-Datei certs_backup.tar.gz der PKI-Zertifikate von der Workstation in die Steuerungsebene des Clusters.
```
sudo scp -r BACKUP_PATH/certs_backup.tar.gz root@CONTROL_PLANE_NAME:~/
```
Verwenden Sie ssh, um als Root eine Verbindung zur Steuerungsebene des Clusters herzustellen.
```
ssh root@CONTROL_PLANE_NAME
```
Extrahieren Sie den Inhalt der TAR-Datei über die Steuerungsebene in das Verzeichnis /etc/kubernetes/pki.
```
tar -xzvf certs_backup.tar.gz -C /etc/kubernetes/pki/
```
Beenden Sie die Steuerungsebene.

etcd-Speicher wiederherstellen

Bei der Wiederherstellung des etcd-Speichers hängt der Vorgang davon ab, ob der Cluster im Modus für Hochverfügbarkeit ausgeführt wird und, wenn dies der Fall ist, ob ein Quorum vorhanden ist. Folgen Sie der nachstehenden Anleitung, um den etcd-Speicher für eine bestimmte Clusterfehlersituation wiederherzustellen:

Wenn der fehlgeschlagene Cluster nicht im Hochverfügbarkeitsmodus ausgeführt wird, stellen Sie den etcd-Speicher auf der Steuerungsebene mit den unten aufgeführten Schritten wieder her.
Wenn der Cluster im Hochverfügbarkeitsmodus ausgeführt wird und das Quorum vorhanden wird, ist keine Aktion erforderlich. Solange ein Quorum vorhanden ist, müssen Sie fehlgeschlagene Cluster nicht wiederherstellen.
Wenn der Cluster im Hochverfügbarkeitsmodus ausgeführt wird und das Quorum verloren geht, wiederholen Sie die folgenden Schritte, um den etcd-Speicher für alle fehlgeschlagenen Mitglieder wiederherzustellen.

Führen Sie die folgenden Schritte von der Workstation aus, um den etcd-Speicher auf einer Steuerungsebene für einen fehlgeschlagenen Cluster zu entfernen und wiederherzustellen:

Erstellen Sie ein /backup-Verzeichnis im Stammverzeichnis der Steuerungsebene:
```
ssh root@CONTROL_PLANE_NAME "mkdir /backup"
```
Dieser Schritt ist nicht unbedingt erforderlich, wird aber empfohlen. In den folgenden Schritten wird davon ausgegangen, dass Sie ein /backup-Verzeichnis erstellt haben.
Kopieren Sie die etcd-Snapshot-Datei snapshot.db und etcdctl von der Workstation in das Verzeichnis backup auf der Steuerungsebene des Clusters.
```
sudo scp snapshot.db root@CONTROL_PLANE_NAME:/backup
sudo scp etcdctl root@CONTROL_PLANE_NAME:/backup
```
Verwenden Sie SSH, um eine Verbindung zum Knoten der Steuerungsebene herzustellen:
```
ssh root@CONTROL_PLANE_NAME
```
Beenden Sie die etcd und kube-apiserver statischen Pods, indem Sie ihre Manifestdateien aus dem Verzeichnis /etc/kubernetes/manifests in das Verzeichnis /backup verschieben.
```
sudo mv /etc/kubernetes/manifests/etcd.yaml /backup/etcd.yaml
sudo mv /etc/kubernetes/manifests/kube-apiserver.yaml /backup/kube-apiserver.yaml
```
Entfernen Sie das etcd-Datenverzeichnis.
```
rm -rf /var/lib/etcd/
```

Führen Sie die Snapshot-Wiederherstellung etcdctl mit der gespeicherten Binärdatei aus.

sudo chmod +x /backup/etcdctl
sudo ETCDCTL_API=3 /backup/etcdctl \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt \
    --cert=/etc/kubernetes/pki/etcd/server.crt \
    --key=/etc/kubernetes/pki/etcd/server.key \
    --data-dir=/var/lib/etcd \
    --name=CONTROL_PLANE_NAME \
    --initial-advertise-peer-urls=https://CONTROL_PLANE_IP:2380 \
    --initial-cluster=CONTROL_PLANE_NAME=https://CONTROL_PLANE_IP:2380 \
    snapshot restore /backup/snapshot.db

Die Einträge für --name, --initial-advertise-peer-urls und --initial-cluster finden Sie in der Manifestdatei etcd.yaml, die in das Verzeichnis /backup verschoben wurde.

Achten Sie darauf, dass /var/lib/etcd neu erstellt wurde und in /var/lib/etcd/member ein neues Mitglied erstellt wird.
Ändern Sie den Inhaber des Verzeichnisses /var/lib/etcd/member in 2003. Ab Anthos-Cluster-auf-Bare-Metal-Release 1.10.0 wird der etcd-Container als Nicht-Root-Nutzer mit UID und GID 2003 ausgeführt.
```
sudo chown -R 2003:2003 /var/lib/etcd
```
Verschieben Sie die Manifeste „etcd“ und „kube-apiserver“ zurück in das Verzeichnis /manifests, sodass die statischen Pods neu gestartet werden können.
```
sudo mv /backup/etcd.yaml /etc/kubernetes/manifests/etcd.yaml
sudo mv /backup/kube-apiserver.yaml /etc/kubernetes/manifests/kube-apiserver.yaml
```

Führen Sie eine Bash-Shell im etcd-Container aus:

kubectl --kubeconfig CLUSTER_KUBECONFIG exec -it \
    ETCD_POD_NAME --container etcd --namespace kube-system \
    -- bin/sh

Prüfen Sie mit etcdctl, ob das hinzugefügte Mitglied korrekt funktioniert.

ETCDCTL_API=3 etcdctl --cert=/etc/kubernetes/pki/etcd/peer.crt  \
    --key=/etc/kubernetes/pki/etcd/peer.key \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt \
    --endpoints=CONTROL_PLANE_IP:2379 \
    endpoint health

Wenn Sie mehrere fehlgeschlagene Mitglieder wiederherstellen möchten, führen Sie nach der Wiederherstellung aller fehlgeschlagenen Mitglieder den Befehl mit den IP-Adressen der Steuerungsebene von allen wiederhergestellten Mitgliedern im Feld „--endpoints“ aus.

Beispiel:

ETCDCTL_API=3 etcdctl --cert=/etc/kubernetes/pki/etcd/peer.crt  \
    --key=/etc/kubernetes/pki/etcd/peer.key \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt \
    --endpoints=10.200.0.3:2379,10.200.0.4:2379,10.200.0.5:2379 \
    endpoint health

Bei erfolgreicher Ausführung für jeden Endpunkt sollte Ihr Cluster ordnungsgemäß funktionieren.

Fehlerbehebung

Wenn Sie Probleme mit dem Back-up- oder Wiederherstellungsvorgang haben, helfen Ihnen die folgenden Abschnitte bei der Fehlerbehebung.

Wenn Sie weitere Hilfe benötigen, wenden Sie sich an den Google-Support.

Fehlende Berechtigungen für Dateien während der Wiederherstellung

Nach einer erfolgreichen Wiederherstellungsaufgabe kann das Löschen von Bootstrap mit einer Fehlermeldung wie im folgenden Beispiel fehlschlagen:

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

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

Anthos-Cluster auf Bare-Metal-Version 1.14 und höher haben detailliertere Fehlermeldungen, für die Verzeichnisse geschrieben werden müssen. Prüfen Sie, ob die gemeldeten Verzeichnisse schreibbar sind, und aktualisieren Sie die Berechtigungen für Verzeichnisse nach Bedarf.

SSH-Schlüssel nach einer Sicherung aktualisieren

SSH-bezogene Vorgänge während des Wiederherstellungsvorgangs 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 Wiederherstellungsvorgang 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.