Anthos-Cluster auf VMware ist jetzt Google Distributed Cloud (nur Software) für VMware. Weitere Informationen finden Sie in der Produktübersicht.

Diese Seite wurde von der Cloud Translation API übersetzt.

Fehler beim Erstellen oder Upgraden von Clustern beheben

Auf dieser Seite wird beschrieben, wie Sie Probleme bei der Clustererstellung und -upgrades in Google Distributed Cloud untersuchen.

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.

Probleme bei der Installation

Die folgenden Abschnitte helfen Ihnen möglicherweise bei der Behebung von Problemen bei der Installation von Google Distributed Cloud.

Bootstrap-Cluster zum Beheben von Problemen verwenden

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 Ihr Administratorcluster und Ihr Nutzercluster übrig bleiben. Im Allgemeinen sollten Sie keinen Grund haben, mit dem Bootstrap-Cluster zu interagieren. Wenn während der Installation jedoch Probleme auftreten, können Sie die Bootstrap-Clusterlogs verwenden, um das Problem zu beheben.

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

Logs des Bootstrap-Clusters untersuchen

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
```
Ersetzen Sie POD_NAME durch den Namen des Pods, den Sie aufrufen möchten.
Führen Sie beim Erstellen, Aktualisieren und Upgraden des Clusters den folgenden Befehl aus, um die Logs direkt aus dem Bootstrap-Cluster abzurufen:
```
docker exec -it gkectl-control-plane bash
```
Mit diesem Befehl wird ein Terminal im gkectl-control-plane-Container geöffnet, der im Bootstrap-Cluster ausgeführt wird.
Verwenden Sie die folgenden Befehle, um die kubelet- und containerd-Logs zu prüfen und in der Ausgabe nach Fehlern oder Warnungen zu suchen:
```
systemctl status -l kubelet
journalctl --utc -u kubelet
systemctl status -l containerd
journalctl --utc -u containerd
```

Snapshot des Bootstrap-Clusters untersuchen

Wenn Sie versuchen, einen Administratorcluster zu erstellen oder zu aktualisieren, und dieser Vorgang fehlschlägt, erstellt Google Distributed Cloud einen externen Snapshot des Bootstrap-Clusters. Dieser Snapshot des Bootstrap-Clusters ähnelt dem Snapshot, der mit dem Befehl gkectl diagnose snapshot auf dem Administratorcluster erstellt wurde. Der Prozess wird jedoch automatisch ausgelöst. Der Bootstrap-Cluster-Snapshot enthält wichtige Informationen zur Fehlerbehebung für die Erstellung und das Upgrade des Administratorclusters. Sie können diesen Snapshot bei Bedarf Cloud Customer Care zur Verfügung stellen.

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

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

VM wird nach dem Start der Administrator-Steuerungsebene nicht gestartet

Wenn eine VM nach dem Start der Administrator-Steuerungsebene nicht gestartet werden kann, können Sie das Problem untersuchen. Sehen Sie sich dazu die Logs im Pod des Cluster-API-Controllers im Administratorcluster an:

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 zuerst den Pod, aber keinen Container an:
```
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

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.

Zum Beheben dieses Problems aktualisieren Sie die Cluster-IP-Blockdatei, sodass die Maschinenadressen nicht mit den in der Clusterkonfigurationsdatei oder der Seesaw-IP-Blockdatei angegebenen Adressen in Konflikt stehen.

Probleme beim Clusterupgrade

Die folgenden Abschnitte enthalten Tipps zum Beheben von Problemen, die während eines Clusterupgrades auftreten können.

Rollback eines Knotenpools 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 ausgewählter Knotenpools wird für Ubuntu- und COS-Knotenpools unterstützt, jedoch nicht für Windows-Knotenpools.

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

Verfügbare Knotenpoolversionen ansehen

Angenommen, Sie haben vor Kurzem ein Upgrade der Worker-Knoten Ihres Nutzerclusters und der Steuerungsebene von Version 1.13.1-gke.35 auf Version 1.14.0 durchgeführt und festgestellt, dass ein Problem mit den aktualisierten Worker-Knoten vorliegt. Sie beschließen daher, für einen oder mehrere Knotenpools ein Rollback auf die Version 1.13.1-gke.35 durchzuführen, die Sie zuvor ausgeführt haben. Bevor Sie mit dem Rollback beginnen können, müssen Sie prüfen, ob die vorherige Version für ein Rollback verfügbar ist.

Führen Sie den folgenden Befehl aus, um die verfügbaren Versionen aufzurufen:

gkectl version --cluster-name USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Die Ausgabe zeigt die aktuelle und die vorherige Version für jeden Knotenpool. 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 der Knotenpoolversion durchführen

Sie können für die Version eines Knotenpools einzeln oder für mehrere Knotenpools in einem Schritt ein Rollback durchführen.

