Fehlerbehebung beim Erstellen und Upgraden von Clustern

Auf dieser Seite wird beschrieben, wie Sie Probleme beim Erstellen, Upgraden und Anpassen der Größe von Clustern in GKE on VMware untersuchen können.

Standard-Logging-Verhalten für gkectl und gkeadm

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

  • Für gkectl ist die Standard-Logdatei /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log per Symlink mit der Datei logs/gkectl-$(date).log im lokalen Verzeichnis verknüpft, in dem Sie gkectl ausführen.

  • Für gkeadm befindet sich die Standard-Logdatei logs/gkeadm-$(date).log im lokalen Verzeichnis, in dem Sie gkeadm ausführen.

  • Die Ausführlichkeitsstufe -v5 (Standard) deckt alle Logeinträge ab, die vom Support-Team benötigt werden.

  • Die Logdatei enthält den ausgeführten Befehl und die Fehlermeldung.

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

Nicht-Standardstandorte für Logdateien festlegen

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 nicht gestartet wird, nachdem die Administrator-Steuerungsebene gestartet wurde, können Sie das Problem untersuchen. Dazu prüfen Sie die Logs des Pods der Cluster API-Controllers im Administratorcluster.

  1. Suchen Sie den Namen des Pods der Cluster API-Controllers:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
        get pods | grep clusterapi-controllers
    
  2. Sehen Sie sich die Logs des vsphere-controller-manager an. Geben Sie als Erstes den Pod an, aber keinen Container:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
        logs POD_NAME
    

    Die Ausgabe zeigt Ihnen, dass Sie einen Container angeben müssen, und gibt Ihnen die Namen der Container im Pod. Beispiel:

    ... a container name must be specified ...,
    choose one of: [clusterapi-controller-manager vsphere-controller-manager rbac-proxy]
    

    Wählen Sie einen Container aus und rufen Sie dessen Logs auf:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
        logs POD_NAME --container CONTAINER_NAME
    

Artcluster wird nicht gelöscht

Wenn Sie einen Administratorcluster erstellen, wird dabei ein kind-Cluster (auch Bootstrap-Cluster genannt) erstellt. Wenn der Vorgang des Administratorclusters abgeschlossen ist, wird der Cluster kind automatisch gelöscht.

Wenn die Fehlermeldung Failed to delete the kind cluster angezeigt wird, können Sie die folgenden Schritte auf Ihrer Administratorworkstation ausführen, um den Cluster kind manuell zu löschen:

  1. Rufen Sie die Container-ID kind ab:

    docker inspect --format="{{.Id}}" gkectl-control-plane
    
  2. Rufen Sie die Prozess-ID containerd-shim ab:

    sudo ps awx | grep containerd-shim | grep CONTAINER_ID | awk '{print $1}'
    
  3. Beenden Sie den Prozess:

    sudo kill -9 PROCESS_ID
    

Verwendung von govc zur Behebung von Problemen mit vSphere

Sie können govc verwenden, um Probleme mit vSphere zu untersuchen. Beispielsweise können Sie die Berechtigungen und den Zugriff für Ihre vCenter-Nutzerkonten bestätigen und vSphere-Logs erfassen.

Debugging mit den Logs des Bootstrap-Clusters

Während der Installation erstellt GKE on VMware einen temporären Bootstrap-Cluster. Nach einer erfolgreichen Installation löscht GKE on VMware den Bootstrap-Cluster, sodass Sie Ihren Administrator- und Nutzercluster haben. Im Allgemeinen sollten Sie keinen Grund haben, mit dem Bootstrap-Cluster zu interagieren.

Wenn Sie --cleanup-external-cluster=false an gkectl create cluster übergeben, wird der Bootstrap-Cluster nicht gelöscht und Sie können die Logs des Bootstrap-Clusters verwenden, um Installationsprobleme zu beheben.

  1. Suchen Sie die Namen der Pods, die im Namespace kube-system ausgeführt werden:

    kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system
    
  2. Rufen Sie die Logs für einen Pod auf:

    kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs POD_NAME
    
  3. Um die Logs direkt aus dem Bootstrap-Cluster abzurufen, können Sie den folgenden Befehl während der Clustererstellung, -aktualisierung und -upgrades ausführen:

    docker exec -it gkectl-control-plane bash
    

    Der Befehl öffnet ein Terminal im Container der gkectl-Steuerungsebene, der im Bootstrap-Cluster ausgeführt wird.

    Prüfen Sie die kubelet- und containerd-Logs mit den folgenden Befehlen und suchen Sie in der Ausgabe nach Fehlern oder Warnungen:

    systemctl status -l kubelet
    journalctl --utc -u kubelet
    systemctl status -l containerd
    journalctl --utc -u containerd
    

