Cluster sichern und wiederherstellen

Auf dieser Seite wird beschrieben, wie Sie Sicherungen von GKE On-Prem-Administrator- und User-Clustern manuell erstellen und wiederherstellen können. Auf dieser Seite finden Sie auch ein Skript, mit dem Sie Ihre Cluster automatisch sichern können.

Sie sollten Back-ups erstellen, um nach vorhersehbaren Katastrophen beschädigte etcd-Daten und Secrets wiederherstellen zu können. Achten Sie darauf, Sicherungen außerhalb des Clusters an einem Ort zu speichern, der nicht von der Funktionsfähigkeit des Clusters abhängt. Wenn Sie die Sicherheit erhöhen möchten, sollten Sie auch eine Kopie der Sicherung erstellen.

Obwohl der Pod "etcd event", der in jedem Cluster ausgeführt wird, für die Wiederherstellung eines Nutzerclusters nicht entscheidend ist, können Sie zum Sichern einen ähnlichen Prozess ausführen.

Beschränkungen

• Das Sichern anwendungsspezifischer Daten ist mit diesem Feature nicht möglich.
• Secrets bleiben so lange gültig, bis Sie sie manuell rotieren.
• Nach dem Erstellen einer Sicherung geplante Arbeitslasten werden nicht mit dieser Sicherung wiederhergestellt.
• Derzeit ist eine Wiederherstellung nach fehlgeschlagenen Clusterupgrades nicht möglich.
• Mit diesem Verfahren wird ein gelöschter Cluster nicht wiederhergestellt.

Bekannte Probleme

Wenn Sie sudo-Befehle ausführen, kann der folgende Fehler auftreten:

sudo: unable to resolve host gke-admin-master-[CLUSTER_ID]

Fügen Sie in diesem Fall die folgende Zeile zur Datei /etc/hosts hinzu:

127.0.0.1 gke-admin-master-[CLUSTER_ID]

Sicherungen von Nutzerclustern

Eine Nutzercluster-Sicherung enthält einen Snapshot des etcd-Speichers des Nutzerclusters. Der etcd-Speicher eines Clusters enthält unter anderem alle Kubernetes-Objekte und alle benutzerdefinierten Objekte, die zur Verwaltung des Clusterstatus erforderlich sind. Dieser Snapshot enthält die Daten, die zum Neuerstellen der Komponenten und Arbeitslasten des Clusters erforderlich sind.

Nutzercluster sichern

Der etcd-Speicher eines Nutzerclusters ist auf seinem Knoten der Steuerungsebene gespeichert, auf den Sie mit der kubeconfig-Datei des Administratorclusters zugreifen können.

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

1. Stellen Sie eine Shell-Verbindung zum kube-etcd-Container her:

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] exec \
   -it -n [USER_CLUSTER_NAME] kube-etcd-0 -c \
   kube-etcd -- bin/sh

   Dabei gilt:

   • [ADMIN_CLUSTER_KUBECONFIG] ist die kubeconfig-Datei des Administratorclusters.
   • [USER_CLUSTER_NAME] ist der Name des Nutzerclusters. Insbesondere übergeben Sie einen Namespace im Administratorcluster, der nach dem Nutzercluster benannt ist.

2. 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=/etcd.local.config/certificates/etcdCA.crt \
   --cert=/etcd.local.config/certificates/etcd.crt --key=/etcd.local.config/certificates/etcd.key \
   snapshot save snapshot.db

3. Schließen Sie den Container:

   exit

4. Kopieren Sie die Sicherung mit kubectl cp aus dem kube-etcd-Container:

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] cp \
   [USER_CLUSTER_NAME]/kube-etcd-0:snapshot.db [DIRECTORY] -c kube-etcd

   Dabei ist [RELATIVE_DIRECTORY] ein Pfad, unter dem Sie Ihre Sicherung speichern möchten.

Sicherung eines Nutzerclusters wiederherstellen

• Bevor Sie eine Sicherung wiederherstellen, sollten Sie den Cluster diagnostizieren und vorhandene Probleme beheben. Durch das Wiederherstellen eines Back-ups in einem problematischen Cluster können Probleme wieder hergestellt oder verschlimmert werden. Wenden Sie sich an das Supportteam von GKE on-prem, um weitere Unterstützung bei der Wiederherstellung Ihrer Cluster zu erhalten.

• Wenn Sie einen HA-Nutzercluster erstellt haben, sollten Sie diese Schritte einmal pro Mitglied des etcd-Clusters ausführen. Sie können denselben Snapshot verwenden, wenn Sie die einzelnen etcd-Mitglieder wiederherstellen. Führen Sie diese Schritte nur aus, wenn sich alle Pods in einer Absturzschleife befinden. Dies deutet darauf hin, dass Daten beschädigt sind.

In Absturzschleife befindlicher etcd-Pod

