Version 1.5 Diese Version wird nicht mehr unterstützt, wie in der Supportrichtlinie für Anthos-Versionen beschrieben. Führen Sie ein Upgrade auf eine unterstützte Version durch, um die neuesten Patches und Updates für Sicherheitslücken, Kontakte und Probleme bei Anthos-Clustern in VMware (GKE On-Prem) zu erhalten. Die neueste Version finden Sie hier.

Verfügbare Versionen

Cluster sichern und wiederherstellen

Auf dieser Seite wird gezeigt, wie Sie den etcd-Speicher für einen Cluster 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 zur Wiederherstellung bei vorhersehbaren 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.

Führen Sie die folgenden Schritte aus, um einen Snapshot des etcd-Speichers zu erstellen:

Starten Sie eine Shell im Container kube-etcd:
```
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG exec -it \
   kube-etcd-0 --container kube-etcd --namespace 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 Stammverzeichnis 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 snapshot.db

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

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

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

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. Wenden Sie sich an das GKE On-Prem-Supportteam, um weitere Unterstützung bei der Wiederherstellung Ihrer Cluster zu erhalten.

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.

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.

Kopieren Sie das folgende Pod-Manifest in eine Datei mit dem Namen etcd-utility.yaml. Ersetzen Sie dabei diese Platzhalter durch entsprechende Werte:

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

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

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

Nutzercluster aus einer Sicherung wiederherstellen (Hochverfügbarkeit)

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

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.

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 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       ...   node-xxx
kube-etcd-1       ...   node-yyy
kube-etcd-2       ...   node-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

Erinnern Sie sich an den Namen des Container-Images für Ihre etcd-Pods.

Hilfs-Pods bereitstellen

Führen Sie die Schritte in diesem Abschnitt für jeden etcd-Pod aus.

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

Das obige Manifest beschreibt einen Hilfs-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 restart rollout 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

Administratorcluster sichern

Eine Administratorcluster-Sicherung enthält Folgendes:

Einen Snapshot des etcd-Speichers des Administratorclusters
Die Secrets der Administrator-Steuerungsebene, die für die Authentifizierung bei den Administrator- und Nutzerclustern erforderlich sind.

Führen Sie die folgenden Schritte aus, bevor Sie eine Administratorcluster-Sicherung erstellen:

Ermitteln Sie die externe IP-Adresse des Administratorclusters, die für die SSH-Verbindung zur Steuerungsebene des Administratorclusters verwendet wird:
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get nodes -n kube-system -o wide | grep master
```
Dabei ist [ADMIN_CLUSTER_KUBECONFIG] die kubeconfig-Datei des Administratorclusters.
Erstellen Sie aus dem privaten Schlüssel des Administratorclusters einen SSH-Schlüssel namens vsphere_tmp.

Sie finden den privaten Schlüssel in den Administratorcluster-Secrets:
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get secrets sshkeys -n kube-system -o yaml
```
In der Befehlsausgabe finden Sie den privaten Schlüssel im Feld vsphere_tmp.

Kopieren Sie den privaten Schlüssel in vsphere_tmp:
```
echo "[PRIVATE_KEY]" | base64 -d > vsphere_tmp; chmod 600 vsphere_tmp
```
Prüfen Sie, ob Sie mit diesem privaten Schlüssel eine Shell-Verbindung zur Administrator-Steuerungsebene herstellen können:
```
ssh -i vsphere_tmp ubuntu@[EXTERNAL_IP]
```
Schließen Sie den Container:
```
exit
```

etcd-Speicher eines Administratorclusters sichern

So sichern Sie den etcd-Speicher des Administratorclusters:

Rufen Sie den Namen des etcd-Pods ab:

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

Stellen Sie eine Shell-Verbindung zum kube-etcd-Container des Pods her:
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]  exec -it \
    -n kube-system [ADMIN_ETCD_POD] -- bin/sh
```
Dabei ist [ADMIN_ETCD_POD] der Name des etcd-Pods.

Verwenden Sie in der Shell etcdctl, um im lokalen Verzeichnis eine Sicherung mit dem Namen snapshot.db zu erstellen:

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