Rollback für einen Knotenpool nach einem Upgrade durchführen

Wenn Sie einen Nutzercluster upgraden und dann ein Problem mit den Clusterknoten feststellen, können Sie für ausgewählte Knotenpools ein Rollback auf die vorherige Version durchführen.

Das Rollback für ausgewählte Knotenpools wird für Ubuntu- und COS-Knotenpools unterstützt, aber nicht für Windows-Knotenpools.

Die Version eines Knotenpools kann mit der Version der Steuerungsebene des Nutzerclusters identisch oder eine Nebenversion älter sein. Wenn sich die Steuerungsebene beispielsweise in der Version 1.14 befindet, können die Knotenpools die Version 1.14 oder 1.13 haben.

Verfügbare Knotenpoolversionen ansehen

Angenommen, Sie haben kürzlich ein Upgrade Ihres Nutzerclusters und Ihrer Steuerungsebene von Version 1.13.1-gke.35 auf Version 1.14.0 aktualisiert und dabei ein Problem mit den aktualisierten Worker-Knoten festgestellt. Daher beschließen Sie, für einen oder mehrere Knotenpools ein Rollback auf die zuvor ausgeführte Version durchzuführen: 1.13.1-gke.35.

Prüfen Sie, ob die vorherige Version für ein Rollback verfügbar ist:

gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Die Ausgabe zeigt für jeden Knotenpool die aktuelle und die vorherige Version an. Beispiel:
user cluster version: 1.14.0-gke.x

node pools:
- pool-1:
  - version: 1.14.0-gke.x
  - previous version: 1.13.1-gke.35
- pool-2:
  - version: 1.14.0-gke.x
  - previous version: 1.13.1-gke.35

available node pool versions:
- 1.13.1-gke.35
- 1.14.0-gke.x

Rollback für Knotenpools durchführen

Sie können für einen Knotenpool ein Rollback nach dem anderen oder für mehrere Knotenpools in einem Schritt ein Rollback durchführen.

Legen Sie in der Konfigurationsdatei des Nutzerclusters in einem oder mehreren Knotenpools den Wert von gkeOnPremVersion auf die vorherige Version fest: 1.13.1-gke.35 in diesem Beispiel:

nodePools:
- name: pool-1
  cpus: 4
  memoryMB: 8192
  replicas: 3
  gkeOnPremVersion: 1.13.1-gke.35
  ...

Aktualisieren Sie den Cluster, um ein Rollback für die Knotenpools durchzuführen:

gkectl update cluster --config USER_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Prüfen Sie, ob das Rollback ausgeführt wird:

gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Die folgende Ausgabe zeigt beispielsweise, dass für pool-1 ein Rollback auf Version 1.13.1-gke.35 durchgeführt wurde.
user cluster version: 1.14.0-gke.x

node pools:
- pool-1:
  - version: 1.13.1-gke.35
  - previous version: 1.14.0-gke.x
- pool-2:
  - version: 1.14.0-gke.x
  - previous version: 1.13.1-gke.35

available node pool versions:
- 1.13.1-gke.35
- 1.14.0-gke.x

Upgrade auf eine neue Patchversion durchführen

Angenommen, das Problem wurde in einer neuen Patchversion, z. B. 1.14.1, behoben. Jetzt können Sie alle Knotenpools und die Steuerungsebene auf die neue Patchversion aktualisieren.

In der Konfigurationsdatei des Nutzerclusters:

  • Legen Sie den Wert von gkeOnPremVersion auf die neue Patchversion fest, in diesem Beispiel 1.14.1-gke.x.

  • Entfernen Sie für jeden Knotenpool das Feld gkeOnPremVersion oder legen Sie dafür den leeren String fest. Wenn für einen Knotenpool keine Version angegeben ist, wird standardmäßig die für den Cluster angegebene Version für den Knotenpool verwendet.

