Diese Seite wurde von der Cloud Translation API übersetzt.

Nutzercluster sichern und wiederherstellen

In diesem Dokument wird gezeigt, wie Sie den etcd-Speicher für einen Nutzercluster sichern und wiederherstellen können. Diese Seite enthält auch ein Skript, mit dem Sie den etcd-Speicher eines Clusters automatisch sichern können.

Sie können eine Sicherungsdatei für die Wiederherstellung nach unvorhergesehenen Notfällen erstellen, die die etcd-Daten Ihres Clusters beschädigen könnten. Speichern Sie die Sicherungsdatei an einem Speicherort, der sich außerhalb des Clusters befindet und nicht von der Funktionsfähigkeit des Clusters abhängt.

Beschränkungen

Mit diesem Verfahren werden keine anwendungsspezifischen Daten gesichert.
Mit diesem Verfahren werden keine PersistentVolumes gesichert.
Nach dem Erstellen einer Sicherung geplante Arbeitslasten werden mit dieser Sicherung nicht wiederhergestellt.
Sie können einen Cluster nicht nach einem fehlgeschlagenen Upgrade wiederherstellen.
Mit diesem Verfahren wird ein gelöschter Cluster nicht wiederhergestellt.

Nutzercluster sichern

Eine Nutzercluster-Sicherung ist ein Snapshot des etcd-Speichers des Nutzerclusters. Der etcd-Speicher enthält alle zum Verwalten des Clusterstatus erforderlichen Kubernetes-Objekte und benutzerdefinierten Objekte. Der Snapshot enthält die Daten, die zum Neuerstellen der Komponenten und Arbeitslasten des Clusters erforderlich sind.

Welche Sicherungsschritte Sie ausführen, hängt davon ab, ob Controlplane V2 auf dem Nutzercluster aktiviert ist. Wenn Controlplane V2 aktiviert ist, wird die Steuerungsebene für den Nutzercluster auf dem Nutzercluster selbst ausgeführt. Wenn Steuerungsebene V2 nicht aktiviert ist, wird die Steuerungsebene für den Nutzercluster auf einem oder mehreren Knoten im Administratorcluster ausgeführt. Dieser wird als kubeception bezeichnet.

Ermitteln Sie mit dem folgenden Befehl, ob für den Cluster Controlplane V2 aktiviert ist:

kubectl get onpremuserclusters --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system -o jsonpath='{.items[0].spec.enableControlplaneV2}' && echo

Wenn die Ausgabe true ist, führen Sie die Schritte unter Controlplane V2 aus, um den Cluster zu sichern. Andernfalls führen Sie die Schritte unter Kubeception aus.

Kubeception

Starten Sie eine Shell im Container kube-etcd:
```
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG exec -it \
 kube-etcd-0 -c kube-etcd -n USER_CLUSTER_NAME \
 -- /bin/sh
```
Dabei gilt:
- ADMIN_CLUSTER_KUBECONFIG ist die kubeconfig-Datei des Administratorclusters.
- USER_CLUSTER_NAME ist der Name des Nutzerclusters.

Erstellen Sie in der Shell im Verzeichnis /tmp eine Sicherung mit dem Namen snapshot.db:

ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etcd.local.config/certificates/etcdCA.crt \
  --cert=/etcd.local.config/certificates/etcd.crt \
  --key=/etcd.local.config/certificates/etcd.key \
  snapshot save /tmp/snapshot.db

Geben Sie in der Shell exit ein, um die Shell zu beenden.

Kopieren Sie /tmp/snapshot.db aus dem kube-etcd-Container in das aktuelle Verzeichnis:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG cp \
  USER_CLUSTER_NAME/kube-etcd-0:/tmp/snapshot.db \
  --container kube-etcd snapshot.db

Steuerungsebene v2

Rufen Sie den Namen des etcd-Pods ab:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods \
 -n kube-system -l component=etcd,tier=control-plane -ojsonpath='{$.items[*].metadata.name}{"\n"}'

Dabei gilt:

USER_CLUSTER_KUBECONFIG ist die kubeconfig-Datei des Nutzerclusters.

Beispiel:

NAME          READY   STATUS    RESTARTS   AGE
etcd-uc1-cp1  1/1     Running   0          38m
etcd-uc1-cp2  1/1     Running   0          37m
etcd-uc1-cp3  1/1     Running   0          38m

Es kann mehrere etcd-Pods geben, z. B. 3 für Hochverfügbarkeitscluster. Für die Sicherung sollte jeder etcd-Pod funktionieren.

Starten Sie eine Shell im Container etcd:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG exec -it \
 POD_NAME -c etcd -n kube-system -- /bin/sh
