Nutzercluster sichern und wiederherstellen

In diesem Dokument wird gezeigt, wie Sie den etcd-Speicher für einen Nutzercluster sichern und wiederherstellen, der mit Google Distributed Cloud (nur Software) für VMware erstellt wurde. 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 unerwarteten 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.

Hinweis: Die Sicherung eines Nutzerclusters mit einem Sicherungstool eines Drittanbieters wie Veeam wird nicht unterstützt. Die Sicherung des Clusters mit einem Drittanbietertool kann zu unvorhergesehenen Fehlern bei Cluster-Vorgängen führen.

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 nach einem fehlgeschlagenen Upgrade nicht mehr wiederherstellen.

• Dieses Verfahren ist nicht zum Wiederherstellen gelöschter Cluster gedacht

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.

Weitere Informationen zu Einschränkungen finden Sie unter Inkompatibilität der Infrastruktur.

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 Schritte Sie für die Sicherung ausführen, hängt davon ab, ob die Steuerungsebene V2 im Nutzercluster aktiviert ist. Wenn die Steuerungsebene V2 aktiviert ist, wird die Steuerungsebene für den Nutzercluster im Nutzercluster selbst ausgeführt. Wenn die Steuerungsebene V2 nicht aktiviert ist, wird die Steuerungsebene für den Nutzercluster auf einem oder mehreren Knoten im Administratorcluster ausgeführt. Dies wird als Kubeception bezeichnet.

Führen Sie den folgenden Befehl aus, um festzustellen, ob die Steuerungsebene V2 für den Cluster aktiviert ist:

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

Wenn die Ausgabe true lautet, folgen Sie der Anleitung unter Controlplane V2, um den Cluster zu sichern. Andernfalls folgen Sie der Anleitung unter Kubeception.

Kubeception

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

2. Erstellen Sie in der Shell im /tmp-Verzeichnis 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
   

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

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

1. 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 können mehrere etcd-Pods vorhanden sein, z. B. 3 für HA-Cluster. Für die Sicherung müsste jeder etcd-Pod funktionieren.

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

3. Erstellen Sie in der 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
   

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

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

6. 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 Nutzer-Steuerungsebene, aus dem die Secrets kopiert werden sollen.
   Hinweis: Kopieren Sie bei HA-Clustern die Geheimnisse gemäß der Anleitung von allen Knoten der Nutzer-Steuerungsebene.

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

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.

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

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

3. Stellen Sie den Hilfs-Pod bereit:

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

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

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

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

