Cluster sichern und wiederherstellen

Auf dieser Seite wird gezeigt, wie Sie Cluster sichern und wiederherstellen, die mit dem privaten Modus von Anthos erstellt wurden. Diese Anleitung gilt für alle Clustertypen, die vom privaten Anthos-Modus unterstützt werden.

Warnung: Die Verwendung einer Sicherungsdatei zum Wiederherstellen Ihrer etcd-Daten sollte das letzte Mittel sein. Wir empfehlen, die Wiederherstellung aus einer Sicherungsdatei nur dann auszuführen, wenn der Cluster vollständig fehlerhaft ist. Wenden Sie sich an den Google-Support, wenn Sie Hilfe bei der Entscheidung benötigen.

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 eine 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

Im privaten Anthos-Modus führt ein Pod mit dem Namen 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:

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

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

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

4. 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/healthcheck-client.crt \
       --key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
       snapshot save snapshotDATESTAMP.db
   

   Ersetzen Sie dabei DATESTAMP durch das aktuelle Datum, damit nachfolgende Snapshots nicht überschrieben werden.

5. 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:snapshot.db \
       --container etcd snapshot.db
   

6. Speichern Sie die Snapshot-Datei an einem Speicherort, der sich außerhalb des Clusters befindet und nicht von der Funktionsfähigkeit des Clusters abhängt.

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.

1. Verwenden Sie ssh, um als Root eine Verbindung zur Steuerungsebene des Clusters herzustellen.

   ssh root@CONTROL_PLANE_NAME
   

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

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

1. 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:~/
   

2. Verwenden Sie ssh, um als Root eine Verbindung zur Steuerungsebene des Clusters herzustellen.

   ssh root@CONTROL_PLANE_NAME
   

3. 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/
   

4. 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:

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

2. Kopieren Sie die etcd-Snapshot-Datei snapshot.db von der Workstation in das Verzeichnis backup auf der Steuerungsebene des Clusters.

   sudo scp snapshot.db root@CONTROL_PLANE_NAME:/backup
   

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

4. Entfernen Sie das etcd-Datenverzeichnis.

   rm -rf /var/lib/etcd/
   

5. Führen Sie die etcdctl Snapshot-Wiederherstellung mit docker aus.

   sudo docker run --rm -t \
       -v /var/lib:/var/lib \
       -v /etc/kubernetes/pki/etcd:/etc/kubernetes/pki/etcd \
       -v /backup:/backup \
       --env ETCDCTL_API=3 \
       k8s.gcr.io/etcd:3.2.24 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.

6. Achten Sie darauf, dass /var/lib/etcd neu erstellt wurde und in /var/lib/etcd/member ein neues Mitglied erstellt wird.

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

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

   ETCDCTL_API=3 etcdctl --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt  \
       --key=/etc/kubernetes/pki/etcd/healthcheck-client.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/healthcheck-client.crt  \
       --key=/etc/kubernetes/pki/etcd/healthcheck-client.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.