Beispiel:

gkeOnPremVersion: 1.14.1-gke.x

nodePools:
- name: pool-1
  cpus: 4
  memoryMB: 8192
  replicas: 3
  gkeOnPremVersion: ""
- name: pool-2
  cpus: 8
  memoryMB: 8192
  replicas: 2
  gkeOnPremVersion: ""

Führen Sie gkectl prepare und gkectl upgrade cluster aus, wie unter Upgrade von GKE on VMware beschrieben.

Überprüfen Sie die neue Clusterversion und sehen Sie sich die Versionen an, die jetzt für ein Rollback verfügbar sind:

gkectl version --cluster-name USER_CLUSTER_NAME --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Beispielausgabe:
user cluster version: 1.14.1-gke.y

node pools:
- pool-1:
  - version: 1.14.1-gke.y
  - previous version: 1.13.1-gke.35
- pool-2:
  - version: 1.14.1-gke.y
  - previous version: 1.13.1-gke.35

available node pool versions:
- 1.13.1-gke.35
- 1.14.0-gke.x
- 1.14.1-gke.y

Fehlerbehebung bei F5 BIG-IP-Problemen mithilfe der internen kubeconfig-Datei

Nach einer Installation generiert GKE on VMware eine kubeconfig-Datei mit dem Namen internal-cluster-kubeconfig-debug im Basisverzeichnis Ihrer Administrator-Workstation. Diese Datei „kubeconfig“ ist identisch mit der „kubeconfig“-Datei Ihres Administratorclusters, mit der Ausnahme, dass sie direkt auf den Steuerungsebenenknoten des Administratorclusters verweist, auf dem der Kubernetes API-Server ausgeführt wird. Sie können die Datei internal-cluster-kubeconfig-debug verwenden, um F5 BIG-IP-Probleme zu beheben.

Anpassen der Größe eines Nutzerclusters schlägt fehl

Wenn die Größenanpassung eines Nutzerclusters fehlschlägt:

  1. Suchen Sie die Namen der MachineDeployments und der Maschinen:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machinedeployments --all-namespaces
    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces
    
  2. Beschreiben Sie ein MachineDeployment, um dessen Logs aufzurufen:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machinedeployment MACHINE_DEPLOYMENT_NAME
  3. Prüfen Sie, ob auf neu erstellten Maschinen Fehler vorliegen:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME

Für die Clustergrößenanpassung können keine Adressen zugewiesen werden

Dieses Problem tritt auf, wenn nicht genügend IP-Adressen zur Größenanpassung eines Nutzerclusters verfügbar sind.

kubectl describe machine zeigt den folgenden Fehler an:

Events:
Type     Reason  Age                From                    Message
----     ------  ----               ----                    -------
Warning  Failed  9s (x13 over 56s)  machineipam-controller  ipam: no addresses can be allocated

Weisen Sie diesem Cluster weitere IP-Adressen zu, um dieses Problem zu beheben. Löschen Sie dann die betroffene Maschine:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete machine MACHINE_NAME

GKE on VMware erstellt eine neue Maschine und weist ihr eine der neu verfügbaren IP-Adressen zu.

Ausreichende Anzahl von zugewiesenen IP-Adressen, aber Maschine kann sich nicht beim Cluster registrieren

Dieses Problem kann auftreten, wenn ein IP-Adresskonflikt vorliegt. Beispiel: Eine IP-Adresse, die Sie für eine Maschine angegeben haben, wird für einen Load-Balancer verwendet.

Dieses Problem können Sie beheben, indem Sie Ihre Cluster-IP-Blockdatei aktualisieren, damit die Maschinenadressen nicht mit den Adressen in der Clusterkonfigurationsdatei in Konflikt stehen oder mit der Seesaw-IP-Blockdatei.

Snapshot wird automatisch erstellt, wenn das Erstellen oder Upgrade des Administratorclusters fehlschlägt.