```
Dabei gilt:
- POD_NAME ist der Name des etcd-Pods aus dem vorherigen Schritt.

Erstellen Sie in Ihrer Shell eine Sicherungsdatei mit dem Namen snapshot.db:

ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /tmp/snapshot.db

Geben Sie in der Shell exit ein, um die Shell zu beenden.

Kopieren Sie snapshot.db aus dem etcd-Container in das Basisverzeichnis der Workstation:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
 cp POD_NAME:/tmp/snapshot.db ~/snapshot.db \
 -c etcd -n kube-system

Kopieren Sie die Secrets aus dem PKI-Verzeichnis:
```
ssh -i NODE_NAME.key ubuntu@NODE_EXTERNAL_IP
sudo chmod -R 0644 /etc/kubernetes/pki/*
sudo chmod 0755 /etc/kubernetes/pki/etcd
exit
scp -ri NODE_NAME.key ubuntu@NODE_EXTERNAL_IP:/etc/kubernetes/pki ~/pki_NODE_NAME
```
Dabei gilt:
- NODE_NAME ist die Datei mit dem SSH-Schlüssel für den Knoten der Steuerungsebene.
- NODE_EXTERNAL_IP ist die IP-Adresse des Knotens der Nutzersteuerungsebene, von der Sie die Secrets kopieren möchten.
Hinweis: Kopieren Sie bei Clustern für hohe Verfügbarkeit die Secrets aus allen Knoten der Nutzersteuerungsebene anhand der Anleitung.

Nutzercluster aus einer Sicherung wiederherstellen (ohne Hochverfügbarkeit)

Bevor Sie eine Sicherungsdatei zur Wiederherstellung des etcd-Speichers Ihres Nutzerclusters verwenden können, müssen Sie den Cluster diagnostizieren und vorhandene Probleme beheben. Wenn Sie eine Sicherung verwenden, um einen problematischen Cluster wiederherzustellen, können dieselben Probleme wieder hervorgerufen oder verschlimmert werden. Weitere Unterstützung beim Wiederherstellen Ihrer Cluster erhalten Sie vom GKE on VMware-Supportteam.

In der folgenden Anleitung wird erläutert, wie Sie mit einer Sicherungsdatei einen Nutzercluster wiederherstellen, wenn die etcd-Daten des Clusters beschädigt wurden und der etcd-Pod des Nutzerclusters sich in einer Absturzschleife befindet.

Kubeception

Sie können die etcd-Daten wiederherstellen, indem Sie einen Hilfs-Pod bereitstellen, der die beschädigten Daten mit der Sicherung überschreibt. Der API-Server des Administratorclusters muss ausgeführt werden und der Planer des Administratorclusters muss neue Pods planen können.

Ermitteln Sie den Namen des Secrets, das von etcd im Nutzercluster verwendet wird:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG -n USER_CLUSTER_NAME \
   get secrets | grep kube-etcd-certs

Kopieren Sie das folgende Pod-Manifest in eine Datei mit dem Namen etcd-utility.yaml. Ersetzen Sie Folgendes:

NODE_NAME: Der Knoten, auf dem der kube-etcd-0-Pod ausgeführt wird.
ADMIN_CLUSTER_KUBECONFIG: Die kubeconfig-Datei des Administratorclusters.
USER_CLUSTER_NAME: Der Name des Nutzerclusters.
GKE_ON_PREM_VERSION: Die Version des Clusters, in der Sie die etcd-Wiederherstellung durchführen möchten (z. B. 1.5.0-gke.0).
KUBE_ETCD_SECRET_NAME: Der Name des Secrets, das von etcd im Nutzercluster verwendet wird, beginnend mit kube-etcd-certs.

apiVersion: v1
kind: Pod
metadata:
 name: etcd-utility-0
 namespace: USER_CLUSTER_NAME
spec:
 containers:
 - command: ["/bin/sh"]
   args: ["-ec", "while :; do echo '.'; sleep 5 ; done"]
   image: gcr.io/gke-on-prem-release/etcd-util:GKE_ON_PREM_VERSION
   name: etcd-utility
   volumeMounts:
   - mountPath: /var/lib/etcd
     name: data
   - mountPath: /etcd.local.config/certificates
     name: etcd-certs
 nodeSelector:
   kubernetes.googleapis.com/cluster-name: USER_CLUSTER_NAME
   kubernetes.io/hostname: NODE_NAME
 tolerations:
 - effect: NoExecute
   key: node.kubernetes.io/not-ready
   operator: Exists
   tolerationSeconds: 300
 - effect: NoExecute
   key: node.kubernetes.io/unreachable
   operator: Exists
   tolerationSeconds: 300
 - effect: NoSchedule
   key: node.kubernetes.io/unschedulable
   operator: Exists
 volumes:
 - name: data
   persistentVolumeClaim:
     claimName: data-kube-etcd-0
 - name: etcd-certs
   secret:
     defaultMode: 420
     secretName: KUBE_ETCD_SECRET_NAME

Stellen Sie den Hilfs-Pod bereit:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  create -f etcd-utility.yaml --namespace USER_CLUSTER_NAME

Kopieren Sie snapshot.db aus dem aktuellen Verzeichnis in das Stammverzeichnis des Hilfs-Pods:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG cp snapshot.db \
  USER_CLUSTER_NAME/etcd-utility-0:snapshot.db --container etcd-utility

Starten Sie eine Shell im Container etcd-utility:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG exec it \
  etcd-utility-0 --container etcd-utility --namespace USER_CLUSTER_NAME \
  -- bin/sh

Führen Sie in der Shell im Stammverzeichnis den folgenden Befehl aus, um einen neuen Ordner zu erstellen, der die Sicherung enthält:

ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etcd.local.config/certificates/etcdCA.crt \
  --cert=/etcd.local.config/certificates/etcd.crt \
  --key=/etcd.local.config/certificates/etcd.key \
  snapshot restore snapshot.db

Löschen Sie in der Shell die alten etcd-Daten:
```
rm -r var/lib/etcd/*
```
Kopieren Sie in der Shell die wiederhergestellten etcd-Daten an ihren permanenten Speicherort:
```
cp -r default.etcd/* var/lib/etcd/
```
Geben Sie in der Shell exit ein, um die Shell zu beenden.

Löschen Sie den abstürzenden etcd-Pod:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  delete pod kube-etcd-0 --namespace USER_CLUSTER_NAME

Verifizieren Sie, dass der etcd-Pod nicht mehr abstürzt.

Löschen Sie den Hilfs-Pod:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  delete pod etcd-utility-0 --namespace USER_CLUSTER_NAME

Entfernen Sie etcd-utility.yaml aus dem aktuellen Verzeichnis:
```
rm etcd-utility.yaml
```

Steuerungsebene v2

Sie können die etcd-Daten einzeln wiederherstellen. Stellen Sie dazu einen temporären etcd-Container bereit, der die beschädigten Daten mit der Sicherung überschreibt.

Rufen Sie eine Shell auf dem Knoten der Nutzersteuerungsebene ab:
```
ssh -i NODE_NAME.key ubuntu@NODE_EXTERNAL_IP
```

Beenden Sie in der Shell den Kubernetes API-Server und den etcd-Server:

sudo mv /etc/kubernetes/manifests/kube-apiserver.yaml /etc/kubernetes/manifests/etcd.yaml ~

Geben Sie in der Shell exit ein, um sie zu verlassen.

Führen Sie scp aus, um die Sicherungsdatei snapshot.db und die Secrets auf den Knoten der Nutzersteuerungsebene zu kopieren:

scp -i NODE_NAME.key ~/snapshot.db ubuntu@NODE_EXTERNAL_IP:/tmp/

chmod a+rw pki/
scp -ri NODE_NAME.key ~/pki_NODE_NAME ubuntu@NODE_EXTERNAL_IP:/etc/kubernetes/pki

Verwenden Sie in der Shell snapshot.db, um die etcd-Daten wiederherzustellen:

sudo docker run --rm -t \
-v /opt/data/var/lib:/var/lib \
-v /etc/kubernetes/pki/etcd:/etc/kubernetes/pki/etcd \
-v /tmp:/tmp \
--env ETCDCTL_API=3 \
gcr.io/gke-on-prem-release/etcd-util:GKE_ON_PREM_VERSION etcdctl \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
--data-dir=/opt/data/var/lib/etcd \
--name=NODE_NAME \
--initial-advertise-peer-urls=https://NODE_IP_ADDRESS:2380 \
--initial-cluster=NODE_NAME=https://NODE_IP_ADDRESS:2380 \
snapshot restore /tmp/snapshot.db

Dabei gilt:

GKE_ON_PREM_VERSION ist die GKE Enterprise-Version, die als Image-Tag verwendet wird
NODE_NAME ist der Name des Knotens, auf dem die Wiederherstellung ausgeführt wird.
NODE_IP_ADDRESS ist die IP-Adresse des betreffenden Knotens.

Fügen Sie der etcd-Manifestdatei unter dem Containerbefehl das Flag - --initial-cluster-state=new hinzu.

Beispiel:
```
containers:
      - command:
        - etcd
        ...
        - --initial-cluster-state=new
        ...
```

Starten Sie in der Shell die Server kube-apiserver und etcd:

sudo mv ~/etcd.yaml ~/kube-apiserver.yaml /etc/kubernetes/manifests/

Geben Sie in der Shell exit ein, um sie zu verlassen.

Nutzercluster aus einer Sicherung wiederherstellen (Hochverfügbarkeit)

Kubeception

In diesem Abschnitt wird gezeigt, wie Sie die etcd-Daten für einen Hochverfügbarkeits-Nutzercluster wiederherstellen.

In einem Hochverfügbarkeits-Nutzercluster dienen drei Knoten im Administratorcluster als Steuerungsebene für den Nutzercluster. Auf jedem dieser Knoten wird ein etcd-Pod ausgeführt, der etcd-Daten auf einem Speicher-Volume verwaltet.

Wenn zwei der etcd-Pods fehlerfrei sind und die Daten auf den zugehörigen Speicher-Volumes intakt sind, müssen Sie zur Wiederherstellung keine Sicherungsdatei verwenden. Das liegt daran, dass Sie noch ein etcd-Quorum haben.

Im seltenen Fall, dass zwei der etcd-Speichervolumes beschädigte Daten enthalten, müssen Sie die etcd-Daten mithilfe einer Sicherungsdatei wiederherstellen.

Damit Sie die Schritte in diesem Abschnitt ausführen können, müssen Sie bereits eine snapshot.db-Datei erstellt haben, wie unter Nutzercluster sichern beschrieben.

etcd-Pods und -Knoten auflisten

Listen Sie die etcd-Pods auf, die den etcd-Speicher für Ihren Nutzercluster verwalten. Diese Pods werden im Administratorcluster ausgeführt:
```
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods --namespace USER_CLUSTER_NAME \
--output wide | grep kube-etcd
```
Die Ausgabe zeigt die etcd-Pods und die Knoten, auf denen die Pods ausgeführt werden. Die in der Ausgabe angezeigten Knoten sind Knoten im Administratorcluster, die als Steuerungsebenen für den Nutzercluster dienen:
```
NAME              ...   NODE
kube-etcd-0       ...   xxx
kube-etcd-1       ...   yyy
kube-etcd-2       ...   zzz
```
Notieren Sie sich die Namen der Pods und die Knotennamen der Steuerungsebene für später.

Beachten Sie, dass jeder etcd-Pod den Namen kube-etcd, gefolgt von einer Nummer, hat. Diese Nummer wird als Mitgliedsnummer des Pods bezeichnet. Sie identifiziert den Pod als bestimmtes Mitglied des etcd-Clusters, der die Objektdaten für Ihren Nutzercluster enthält. In dieser Anleitung wird mit dem Platzhalter MEMBER_NUMBER auf die Mitgliedsnummer des etcd-Pods verwiesen.

Beachten Sie außerdem, dass jeder Pod in Ihrem etcd-Cluster auf einem eigenen Knoten ausgeführt wird.

Deployment der Hilfs-Pods vorbereiten

Speichern Sie ein Manifest für das PodDisruptionBudget (PDB) für den Kubernetes API-Server des Nutzerclusters. Löschen Sie dann das PDB.

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG get pdb --namespace USER_CLUSTER_NAME \
kube-apiserver-pdb --output yaml > kube-apiserver-pdb.yaml

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG delete pdb --namespace USER_CLUSTER_NAME \
kube-apiserver-pdb

Beenden Sie den Kubernetes API-Server und das etcd-Wartungs-Deployment. Damit verwenden keine Komponenten etcd während der Wiederherstellung:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG --namespace USER_CLUSTER_NAME \
scale --replicas 0 statefulset kube-apiserver

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG --namespace USER_CLUSTER_NAME \
scale --replicas 0 deployment gke-master-etcd-maintenance

Rufen Sie den Namen des Container-Images für Ihre etcd-Pods auf.

Dienstprogramm-Pods bereitstellen

Rufen Sie den Namen des etcd-Pods und den Namen des Knotens auf, auf dem der Pod läuft.
Speichern Sie das folgende Pod-Manifest im aktuellen Verzeichnis in einer Datei mit dem Namen etcd-utility-MEMBER_NUMBER.yaml:

 apiVersion: v1
 kind: Pod
 metadata:
   name: etcd-utility-MEMBER_NUMBER
   namespace: USER_CLUSTER_NAME
 spec:
   containers:
   - command: ["/bin/sh"]
     args: ["-ec", "while :; do echo '.'; sleep 5 ; done"]
     image: gcr.io/gke-on-prem-release/etcd-util:GKE_ON_PREM_VERSION
     name: etcd-utility
     volumeMounts:
     - mountPath: /var/lib/etcd
       name: data
     - mountPath: /etcd.local.config/certificates
       name: etcd-certs
   nodeSelector:
     kubernetes.googleapis.com/cluster-name: USER_CLUSTER_NAME
     kubernetes.io/hostname: NODE_NAME
   tolerations:
   - effect: NoExecute
     key: node.kubernetes.io/not-ready
     operator: Exists
     tolerationSeconds: 300
   - effect: NoExecute
     key: node.kubernetes.io/unreachable
     operator: Exists
     tolerationSeconds: 300
   - effect: NoSchedule
     key: node.kubernetes.io/unschedulable
     operator: Exists
   volumes:
   - name: data
     persistentVolumeClaim:
       claimName: data-kube-etcd-MEMBER_NUMBER
   - name: etcd-certs
     secret:
       defaultMode: 420
       secretName: KUBE_ETCD_SECRET_NAME

Das vorherige Manifest beschreibt einen Dienstprogramm-Pod, den Sie vorübergehend ausführen, um etcd-Daten wiederherzustellen.

Erstellen Sie den Hilfs-Pod in Ihrem Administratorcluster:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG apply -f etcd-utility-MEMBER_NUMBER.yaml

Kopieren Sie die Sicherungsdatei snapshot.db in das Stammverzeichnis Ihres Hilfs-Pods:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG cp snapshot.db \
USER_CLUSTER_NAME/etcd-utility-MEMBER_NUMBER:snapshot.db

Starten Sie eine Shell im Container etcd-utility im Hilfs-Pod:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG exec -it --namespace USER_CLUSTER_NAME \
etcd-utility-MEMBER_NUMBER --container etcd-utility -- bin/sh

Stellen Sie in der Shell im Stammverzeichnis mithilfe von snapshot.db die etcd-Daten wieder her:

ETCDCTL_API=3 etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etcd.local.config/certificates/etcdCA.crt \
--cert=/etcd.local.config/certificates/etcd.crt \
--key=/etcd.local.config/certificates/etcd.key \
--name=kube-etcd-MEMBER_NUMBER \
--initial-cluster=kube-etcd-0=https://kube-etcd-0.kube-etcd:2380,kube-etcd-1=https://kube-etcd-1.kube-etcd:2380,kube-etcd-2=https://kube-etcd-2.kube-etcd:2380 \
--initial-cluster-token=etcd-cluster-1 \
--initial-advertise-peer-urls=https://kube-etcd-MEMBER_NUMBER.kube-etcd:2380 \
snapshot restore snapshot.db

Mit dem vorherigen Befehl wurden etcd-Daten im Verzeichnis /kube-etcd-MEMBER_NUMBER.etcd gespeichert.

Löschen Sie in der Shell die alten etcd-Daten:
```
rm -r var/lib/etcd/*
```
Kopieren Sie in der Shell die wiederhergestellten etcd-Daten an ihren permanenten Speicherort:
```
cp -r kube-etcd-MEMBER_NUMBER.etcd/* var/lib/etcd/
```
Entfernen Sie in der Shell das temporäre etcd-Verzeichnis und die Sicherungsdatei:
```
rm -R kube-etcd-MEMBER_NUMBER.etcd/
rm snapshot.db
```
Geben Sie in der Shell exit ein, um die Shell zu beenden.

Löschen Sie den Hilfs-Pod:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG delete pod \
--namespace USER_CLUSTER_NAME etcd-utility-MEMBER_NUMBER

Komponenten neu starten

Nachdem Sie nun Ihre Hilfs-Pods bereitgestellt und gelöscht haben, müssen Sie einige Clusterkomponenten neu starten.

Starten Sie die Pods im StatefulSet kube-etcd neu:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG rollout restart statefulset \
--namespace USER_CLUSTER_NAME kube-etcd

Starten Sie die Kubernetes API-Server für Ihren Nutzercluster:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG scale statefulset --replicas 3 \
--namespace USER_CLUSTER_NAME kube-apiserver

Starten Sie das etcd-Wartungs-Deployment für Ihren Nutzercluster:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG scale deployment --replicas 1 \
--namespace=USER_CLUSTER_NAME  gke-master-etcd-maintenance

Stellen Sie das PDB für den Kubernetes API-Server wieder her:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONIFG apply -f kube-apiserver-pdb.yaml

Steuerungsebene v2

In diesem Abschnitt wird gezeigt, wie Sie die etcd-Daten für einen Hochverfügbarkeits-Nutzercluster wiederherstellen können.

Bei einem Hochverfügbarkeitsnutzercluster gibt es drei Knoten im Nutzercluster, die als Steuerungsebene für den Nutzercluster dienen. Auf jedem dieser Knoten wird ein etcd-Pod ausgeführt, der etcd-Daten auf einem Speicher-Volume verwaltet.

Im seltenen Fall, dass zwei der etcd-Speichervolumes beschädigte Daten enthalten, müssen Sie die etcd-Daten mithilfe einer Sicherungsdatei wiederherstellen.

Für die Schritte in diesem Abschnitt müssen Sie bereits eine Datei snapshot.db erstellt haben, wie unter Nutzercluster sichern beschrieben.

etcd-Pods und -Knoten auflisten

Listen Sie die etcd-Pods und ihren jeweiligen Knoten auf:
```
kubectl get pod --kubeconfig USER_CLUSTER_KUBECONFIG \
 -n kube-system -l component=etcd,tier=control-plane -o wide
```
Die Ausgabe zeigt die etcd-Pods und die Knoten, auf denen die Pods ausgeführt werden. Die in der Ausgabe angezeigten Knoten sind Knoten im Administratorcluster, die als Steuerungsebenen für den Nutzercluster dienen:
```
NAME           ...   NODE
etcd-xxx       ...   xxx
etcd-yyy       ...   yyy
etcd-zzz       ...   zzz
```
Notieren Sie sich die Namen der Pods und die Knotennamen der Steuerungsebene für später.

Beachten Sie, dass jeder etcd-Pod den Namen etcd-xxx hat, an den ein Knotenname angehängt ist. Das liegt daran, dass die etcd-Pods in Controlplane V2 als statischer Pod ausgeführt werden.

Wiederherstellung wird vorbereitet

Führen Sie scp aus, um die Sicherungsdatei snapshot.db auf alle Knoten der Nutzersteuerungsebene zu kopieren:
```
scp -i NODE_NAME.key ~/snapshot.db ubuntu@NODE_EXTERNAL_IP:/tmp/
```

Kopieren Sie die Secrets in den entsprechenden Knoten der Nutzersteuerungsebene:

chmod a+rw ~/pki_*
scp -ri NODE_NAME.key ~/pki_NODE_NAME/* ubuntu@NODE_EXTERNAL_IP:/opt/data/etc/kubernetes/pki/

Rufen Sie eine Shell auf dem Knoten der Nutzersteuerungsebene ab:
```
ssh -i NODE_NAME.key ubuntu@NODE_EXTERNAL_IP
```

Wiederherstellung wird durchgeführt

Rufen Sie den Namen des etcd-Pods und den Namen des Knotens auf, auf dem der Pod läuft.
Beenden Sie in der Shell den Kubernetes API-Server und den etcd-Server auf allen Knoten der Nutzersteuerungsebene:
```
sudo mv /etc/kubernetes/manifests/kube-apiserver.yaml /etc/kubernetes/manifests/etcd.yaml ~
```

Verwenden Sie in der Shell snapshot.db, um die etcd-Daten auf allen Knoten der Nutzersteuerungsebene wiederherzustellen:

sudo docker run --rm -t \
-v /opt/data/var/lib:/var/lib \
-v /etc/kubernetes/pki/etcd:/etc/kubernetes/pki/etcd \
-v /tmp:/tmp \
--env ETCDCTL_API=3 \
gcr.io/gke-on-prem-release/etcd-util:GKE_ON_PREM_VERSION etcdctl \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
--data-dir=/opt/data/var/lib/etcd \
--name=NODE_NAME \
--initial-advertise-peer-urls=https://NODE_IP_ADDRESS:2380 \
--initial-cluster=NODE1=https://NODE1_IP:2380,NODE2=https://NODE2_IP:2380,NODE3=https://NODE3_IP:2380 \
snapshot restore /tmp/snapshot.db

Dabei gilt:

GKE_ON_PREM_VERSION ist die GKE Enterprise-Version, die als Image-Tag verwendet wird
NODE_NAME ist der Name des Knotens, auf dem die Wiederherstellung ausgeführt wird.
NODE_IP_ADDRESS ist die IP-Adresse des betreffenden Knotens.
Geben Sie für das Flag --initial-cluster die Werte NODE1, NODE2, NODE3 und IP des jeweiligen Knotens ein. Sie können sie auch dem etcd-Manifest entnehmen.

Fügen Sie der etcd-Manifestdatei unter dem Containerbefehl das Flag - --initial-cluster-state=existing hinzu.

Beispiel:
```
containers:
      - command:
        - etcd
        ...
        - --initial-cluster-state=existing
        ...
```

Komponenten neu starten

Starten Sie in der Shell die Server kube-apiserver und etcd in allen Knoten der Nutzersteuerungsebene:
```
sudo mv ~/etcd.yaml ~/kube-apiserver.yaml /etc/kubernetes/manifests/
```
Geben Sie in der Shell exit ein, um sie zu verlassen.
Prüfen Sie, ob kube-apiserver und etcd auf allen Knoten der Nutzersteuerungsebene ausgeführt werden:
```
kubectl get pod --kubeconfig USER_CLUSTER_KUBECONFIG \
-n kube-system -l tier=control-plane
```

Automatische Clustersicherung

Sie können das hier angegebene Skript als Beispiel für die automatische Sicherung Ihrer Cluster verwenden. Beachten Sie, dass das folgende Skript nicht unterstützt wird und nur als Referenz zum Schreiben eines besseren, stabileren und vollständigeren Skripts verwendet werden sollte. Bevor Sie das Skript ausführen, geben Sie Werte für die fünf Variablen am Anfang des Skripts ein:

Kubeception

Setzen Sie BACKUP_DIR auf den Pfad, unter dem Sie die Sicherungen der Administrator- und Nutzerclusters speichern möchten. Dieser Pfad sollte nicht vorhanden sein.
Setzen Sie ADMIN_CLUSTER_KUBECONFIG auf den Pfad der kubeconfig-Datei des Administratorclusters.
Setzen Sie USER_CLUSTER_NAMESPACE auf den Namen des Nutzerclusters. Der Name des Nutzerclusters ist ein Namespace im Administratorcluster.
Setzen Sie EXTERNAL_IP auf die VIP, die Sie für den Dienst der Administrator-Steuerungsebene reserviert haben.
Legen Sie für SSH_PRIVATE_KEY den Pfad Ihres SSH-Schlüssels fest.
Wenn Sie ein privates Netzwerk verwenden, setzen Sie JUMP_IP auf die IP-Adresse des Jump-Servers Ihres Netzwerks.

#!/usr/bin/env bash

# Automates manual steps for taking backups of user and admin clusters.
# Fill in the variables below before running the script.

BACKUP_DIR=""                       # path to store user and admin cluster backups
ADMIN_CLUSTER_KUBECONFIG=""         # path to admin cluster kubeconfig
USER_CLUSTER_NAMESPACE=""           # user cluster namespace
EXTERNAL_IP=""                      # admin control plane node external ip - follow steps in documentation
SSH_PRIVATE_KEY=""                  # path to vsphere_tmp ssh private key - follow steps in documentation
JUMP_IP=""                          # network jump server IP - leave empty string if not using private network.

mkdir -p $BACKUP_DIR
mkdir $BACKUP_DIR/pki

# USER CLUSTER BACKUP

# Snapshot user cluster etcd
kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG} exec -it -n ${USER_CLUSTER_NAMESPACE} kube-etcd-0 -c kube-etcd -- /bin/sh -ec "export ETCDCTL_API=3; etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etcd.local.config/certificates/etcdCA.crt --cert=/etcd.local.config/certificates/etcd.crt --key=/etcd.local.config/certificates/etcd.key snapshot save ${USER_CLUSTER_NAMESPACE}_snapshot.db"
kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG} cp ${USER_CLUSTER_NAMESPACE}/kube-etcd-0:${USER_CLUSTER_NAMESPACE}_snapshot.db $BACKUP_DIR/user-cluster_${USER_CLUSTER_NAMESPACE}_snapshot.db 

# ADMIN CLUSTER BACKUP

# Set up ssh options
SSH_OPTS=(-oStrictHostKeyChecking=no -i ${SSH_PRIVATE_KEY})
if [ "${JUMP_IP}" != "" ]; then
  SSH_OPTS+=(-oProxyCommand="ssh -oStrictHostKeyChecking=no -i ${SSH_PRIVATE_KEY} -W %h:%p ubuntu@${JUMP_IP}")
fi

# Copy admin certs
ssh "${SSH_OPTS[@]}" ubuntu@${EXTERNAL_IP} 'sudo chmod -R +rw /etc/kubernetes/pki/*'
scp -r "${SSH_OPTS[@]}" ubuntu@${EXTERNAL_IP}:/etc/kubernetes/pki/* ${BACKUP_DIR}/pki/

# Snapshot admin cluster etcd
admin_etcd=$(kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG} get pods -n kube-system -l component=etcd,tier=control-plane -ojsonpath='{$.items[*].metadata.name}{"\n"}')
kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG} exec -it -n kube-system ${admin_etcd} -- /bin/sh -ec "export 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 admin_snapshot.db"
kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG} cp -n kube-system ${admin_etcd}:admin_snapshot.db $BACKUP_DIR/admin-cluster_snapshot.db

Steuerungsebene v2

Setzen Sie BACKUP_DIR auf den Pfad, unter dem Sie die Sicherungen der Administrator- und Nutzerclusters speichern möchten. Dieser Pfad sollte nicht vorhanden sein.
Setzen Sie ADMIN_CLUSTER_KUBECONFIG auf den Pfad der kubeconfig-Datei des Administratorclusters.
Legen Sie USER_CLUSTER_KUBECONFIG auf den Pfad der kubeconfig-Datei Ihres Nutzerclusters fest.
Setzen Sie EXTERNAL_IP auf die VIP, die Sie für den Dienst der Administrator-Steuerungsebene reserviert haben.
Legen Sie für SSH_PRIVATE_KEY den Pfad Ihres SSH-Schlüssels fest.
Wenn Sie ein privates Netzwerk verwenden, setzen Sie JUMP_IP auf die IP-Adresse des Jump-Servers Ihres Netzwerks.

#!/usr/bin/env bash

# Automates manual steps for taking backups of user and admin clusters.
# Fill in the variables below before running the script.

BACKUP_DIR=""                       # path to store user and admin cluster backups
ADMIN_CLUSTER_KUBECONFIG=""         # path to admin cluster kubeconfig
USER_CLUSTER_KUBECONFIG=""          # path to user cluster kubeconfig
EXTERNAL_IP=""                      # admin control plane node external ip - follow steps in documentation
SSH_PRIVATE_KEY=""                  # path to ssh private key - follow steps in documentation
JUMP_IP=""                          # network jump server IP - leave empty string if not using private network

mkdir -p $BACKUP_DIR
mkdir $BACKUP_DIR/pki

# USER CLUSTER BACKUP
user_etcd=$(kubectl --kubeconfig=${USER_CLUSTER_KUBECONFIG} get pods -n kube-system -l component=etcd,tier=control-plane -ojsonpath='{$.items[0].metadata.name}{"\n"}')
kubectl --kubeconfig=${USER_CLUSTER_KUBECONFIG} exec -it -n kube-system ${user_etcd} -c etcd -- /bin/sh -ec "export ETCDCTL_API=3; etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key snapshot save /tmp/${user_etcd}_snapshot.db"
kubectl --kubeconfig=${USER_CLUSTER_KUBECONFIG} cp kube-system/${user_etcd}:/tmp/${user_etcd}_snapshot.db $BACKUP_DIR/${user_etcd}_snapshot.db

# ADMIN CLUSTER BACKUP

# Set up ssh options
SSH_OPTS=(-oStrictHostKeyChecking=no -i ${SSH_PRIVATE_KEY})
if [ "${JUMP_IP}" != "" ]; then
  SSH_OPTS+=(-oProxyCommand="ssh -oStrictHostKeyChecking=no -i ${SSH_PRIVATE_KEY} -W %h:%p ubuntu@${JUMP_IP}")
fi

# Copy admin certs
ssh "${SSH_OPTS[@]}" ubuntu@${EXTERNAL_IP} 'sudo chmod -R +rw /etc/kubernetes/pki/*'
scp -r "${SSH_OPTS[@]}" ubuntu@${EXTERNAL_IP}:/etc/kubernetes/pki/* ${BACKUP_DIR}/pki/

# Snapshot admin cluster etcd
admin_etcd=$(kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG} get pods -n kube-system -l component=etcd,tier=control-plane -ojsonpath='{$.items[*].metadata.name}{"\n"}')
kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG} exec -it -n kube-system ${admin_etcd} -- /bin/sh -ec "export 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 /tmp/${admin_etcd}_snapshot.db"
kubectl --kubeconfig=${ADMIN_CLUSTER_KUBECONFIG} cp -n kube-system ${admin_etcd}:/tmp/${admin_etcd}_snapshot.db $BACKUP_DIR/${admin_etcd}_snapshot.db

Wiederherstellung prüfen

Führen Sie gkectl diagnose cluster aus, um zu prüfen, ob der Cluster erfolgreich wiederhergestellt wurde.

Nächste Schritte

Administratorcluster sichern und wiederherstellen
Clusterprobleme diagnostizieren
Erfahren Sie mehr über Auger, einem Open-Source-Tool zum Wiederherstellen einzelner Objekte aus etcd-Sicherungen