Fehlerbehebung beim Erstellen und Upgraden von Clustern

Auf dieser Seite wird gezeigt, wie Sie Probleme beim Erstellen, Aktualisieren und Größe Anpassen der Cluster in Anthos-Cluster auf VMware (GKE On-Prem) untersuchen.

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.

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

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    get pods | grep clusterapi-controllers

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

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 Anthos-Cluster auf VMware einen temporären Bootstrap-Cluster. Nach einer erfolgreichen Installation löscht Anthos-Cluster auf VMware den Bootstrap-Cluster. Es verbleiben dann Ihr Administratorcluster und Ihr Nutzercluster. Im Allgemeinen sollten Sie keinen Grund haben, mit dem Bootstrap-Cluster zu interagieren.

Wenn Sie --cleanup-external-cliuster=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.

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

Rufen Sie die Logs für einen Pod auf:

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs POD_NAME

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

Nach einer Installation generiert Anthos-Cluster auf VMware eine kubeconfig-Datei namens internal-cluster-kubeconfig-debug im Basisverzeichnis der 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:

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

Beschreiben Sie ein MachineDeployment, um dessen Logs aufzurufen:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machinedeployment MACHINE_DEPLOYMENT_NAME

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

Anthos-Cluster auf 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 upzugraden, und dieser Vorgang fehlschlägt, erstellt Anthos-Cluster auf VMware einen externen Snapshot des Bootstrap-Clusters. Dies ist ein vorübergehender Cluster, der zum Erstellen oder Upgraden 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 ansehen können, um Probleme beim Erstellen oder Aktualisieren von Clustern zu beheben. Die Protokolle werden in einer separaten Datei gespeichert. Beispiel:

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, ein Administrator- oder Nutzercluster zu aktualisieren und dieser Vorgang fehlschlägt, führt Anthos-Cluster auf 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

Anthos-Cluster auf VMware verwenden im Hintergrund den Kubernetes drain-Befehl 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.

In Anthos-Clustern auf VMware Version 1.13 können Sie Fehler über Kubernetes-Pod-Ereignisse prüfen.

Suchen Sie die Namen der Maschinen:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces

Prüfen Sie mit dem Befehl kubectl describe machine, ob Fehler vorliegen:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME

Hier ein Beispiel für eine Ausgabe:

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ühren Sie gkectl diagnose cluster aus, um eine detailliertere Analyse des Maschinenobjektstatus zu erhalten:

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

Speichern Sie das PDB und entfernen Sie es aus dem Cluster, bevor Sie ein Upgrade ausfü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/1.13/diagnose#overview_diagnose_snapshot

Weitere Informationen finden Sie unter Diagnose.

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 diese Befehle aus, um die kubeconfig-Datei des Nutzerclusters neu zu erstellen:

KUBECONFIG_SECRET_NAME=$(kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n USER_CLUSTER_NAME | grep admin-kubeconfig | cut -d' ' -f1)

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n USER_CLUSTER_NAME $KUBECONFIG_SECRET_NAME \
  -o jsonpath='{.data.kubeconfig\.conf}' | base64 -d | sed -r "s/kube-apiserver.*local\./USER_CLUSTER_VIP/" > new_user_kubeconfig

Dabei gilt:

USER_CLUSTER_VIP: der Wert der Nutzer-Master-VIP.
USER_CLUSTER_NAME: der Name des Nutzerclusters.
ADMIN_CLUSTER_KUBECONFIG: der Pfad der kubeconfig-Datei für Ihren Administratorcluster.