In der folgenden Anleitung wird erläutert, wie Sie eine Sicherung wiederherstellen, wenn die Daten eines Nutzerclusters beschädigt sind und sich sein etcd-Pod in einer Absturzschleife befindet. Sie können eine Wiederherstellung durchführen, indem Sie einen etcd-Pod auf den Volumes des vorhandenen Pods bereitstellen und die beschädigten Daten mit der Sicherung überschreiben. Dabei muss der API-Server des Nutzerclusters ausgeführt werden und neue Pods planen können.

1. Kopieren Sie die unten stehende etcd-Pod-Spezifikation in eine Datei namens restore-etcd.yaml, nachdem Sie die folgenden Platzhalterwerte angegeben haben:

   • [MEMBER_NUMBER] ist der nummerierte Pod, den Sie wiederherstellen.
   • [NODE_NAME] ist der Knoten, auf dem der Pod [MEMBER_NUMBER[ ausgeführt wird.
   • [ADMIN_CLUSTER_KUBECONFIG] ist die kubeconfig-Datei des Administratorclusters.
   • [USER_CLUSTER_NAME] ist der Name des Nutzerclusters.

   • [DEFAULT_TOKEN] wird für die Authentifizierung verwendet. Sie können diesen Wert ermitteln, indem Sie den folgenden Befehl ausführen:

     kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
     -n [USER_CLUSTER_NAME] get pods kube-etcd-0 \
     -o yaml | grep default-token

   Hinweis: Der folgende Wert für image- setzt voraus, dass Sie die gcr.io-Registry verwenden. Ändern Sie den Image-Namen, wenn Sie eine private Registry verwenden.

   restore-etcd.yaml

   apiVersion: v1
   kind: Pod
   metadata:
     labels:
       Component: restore-etcd-[MEMBER_NUMBER]
     name: restore-etcd-0
     namespace: restore-etcd-[MEMBER_NUMBER]
   spec:
     restartPolicy: Never
     containers:
     - command: ["/bin/sh"]
       args: ["-ec", "while :; do echo '.'; sleep 5 ; done"]
       image: gcr.io/gke-on-prem-release/etcd:v3.2.24-1-gke.0
       imagePullPolicy: IfNotPresent
       name: restore-etcd
       terminationMessagePath: /dev/termination-log
       terminationMessagePolicy: File
       volumeMounts:
       - mountPath: /var/lib/etcd
         name: data
       - mountPath: /etcd.local.config/certificates
         name: etcd-certs
       - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
         name: [DEFAULT_TOKEN]
         readOnly: true
     dnsPolicy: ClusterFirst
     hostname: restore-etcd-0
     imagePullSecrets:
     - name: private-registry-creds
     nodeSelector:
       kubernetes.googleapis.com/cluster-name: [USER_CLUSTER_NAME]
       kubernetes.io.hostname: [NODE_NAME]
     priority: 0
     restartPolicy: Always
     schedulerName: default-scheduler
     securityContext: {}
     serviceAccount: default
     serviceAccountName: default
     subdomain: restore-etcd
     terminationGracePeriodSeconds: 30
     tolerations:
     - effect: NoExecute
       key: node.kubernetes.io/not-ready
       operator: Exists
       tolerationSeconds: 300
     - effect: NoExecute
       key: node.kubernetes.io/unreachable
       operator: Exists
       tolerationSeconds: 300
     volumes:
     - name: data
       persistentVolumeClaim:
         claimName: data-kube-etcd-[MEMBER_NUMBER]
     - name: etcd-certs
       secret:
         defaultMode: 420
         secretName: kube-etcd-certs
     - name: [DEFAULT_TOKEN]
       secret:
         defaultMode: 420
         secretName: [DEFAULT_TOKEN]

2. Stellen Sie den Pod bereit:

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
   -n [USER_CLUSTER_NAME] create -f restore-etcd.yaml

3. Kopieren Sie die Sicherungsdatei des etcd-Speichers, snapshot.db, in den neuen Pod. snapshot.db befindet sich im relativen Verzeichnis, in dem Sie die Sicherung erstellt haben:

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
   cp [RELATIVE_DIRECTORY]/snapshot.db \
   [USER_CLUSTER_NAME]/restore-etcd-0:snapshot.db

4. Stellen Sie eine Shell-Verbindung zum restore-etcd-Pod her:

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
   -it -n [USER_CLUSTER_NAME] exec restore-etcd-0 -- bin/sh

5. Führen Sie den folgenden Befehl aus, um einen neuen default.etcd-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

6. Überschreiben Sie die beschädigten etcd-Daten mit der Sicherung:

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

7. Schließen Sie den Container:

   exit

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

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
   -n [USER_CLUSTER_NAME] delete pod kube-etcd-0

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

10. Entfernen Sie restore-etcd.yaml und löschen Sie den restore-etcd-Pod:

    rm restore-etcd.yaml;
    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
    -n [USER_CLUSTER_NAME] delete pod restore-etcd-0

Sicherungen von Administratorclustern

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:

1. Ermitteln Sie die externe IP-Adresse des Administratorclusters, die für die SSH-Verbindung zur Steuerungsebene des Administratorclusters verwendet wird:

   kubectl --kubeconfig [ADMIN_KUBECONFIG] get nodes -n kube-system -o wide | grep gke-admin-master

   Dabei ist [ADMIN_CLUSTER_KUBECONFIG] die kubeconfig-Datei des Administratorclusters.

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

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

4. Schließen Sie den Container:

   exit

Administratorcluster sichern

Sie können den etcd-Speicher eines Administratorclusters und die Secrets seiner Steuerungsebene sichern.

etcd

So sichern Sie den etcd-Speicher des Administratorclusters:

1. Rufen Sie den Namen des etcd-Pods ab:

   kubectl --kubeconfig [ADMIN_KUBECONFIG] get pods \
   -n kube-system | grep etcd-gke-admin-master

2. Stellen Sie eine Shell-Verbindung zum kube-etcd-Container des Pods her:

   kubectl --kubeconfig [ADMIN_KUBECONFIG]  exec -it \
   -n kube-system [ADMIN_ETCD_POD] -- bin/sh

   Dabei ist [ADMIN_ETCD_POD] der Name des etcd-Pods.

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

4. Schließen Sie den Container:

   exit

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

So sichern Sie die Secrets der Administrator-Steuerungsebene:

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

2. Erstellen Sie ein lokales Sicherungsverzeichnis. Dies ist optional, wird aber dringend empfohlen. Sie müssen die Berechtigungen der Sicherungs-Secrets ändern, um sie aus dem Knoten kopieren zu können:

   mkdir backup

3. Kopieren Sie die Secrets lokal in das lokale Sicherungsverzeichnis:

   sudo cp -r /etc/kubernetes/pki/* backup/

4. Ändern Sie die Berechtigungen der Sicherungs-Secrets:

   sudo chmod -R +rw backup/

5. Schließen Sie den Container:

   exit

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

   Dabei ist [RELATIVE_DIRECTORY] ein 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.

Hinweis: Der Nutzercluster kann seine Arbeitslasten auch dann ausführen, wenn die Nutzersteuerungsebene ausgefallen ist. Allerdings können bei einer ausgefallenen Nutzersteuerungsebene keine neuen oder aktualisierten Arbeitslasten geplant oder andere Clusterfehler behoben werden.

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

2. Stellen Sie eine Shell-Verbindung zur Administrator-Steuerungsebene her:

   sudo ssh -i vsphere_tmp ubuntu@[EXTERNAL_IP]

3. Kopieren Sie snapshot.db/ nach /mnt:

   sudo cp snapshot.db /mnt/

4. Erstellen Sie ein temporäres Verzeichnis wie backup:

   Hinweis: Dies ist nicht erforderlich, wenn bereits ein Sicherungsordner mit den Secrets vorhanden ist.

   mkdir backup

5. Schließen Sie die Administrator-Steuerungsebene:

   exit

6. Kopieren Sie die Zertifikate nach backup/:

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

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

8. Führen Sie kubeadm reset aus. Dadurch werden alle Vorgänge gestoppt, die noch im Administratorcluster ausgeführt werden. Alle etcd-Daten und die Secrets in /etc/kubernetes/pki/ werden gelöscht:

   sudo kubeadm reset --ignore-preflight-errors=all

9. Kopieren Sie die Sicherungs-Secrets nach /etc/kubernetes/pki/:

   sudo cp -r backup/* /etc/kubernetes/pki/

10. 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 'k8s.gcr.io/etcd-amd64:3.1.12' /bin/sh -c "etcdctl snapshot restore '/backup/snapshot.db'; mv /default.etcd/member/ /var/lib/etcd/"

11. Führen Sie kubeadm init aus. Dadurch werden alle Sicherungs-Secrets wiederverwendet und der etcd-Speicher wird mit dem wiederhergestellten Snapshot neu gestartet:

    sudo kubeadm init --config /etc/kubernetes/kubeadm_config.yaml --ignore-preflight-errors=DirAvailable--var-lib-etcd

12. Schließen Sie die Administrator-Steuerungsebene:

    exit

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

Back-up-Skript

Mit dem hier angegebenen Skript können Sie Ihre Cluster automatisch sichern. Bevor Sie das Skript ausführen, geben Sie Werte für die fünf Variablen am Anfang des Skripts ein.

Legen Sie für USER_CLUSTER_NAMESPACE den Namen des Nutzerclusters fest. 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.

#!/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 ssh private key - follow steps in documentation

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_snapshot.db $BACKUP_DIR/

# ADMIN CLUSTER BACKUP

# Copy admin certs
ssh -o StrictHostKeyChecking=no -i vsphere_tmp ubuntu@${EXTERNAL_IP} 'sudo chmod -R +rw /etc/kubernetes/pki/*'
scp -o StrictHostKeyChecking=no -r -i vsphere_tmp 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 -o=name | grep etcd | cut -c 5-)
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"

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:

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

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