7. Löschen Sie in der Shell die alten etcd-Daten:

   rm -r var/lib/etcd/*
   

8. Kopieren Sie in der Shell die wiederhergestellten etcd-Daten an ihren permanenten Speicherort:

   cp -r default.etcd/* var/lib/etcd/
   

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

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

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

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

12. Löschen Sie den Hilfs-Pod:

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

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

    rm etcd-utility.yaml
    

Steuerungsebene v2

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

1. Stellen Sie eine Shell-Verbindung zum Knoten der Nutzer-Steuerungsebene her:

   ssh -i NODE_NAME.key ubuntu@NODE_EXTERNAL_IP
   

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

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

4. Führen Sie scp aus, um die Sicherungsdatei snapshot.db und die Secrets in den Knoten der Nutzer-Steuerungsebene 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
   

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

   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 durchgeführt wird
   • NODE_IP_ADDRESS ist die IP-Adresse des besagten Knotens.

6. Fügen Sie das Flag - --initial-cluster-state=new in der etcd-Manifestdatei unter „container command“ hinzu.

   Beispiel:

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

7. Starten Sie in der Shell die Server „kube-apiserver“ und „etcd“:

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

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

Hinweis: Wenn events-etcd-Pods den Status CrashLoopBackOff haben, fügen Sie das Flag - --initial-cluster-state=new hinzu und starten Sie die Pods neu. Die Ereignisse sind dann nicht mehr synchron und Sie verlieren zuvor gespeicherte Ereignisse.

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

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

etcd-Pods und -Knoten auflisten

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

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

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

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

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

Hilfs-Pods bereitstellen

Wichtig: Führen Sie die Schritte in diesem Abschnitt für jeden Ihrer etcd-Pods aus.

1. Rufen Sie den Namen des etcd-Pods und den Namen des Knotens auf, auf dem der Pod läuft.

2. 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 obige Manifest beschreibt einen Hilfs-Pod, den Sie vorübergehend ausführen, um etcd-Daten wiederherzustellen.

1. Erstellen Sie den Hilfs-Pod in Ihrem Administratorcluster:

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

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

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

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

5. Löschen Sie in der Shell die alten etcd-Daten:

   rm -r var/lib/etcd/*
   

6. Kopieren Sie in der Shell die wiederhergestellten etcd-Daten an ihren permanenten Speicherort:

   cp -r kube-etcd-MEMBER_NUMBER.etcd/* var/lib/etcd/
   

7. Entfernen Sie in der Shell das temporäre etcd-Verzeichnis und die Sicherungsdatei:

   rm -R kube-etcd-MEMBER_NUMBER.etcd/
   rm snapshot.db
   

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

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

1. Starten Sie die Pods im StatefulSet kube-etcd neu:

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

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

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

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

In einem Hochverfügbarkeits-Nutzercluster dienen drei Knoten im Nutzercluster 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

Wichtig: Führen Sie die Schritte in den folgenden Abschnitten für jeden CP-Knoten Ihres Nutzerclusters aus.

1. Listen Sie die etcd-Pods und deren jeweilige 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
   

2. 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, gefolgt von einem Knotennamen, hat. Das liegt daran, dass in Controlplane V2 die etcd-Pods als statische Pods ausgeführt werden.

Wiederherstellung vorbereiten

1. Führen Sie scp aus, um die Sicherungsdatei snapshot.db auf alle Knoten der Nutzer-Steuerungsebene zu kopieren:

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

2. Kopieren Sie die Secrets in den entsprechenden Knoten der Nutzer-Steuerungsebene:

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

3. Stellen Sie eine Shell-Verbindung zum Knoten der Nutzer-Steuerungsebene her:

   ssh -i NODE_NAME.key ubuntu@NODE_EXTERNAL_IP
   

Wiederherstellung durchführen

1. Rufen Sie den Namen des etcd-Pods und den Namen des Knotens auf, auf dem der Pod läuft.

2. Beenden Sie in der Shell den Kubernetes API-Server und den etcd-Server auf allen Knoten der Nutzer-Steuerungsebene:

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

3. Stellen Sie in der Shell mithilfe von snapshot.db die etcd-Daten auf allen Knoten der Nutzer-Steuerungsebene wieder her:

   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 durchgeführt wird
   • NODE_IP_ADDRESS ist die IP-Adresse des besagten Knotens.
   • Geben Sie für das --initial-cluster-Flag die NODE1, NODE2, NODE3 und IP des jeweiligen Knotens ein. Sie können sie auch aus dem etcd-Manifest abrufen.

4. Fügen Sie das Flag - --initial-cluster-state=existing in der etcd-Manifestdatei unter „container command“ hinzu.

   Beispiel:

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

Komponenten neu starten

1. Starten Sie in der Shell die kube-apiserver- und etcd-Server in allen Knoten der Nutzer-Steuerungsebene:

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

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

3. Prüfen Sie, ob kube-apiserver und etcd auf allen Knoten der Nutzer-Steuerungsebene ausgeführt werden:

   kubectl get pod --kubeconfig USER_CLUSTER_KUBECONFIG \
   -n kube-system -l tier=control-plane
   

Hinweis: Wenn events-etcd-Pods den Status CrashLoopBackOff haben, fügen Sie das Flag - --initial-cluster-state=new hinzu und starten Sie die Pods neu. Die Ereignisse sind dann nicht mehr synchron und Sie verlieren zuvor gespeicherte Ereignisse.

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 den gkectl-Diagnosecluster 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