Wenn Sie versuchen, einen Administratorcluster zu erstellen oder zu aktualisieren, und dieser Vorgang fehlschlägt, erstellt GKE on VMware einen externen Snapshot des Bootstrap-Clusters. Dies ist ein temporärer Cluster, der zum Erstellen oder Aktualisieren des Administratorclusters verwendet wird. Obwohl dieser Snapshot des Bootstrap-Clusters dem Snapshot ähnelt, der durch Ausführen des Befehls gkectl diagnose snapshot im Administratorcluster erstellt wird, wird dieser stattdessen automatisch ausgelöst. Dieser Snapshot des Bootstrap-Clusters enthält wichtige Debugging-Informationen für den Erstellungs- und Upgradeprozess des Administratorclusters. Bei Bedarf können Sie für den Google Cloud-Support diesen Snapshot bereitstellen.

Der externe Snapshot enthält Pod-Logs aus dem onprem-admin-cluster-controller, die Sie aufrufen können, um Probleme bei der Clustererstellung oder -upgrades zu beheben. Die Protokolle werden in einer separaten Datei gespeichert, z. B.:

kubectl_logs_onprem-admin-cluster-controller-6767f6597-nws8g_--container_onprem-admin-cluster-controller_--kubeconfig_.home.ubuntu..kube.kind-config-gkectl_--namespace_kube-system

Systemdiagnosen werden automatisch ausgeführt, wenn das Cluster-Upgrade fehlschlägt

Wenn Sie versuchen, einen Administrator- oder Nutzercluster zu aktualisieren, und dieser Vorgang fehlschlägt, führt GKE on VMware automatisch den Befehl gkectl diagnose cluster auf dem Cluster aus.

Übergeben Sie das Flag --skip-diagnose-cluster an gkectl upgrade, um die automatische Diagnose zu überspringen.

Upgradeprozess bleibt hängen

GKE on VMware verwendet im Hintergrund den Kubernetes-Befehl drain während eines Upgrades. Diese drain-Prozedur kann durch ein Deployment mit nur einem Replikat blockiert werden, für das ein PodDisruptionBudget (PDB) mit minAvailable: 1 erstellt wurde.

Ab Version 1.13 von GKE on VMware können Sie Fehler über Kubernetes-Pod-Ereignisse prüfen.

  1. Suchen Sie die Namen der Maschinen:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces
    
  2. Prüfen Sie mit dem Befehl kubectl describe machine, ob Fehler aufgetreten sind:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME

Hier ist eine Beispielausgabe:

Events:
  Type     Reason              Age    From                Message
  ----     ------              ----   ----                -------
  Warning  PodEvictionTooLong  3m49s  machine-controller  Waiting too long(12m10.284294321s) for pod(default/test-deployment-669b85c4cc-z8pz7) eviction.

Für eine detailliertere Analyse des Status der Maschinenobjekte führen Sie gkectl diagnose cluster aus:

...
Checking machineset...SUCCESS
Checking machine objects...FAILURE
    Reason: 1 machine objects error(s).
    Unhealthy Resources:
    Pod test-deployment-669b85c4cc-7zjpq: Pod cannot be evicted successfully. There is 1 related PDB.
...
Checking all poddisruptionbudgets...FAILURE
    Reason: 1 pod disruption budget error(s).
    Unhealthy Resources:
    PodDisruptionBudget test-pdb: default/test-pdb might be configured incorrectly, the total replicas(3) should be larger than spec.MinAvailable(3).
...
Some validation results were FAILURE or UNKNOWN. Check report above.

Um dieses Problem zu beheben, speichern Sie das PDB und entfernen Sie es aus dem Cluster, bevor Sie versuchen, ein Upgrade durchzuführen. Sie können das PDB nach Abschluss des Upgrades wieder hinzufügen.

Status von virtuellen Maschinen diagnostizieren

Wenn beim Erstellen der virtuellen Maschine ein Problem auftritt, führen Sie gkectl diagnose cluster aus, um eine Diagnose des VM-Status abzurufen.

Hier ein Beispiel für eine Ausgabe:


- Validation Category: Cluster Healthiness
Checking cluster object...SUCCESS
Checking machine deployment...SUCCESS
Checking machineset...SUCCESS
Checking machine objects...SUCCESS
Checking machine VMs...FAILURE
    Reason: 1 machine VMs error(s).
    Unhealthy Resources:
    Machine [NODE_NAME]: The VM's UUID "420fbe5c-4c8b-705a-8a05-ec636406f60" does not match the machine object's providerID "420fbe5c-4c8b-705a-8a05-ec636406f60e".
    Debug Information:
    null