Führen Sie die folgenden Schritte aus, um ein Rollback einer Knotenpoolversion durchzuführen:

Legen Sie in der Konfigurationsdatei des Nutzerclusters in einem oder mehreren Knotenpools den Wert von gkeOnPremVersion auf die vorherige Version fest. Das folgende Beispiel zeigt, wie Sie ein Rollback auf Version 1.13.1-gke.35 durchführen:
```
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 den oder die Knotenpools durchzuführen:

gkectl update cluster --config USER_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Prüfen Sie, ob das Rollback erfolgreich war:

gkectl version --cluster-name USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Die folgende Ausgabe zeigt, 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

Auf eine neue Patchversion aktualisieren

Sie können alle Knotenpools und die Steuerungsebene auf eine neue Patchversion aktualisieren. Dies kann hilfreich sein, wenn Sie ein Rollback auf eine frühere Version durchgeführt haben und ein Upgrade auf eine Version durchführen möchten, die eine Fehlerkorrektur enthält.

Führen Sie die folgenden Schritte aus, um ein Upgrade auf eine neue Version durchzuführen:

Nehmen Sie die folgenden Änderungen in der Konfigurationsdatei des Nutzerclusters vor:
1. Legen Sie den Wert von gkeOnPremVersion auf eine neue Patchversion fest. In diesem Beispiel wird 1.14.1-gke.x verwendet.
2. Entfernen Sie für jeden Knotenpool das Feld gkeOnPremVersion oder legen Sie es auf den leeren String fest. Wenn für einen Knotenpool keine Version angegeben ist, wird für den Knotenpool standardmäßig die Version verwendet, die für den Cluster angegeben ist.
  
  Diese Änderungen sehen in etwa so aus:
```
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 Google Distributed Cloud ausführen beschrieben.

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

gkectl version --cluster-name USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Die Ausgabe sieht in etwa so aus:

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

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 Google Distributed Cloud automatisch den Befehl gkectl diagnose cluster für den Cluster aus.

Wenn Sie die automatische Diagnose überspringen möchten, übergeben Sie das Flag --skip-diagnose-cluster an gkectl upgrade.

Upgradeprozess bleibt hängen

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

Ab Google Distributed Cloud 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

Mit dem Befehl kubectl describe machine können Sie nach Fehlern suchen:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME

Die Ausgabe sieht in etwa so aus:

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

Optional: Führen Sie gkectl diagnose cluster aus, um eine detailliertere Analyse des Status der Maschinenobjekte zu erhalten.

Die Ausgabe sieht in etwa so 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.

Speichern Sie das PDB und entfernen Sie es vor dem Upgrade aus dem Cluster, um dieses Problem zu beheben. Sie können das PDB dann nach Abschluss des Upgrades wieder hinzufügen.

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

Beim Upgrade von Clustern auf Version 1.16 oder frühere Versionen werden Änderungen an den meisten Feldern während des Upgrades unbemerkt ignoriert, sodass diese Änderungen weder während noch nach dem Upgrade wirksam werden.

Wenn Sie Nutzercluster auf Version 1.28 oder höher upgraden, prüfen wir alle Änderungen, die in der Konfigurationsdatei vorgenommen wurden, und geben bei nicht unterstützten Änderungen einen Fehler zurück, anstatt sie einfach zu ignorieren. Dieses Feature ist nur für Nutzercluster verfügbar. Beim Upgrade von Administratorclustern werden Änderungen an den meisten Feldern ignoriert und nach dem Upgrade nicht übernommen.

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, gibt es folgende Problemumgehungen:

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 AutoRepair-Konfiguration rückgängig machen und dann gkectl upgrade noch einmal ausführen.
Alternativ können Sie Konfigurationsdateien generieren, die dem aktuellen Status des Clusters entsprechen. Führen Sie dazu gkectl get-config aus, aktualisieren Sie die gkeOnPremVersion-Felder für den Cluster und die Knotenpools in der Konfigurationsdatei und führen Sie dann gkectl upgrade noch einmal aus.

F5 BIG-IP-Probleme mit der internen kubeconfig-Datei beheben

Nach einer Installation generiert GKE on VMware eine kubeconfig-Datei mit dem Namen internal-cluster-kubeconfig-debug im Basisverzeichnis Ihrer Administratorworkstation. 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.

Probleme mit vSphere beheben

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

Fehlende kubeconfig-Datei des Nutzerclusters neu erstellen

In den folgenden Situationen kann es sinnvoll sein, die Nutzercluster-Datei kubeconfig neu zu erstellen:

Wenn Sie versuchen, einen Nutzercluster zu erstellen, der Erstellungsvorgang fehlschlägt und Sie die Datei kubeconfig des Nutzerclusters haben möchten.
Wenn die Datei kubeconfig des Nutzerclusters fehlt, beispielsweise 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 Datei kubeconfig für Ihren Administratorcluster.

Nächste Schritte

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.