Fehler beim Erstellen oder Upgraden von Clustern beheben

Auf dieser Seite erfahren Sie, wie Sie Probleme bei der Clustererstellung und -aktualisierung in Google Distributed Cloud (nur Software) für VMware untersuchen.

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

Installationsprobleme

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

Bootstrap-Cluster zum Beheben von Problemen verwenden

Während der Installation erstellt Google Distributed Cloud einen temporären Bootstrap-Cluster. Nach einer erfolgreichen Installation löscht Google Distributed Cloud den Bootstrap-Cluster, sodass Sie Ihren Administratorcluster und Nutzercluster behalten. Im Allgemeinen sollten Sie keinen Grund haben, mit dem Bootstrap-Cluster zu interagieren. Sollten während der Installation Probleme auftreten, können Sie die Bootstrap-Clusterlogs für die Fehlerbehebung verwenden.

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

Logs des Bootstrap-Clusters prüfen

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
   

   Ersetzen Sie POD_NAME durch den Namen des Pods, den Sie sich ansehen möchten.

3. Um die Logs direkt vom Bootstrap-Cluster abzurufen, führen Sie während der Clustererstellung und -aktualisierung den folgenden Befehl aus:

   docker exec -it gkectl-control-plane bash
   

   Dieser Befehl öffnet ein Terminal innerhalb des Containers gkectl-control-plane, der im Bootstrap-Cluster ausgeführt wird.

4. Prüfen Sie die Logs kubelet und containerd 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
   

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 durch Ausführen des Befehls gkectl diagnose snapshot im Administratorcluster erstellt wird, aber der Prozess wird automatisch ausgelöst. Der Bootstrap-Cluster-Snapshot enthält wichtige Debugging-Informationen für das Erstellen und Upgraden des Administratorclusters. Bei Bedarf können Sie für Cloud Customer Care diesen Snapshot bereitstellen.

Der externe Snapshot enthält Pod-Logs aus dem onprem-admin-cluster-controller, die Sie zum Beheben von Problemen beim Erstellen oder Aktualisieren von Clustern aufrufen können. Die Logs 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 startet nach dem Start der Administrator-Steuerungsebene nicht

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]
   

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

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

Probleme beim Clusterupgrade

In den folgenden Abschnitten finden Sie 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 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 niedriger sein. Wenn die Steuerungsebene beispielsweise Version 1.14 ist, können die Knotenpools die Version 1.14 oder 1.13 haben.

Verfügbare Knotenpoolversionen ansehen

Angenommen, Sie haben vor Kurzem ein Upgrade für die Worker-Knoten und Steuerungsebene Ihres Nutzerclusters von Version 1.13.1-gke.35 auf Version 1.14.0 ausgeführt und dabei ein Problem mit den aktualisierten Worker-Knoten festgestellt. Sie beschließen, einen oder mehrere Knotenpools auf die zuvor ausgeführte Version zurückzusetzen: 1.13.1-gke.35. 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 anzusehen:

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

Die Ausgabe zeigt die aktuelle Version 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 ein Rollback für die Version eines Knotenpools für einzelne Knotenpools durchführen oder mehrere Knotenpools in einem einzigen Schritt zurücksetzen.

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

1. Legen Sie in der Konfigurationsdatei des Nutzerclusters in einem oder mehreren Knotenpools den Wert von gkeOnPremVersion auf die vorherige Version. Im folgenden Beispiel erfahren Sie, 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
     ...
   

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

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

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

Upgrade auf eine neue Patchversion ausführen

Sie können alle Knotenpools und die Steuerungsebene auf eine neue Patchversion aktualisieren. Dies kann hilfreich sein, wenn Sie ein Rollback zu einer vorherigen 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:

1. Nehmen Sie die folgenden Änderungen in der Konfigurationsdatei des Nutzerclusters vor:

   1. Legen Sie den Wert von gkeOnPremVersion auf eine neue Patchversion fest. Dieses Beispiel verwendet 1.14.1-gke.x.

   2. Entfernen Sie für jeden Knotenpool das Feld gkeOnPremVersion oder legen Sie ihn 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: ""
      

2. Führen Sie gkectl prepare und gkectl upgrade cluster aus, wie unter Google Distributed Cloud aktualisieren beschrieben.

3. 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 gkectl diagnose cluster-Befehl im Cluster aus.

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

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 ein PodDisruptionBudget (PDB) mit minAvailable: 1 erstellt wurde.

Ab Google Distributed Cloud Version 1.13 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. Suchen Sie mit dem Befehl kubectl describe machine nach Fehlern:

   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.
   

3. Optional: Führen Sie für eine detailliertere Analyse des Maschinenobjektstatus den folgenden Befehl aus: gkectl diagnose cluster

   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.
   

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

Nicht unterstützte Änderungen entfernen, um die Blockierung des Upgrades aufzuheben

Beim Upgrade von Clustern auf Version 1.16 oder früher werden Änderungen an den meisten Feldern während des Upgrades unbemerkt 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 Änderungen, die in der Konfigurationsdatei vorgenommen wurden, und geben einen Fehler für nicht unterstützte Änderungen 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 unbemerkt ignoriert und nach dem Upgrade nicht wirksam.

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
  }

Sie können diesen Fehler so umgehen:

• Setzen Sie die versuchte Änderung zurück und führen Sie das Upgrade noch einmal aus. Beispiel: Im vorherigen Szenario würden Sie die an der AutoRepair-Konfiguration vorgenommenen Änderungen rückgängig machen und gkectl upgrade noch einmal ausführen.
• Alternativ können Sie Konfigurationsdateien generieren, die dem aktuellen Status des Clusters entsprechen, indem Sie gkectl get-config ausführen, die gkeOnPremVersion-Felder für den Cluster und die Knotenpools in der Konfigurationsdatei aktualisieren und gkectl upgrade noch einmal ausführen.

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

Nach einer Installation generiert Google Distributed Cloud 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.

Probleme mit vSphere beheben

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.

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.

Nächste Schritte

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