...
Exit with error:
Cluster is unhealthy!
Run gkectl diagnose cluster automatically in gkectl diagnose snapshot
Public page https://cloud.google.com/anthos/clusters/docs/on-prem/latest/diagnose#overview_diagnose_snapshot

Weitere Informationen finden Sie unter Clusterprobleme diagnostizieren.

Fehlende kubeconfig-Datei des Nutzerclusters neu erstellen

In einigen Situationen kann es sein, dass Sie eine kubeconfig-Datei des Nutzerclusters neu erstellen möchten:

  • Wenn Sie versuchen, einen Nutzercluster zu erstellen, und der Erstellungsvorgang fehlschlägt und Sie die kubeconfig-Datei des Nutzerclusters haben möchten.
  • Wenn die kubeconfig-Datei des Nutzerclusters fehlt, z. B. nach dem Löschen.

Führen Sie den folgenden Befehl aus, um die kubeconfig-Datei des Nutzerclusters neu zu erstellen:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n admin \
  -o jsonpath='{.data.admin\.conf}' | base64 -d  > USER_CLUSTER_KUBECONFIG

Ersetzen Sie Folgendes:

  • USER_CLUSTER_KUBECONFIG: der Name der neuen kubeconfig-Datei für Ihren Nutzercluster.
  • ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei für Ihren Administratorcluster

Entfernen Sie nicht unterstützte Änderungen, um die Blockierung des Upgrades aufzuheben

Beim Upgrade von Clustern auf 1.16 oder frühere Versionen werden Änderungen an den meisten Feldern während des Upgrades im Hintergrund ignoriert. Das bedeutet, dass diese Änderungen während und nach dem Upgrade nicht wirksam werden.

Beim Upgrade von Nutzerclustern auf Version 1.28 oder höher validieren wir alle in der Konfigurationsdatei vorgenommenen Änderungen und geben einen Fehler für nicht unterstützte Änderungen zurück, anstatt sie einfach zu ignorieren. Wenn Sie beispielsweise versuchen, die automatische Knotenreparatur beim Upgrade eines Nutzerclusters auf 1.28 zu deaktivieren, schlägt das Upgrade mit der folgenden Fehlermeldung fehl:

failed to generate desired create config: failed to generate desired OnPremUserCluster from seed config: failed to apply validating webhook to OnPremUserCluster: the following changes on immutable fields are forbidden during upgrade: (diff: -before, +after):
   v1alpha1.OnPremUserClusterSpec{
    ... // 20 identical fields
    UsageMetering:         nil,
    CloudAuditLogging:     &{ProjectID: "syllogi-partner-testing", ClusterLocation: "us-central1", ServiceAccountKey: &{KubernetesSecret: &{Name: "user-cluster-creds", KeyName: "cloud-audit-logging-service-account-key"}}},
-   AutoRepair:            &v1alpha1.AutoRepairConfig{Enabled: true},
+   AutoRepair:            &v1alpha1.AutoRepairConfig{},
    CARotation:            &{Generated: &{CAVersion: 1}},
    KSASigningKeyRotation: &{Generated: &{KSASigningKeyVersion: 1}},
    ... // 8 identical fields
  }

Wenn Sie diesen Fehler umgehen müssen, können Sie das Problem folgendermaßen umgehen:

  • Machen Sie die gewünschte Änderung rückgängig und führen Sie das Upgrade dann noch einmal aus. Im vorherigen Szenario würden Sie beispielsweise die Änderungen an der Konfiguration AutoRepair zurücksetzen und dann gkectl upgrade noch einmal ausführen.
  • Alternativ können Sie Konfigurationsdateien generieren, die dem aktuellen Status des Clusters entsprechen. Dazu führen Sie gkectl get-config aus, aktualisieren die gkeOnPremVersion-Felder für den Cluster und die Knotenpools in der Konfigurationsdatei und führen dann gkectl upgrade noch einmal aus.

gkectl-Befehlsfehler bei Verwendung von VPC Service Controls

Wenn Sie VPC Service Controls verwenden, werden beim Ausführen einiger gkectl-Befehle wie "Validation Category: GCP - [UNKNOWN] GCP service: [Stackdriver] could not get GCP services" möglicherweise Fehler angezeigt. Fügen Sie Ihren Befehlen den Parameter --skip-validation-gcp hinzu, um diese Fehler zu vermeiden.