Schließen Sie den Container:
```
exit
```
Kopieren Sie die Sicherung mit kubectl cp aus dem kube-etcd-Container:
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] cp \
kube-system/[ADMIN_ETCD_POD]:snapshot.db [RELATIVE_DIRECTORY]
```
Dabei ist [RELATIVE_DIRECTORY] ein Pfad, unter dem Sie Ihre Sicherung speichern möchten.

Secrets eines Administratorclusters sichern

So sichern Sie die Secrets der Administrator-Steuerungsebene:

Verwenden Sie SSH, um eine Verbindung zum Knoten der Administrator-Steuerungsebene herzustellen:
```
ssh -i vsphere_tmp ubuntu@EXTERNAL_IP
```
Ersetzen Sie EXTERNAL_IP durch die externe IP-Adresse der Administrator-Steuerungsebene, die Sie zuvor notiert haben.
Optional, aber sehr empfehlenswert: Erstellen Sie ein lokales Sicherungsverzeichnis.

Sie müssen die Berechtigungen der Sicherungs-Secrets ändern, um sie aus dem Knoten kopieren zu können:
```
mkdir backup
```
Kopieren Sie die Secrets lokal in das lokale Sicherungsverzeichnis:
```
sudo cp -r /etc/kubernetes/pki/* backup/
```
Ändern Sie die Berechtigungen der Sicherungs-Secrets:
```
sudo chmod -R +rw backup/
```
Beenden Sie den Knoten der Administrator-Steuerungsebene:
```
exit
```
Führen Sie scp aus, um den Sicherungsordner aus dem Knoten der Administrator-Steuerungsebene zu kopieren:
```
sudo scp -r -i vsphere_tmp  ubuntu@EXTERNAL_IP:backup/ RELATIVE_DIRECTORY
```
Ersetzen Sie RELATIVE_DIRECTORY durch einen Pfad, unter dem Sie Ihre Sicherung speichern möchten.

Administratorcluster wiederherstellen

Im Folgenden werden ein gesicherter Administratorcluster und alle Nutzersteuerungsebenen, die er beim Erstellen des etcd-Snapshots verwaltet hat, neu erstellt.

Führen Sie scp aus, um snapshot.db in die Administrator-Steuerungsebene zu kopieren:
```
sudo scp -i vsphere_tmp snapshot.db ubuntu@[EXTERNAL_IP]:
```
Dabei ist [EXTERNAL_IP] die externe IP-Adresse der Administrator-Steuerungsebene, die Sie zuvor ermittelt haben.
Stellen Sie eine Shell-Verbindung zur Administrator-Steuerungsebene her:
```
sudo ssh -i vsphere_tmp ubuntu@[EXTERNAL_IP]
```
Kopieren Sie snapshot.db/ nach /mnt:
```
sudo cp snapshot.db /mnt/
```
Erstellen Sie ein temporäres Verzeichnis wie backup:

Hinweis: Dies ist nicht erforderlich, wenn bereits ein Sicherungsordner mit den Secrets vorhanden ist.
```
mkdir backup
```
Schließen Sie die Administrator-Steuerungsebene:
```
exit
```

Kopieren Sie die Zertifikate nach backup/:

sudo scp -r -i vsphere_tmp [BACKUP_CERT_FILE] ubuntu@[EXTERNAL_IP]:backup/

Stellen Sie eine Shell-Verbindung zum Knoten der Administrator-Steuerungsebene her:
```
ssh -i vsphere_tmp ubuntu@[EXTERNAL_IP]
```
Dabei ist [EXTERNAL_IP] die externe IP-Adresse der Administrator-Steuerungsebene, die Sie zuvor ermittelt haben.

Beenden Sie kube-etcd und kube-apiserver.

sudo mv /etc/kubernetes/manifests/etcd.yaml /tmp/etcd.yaml

sudo mv /etc/kubernetes/manifests/kube-apiserver.yaml /tmp/kube-apiserver.yaml

Kopieren Sie die Sicherungs-Secrets nach /etc/kubernetes/pki/:
```
sudo cp -r backup/* /etc/kubernetes/pki/
```

Führen Sie etcdctl restore mit Docker aus:

sudo docker run --rm \
-v '/mnt:/backup' \
-v '/var/lib/etcd:/var/lib/etcd' --env ETCDCTL_API=3 'gcr.io/gke-on-prem-release/etcd-util:GKE_ON_PREM_VERSION' /bin/sh -c "etcdctl snapshot restore '/backup/snapshot.db'; rm -r /var/lib/etcd/*; mv /default.etcd/member/ /var/lib/etcd/"

Starten Sie kube-etcd und kube-apiserver neu.

sudo mv /tmp/etcd.yaml /etc/kubernetes/manifests/etcd.yaml

sudo mv /tmp/kube-apiserver.yaml /etc/kubernetes/manifests/kube-apiserver.yaml

Schließen Sie die Administrator-Steuerungsebene:
```
exit
```
Kopieren Sie die neu erstellte kubeconfig-Datei aus dem Administratorknoten:
```
sudo scp -i vsphere_tmp ubuntu@[EXTERNAL_IP]:[HOME]/.kube/config kubeconfig
```
Dabei gilt:
- [EXTERNAL_IP] ist die externe IP-Adresse der Administrator-Steuerungsebene.
- [HOME] ist das Basisverzeichnis auf dem Administratorknoten.
Jetzt können Sie mit dieser neuen kubeconfig-Datei auf den wiederhergestellten Cluster zugreifen.

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.

Setzen Sie BACKUP_DIR auf den Pfad, unter dem Sie die Sicherungen der Administrator- und Nutzerclusters speichern möchten. Dieser Pfad sollte noch 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.
Setzen Sie SSH_PRIVATE_KEY auf den Pfad des SSH-Schlüssels, den Sie beim Einrichten Ihrer Administrator-Workstation erstellt haben.
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

Problembehebung

Weitere Informationen finden Sie unter Fehlerbehebung.

Clusterprobleme mit `gkectl` diagnostizieren

Verwenden Sie gkectl diagnose-Befehle, um Clusterprobleme zu identifizieren und Clusterinformationen an Google zu senden. Siehe Clusterprobleme diagnostizieren.

Standard-Logging-Verhalten

Für gkectl und gkeadm reicht es aus, die Standard-Logging-Einstellungen zu verwenden:

Standardmäßig werden Logeinträge so gespeichert:
- Für gkectl ist die Standard-Logdatei /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log. Die Datei ist per Symlink mit der Datei logs/gkectl-$(date).log im lokalen Verzeichnis verknüpft, in dem Sie gkectl ausführen.
- Für gkeadm ist die Standard-Logdatei logs/gkeadm-$(date).log im lokalen Verzeichnis, in dem Sie gkeadm ausführen.
Alle Logeinträge werden in der Logdatei gespeichert, auch wenn sie nicht im Terminal ausgegeben werden (wenn --alsologtostderr auf false gesetzt ist).
Die Ausführlichkeitsstufe -v5 (Standard) deckt alle Logeinträge ab, die vom Support-Team benötigt werden.
Die Logdatei enthält auch den ausgeführten Befehl und die Fehlermeldung.

Wir empfehlen Ihnen, die Logdatei an das Supportteam zu senden, wenn Sie Hilfe benötigen.

Nicht standardmäßigen Speicherort für die Logdatei angeben

Wenn Sie einen nicht standardmäßigen Speicherort für die Logdatei gkectl angeben möchten, verwenden Sie das Flag --log_file. Die von Ihnen angegebene Logdatei wird nicht per Symlink mit dem lokalen Verzeichnis verknüpft.

Wenn Sie einen nicht standardmäßigen Speicherort für die Logdatei gkeadm angeben möchten, verwenden Sie das Flag --log_file.

Cluster-API-Logs im Administratorcluster suchen

Wenn eine VM nach dem Start der Administrator-Steuerungsebene nicht gestartet wird, versuchen Sie, dies durch Untersuchen der Logs der Cluster-API-Controller im Administratorcluster zu beheben:

Suchen Sie im Namespace kube-system den Namen des Cluster-API-Controller-Pods, wobei [ADMIN_CLUSTER_KUBECONFIG] der Pfad zur kubeconfig-Datei des Administratorclusters ist:
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
```
Öffnen Sie die Logs des Pods, wobei [POD_NAME] der Name des Pods ist. Verwenden Sie optional grep oder ein ähnliches Tool für die Fehlersuche:
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager
```

Weitere Informationen

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