Fehlerbehebung bei Upgrades

Auf dieser Seite wird beschrieben, wie Sie Probleme bei Clusterupgrades von Google Kubernetes Engine (GKE) beheben.

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

Problem: kube-apiserver ist nach dem Upgrade der Steuerungsebene fehlerhaft

Das folgende Problem tritt auf, wenn Sie ein manuelles Upgrade der Steuerungsebene Ihrer GKE-Clusterversion starten. Einige vom Nutzer bereitgestellte Zulassungs-Webhooks können verhindern, dass Systemkomponenten zulässige RBAC-Rollen erstellen, die für eine ordnungsgemäße Funktion erforderlich sind. Während des Upgrades der Steuerungsebene erstellt Google Cloud die Komponente des Kubernetes API-Servers (kube-apiserver) neu. Wenn ein Webhook die RBAC-Rolle für die API-Serverkomponente blockiert, wird der API-Server nicht gestartet und das Clusterupgrade wird nicht abgeschlossen.

Die Fehlermeldung in der gcloud CLI sieht in etwa so aus:

FAILED: All cluster resources were brought up, but: component "KubeApiserverReady" from endpoint "readyz of kube apiserver is not successful" is unhealthy.

Um den fehlerhaften Webhook zu identifizieren, prüfen Sie Ihre GKE-Audit-Logs auf RBAC-Aufrufe mit den folgenden Informationen:

protoPayload.resourceName="RBAC_RULE"
protoPayload.authenticationInfo.principalEmail="system:apiserver"

RBAC_RULE ist der vollständige Name einer RBAC-Rolle, z. B. rbac.authorization.k8s.io/v1/clusterroles/system:controller:horizontal-pod-autoscaler.

Der Name des fehlgeschlagenen Webhooks wird im Log im folgenden Format angezeigt:

admission webhook WEBHOOK_NAME denied the request

Versuchen Sie Folgendes, um dieses Problem zu beheben:

  • Passen Sie Ihre Einschränkungen an, um das Erstellen und Aktualisieren von ClusterRoles mit dem Präfix system: zuzulassen.
  • Passen Sie Ihren Webhook so an, dass keine Anfragen zum Erstellen und Aktualisieren von System-RBAC-Rollen abgefangen werden.
  • Deaktivieren Sie den Webhook.

Wie ist das möglich?

Kubernetes macht einen automatischen Abgleich{track-name="k8sLink" track-type="troubleshooting"} der RBAC-Rollen des Standardsystems mit den Standardrichtlinien in der neuesten Nebenversion. Die Standardrichtlinien für Systemrollen ändern sich in neuen Kubernetes-Versionen manchmal.

Für diesen Abgleich erstellt oder aktualisiert GKE die ClusterRoles und ClusterRoleBindings im Cluster. Wenn Sie einen Webhook haben, der die Erstellungs- oder Aktualisierungsanfragen aufgrund des Umfangs der Berechtigungen, die die Standard-RBAC-Richtlinien verwenden, abfängt und ablehnt, kann der API-Server nicht mit der neuen Nebenversion funktionieren.

Problem: Nach dem Upgrade des Standard-Clusters entfernte Arbeitslasten

Ihre Arbeitslasten werden möglicherweise nach einem Clusterupgrade bereinigt, wenn alle folgenden Bedingungen erfüllt sind:

  • Die Systemarbeitslasten benötigen mehr Speicherplatz, wenn die Steuerungsebene des Clusters die neue GKE-Version ausführt.
  • Ihre vorhandenen Knoten haben nicht genügend Ressourcen, um die neuen Systemarbeitslasten und vorhandenen Arbeitslasten auszuführen.
  • Cluster Autoscaler ist für den Cluster deaktiviert.

Versuchen Sie Folgendes, um dieses Problem zu beheben:

Problem: Knotenversion ist nicht mit Version der Steuerungsebene kompatibel.

Sehen Sie nach, welche Version von Kubernetes auf der Steuerungsebene Ihres Clusters ausgeführt wird, und prüfen Sie dann, welche Kubernetes-Version die Knotenpools des Clusters ausführt. Wenn einer der Knotenpools eines Clusters mehr als zwei Nebenversionen älter als die Steuerungsebene ist, kann dies zu Problemen mit Ihrem Cluster führen.

Das GKE-Team führt regelmäßig Upgrades der Cluster-Steuerungsebene in Ihrem Namen durch. Steuerebenen werden auf neuere stabile Versionen von Kubernetes aktualisiert. Für die Knoten eines Clusters ist standardmäßig das automatische Upgrade aktiviert. Wir empfehlen, dies nicht zu deaktivieren.

Wenn die automatischen Upgrades für die Knoten eines Clusters deaktiviert sind und Sie die Knotenpoolversion nicht manuell auf eine Version aktualisieren, die mit der Steuerungsebene kompatibel ist, wird Ihre Steuerungsebene nicht mehr mit Ihren Knoten kompatibel sein, da die Steuerungsebene im Laufe der Zeit automatisch aktualisiert wird. Inkompatibilität zwischen der Steuerungsebene des Clusters und den Knoten kann zu unerwarteten Problemen führen.

Die Supportrichtlinie für Kubernetes-Versionen und Versionsinkompatibilität gibt an, dass Steuerungsebenen mit Knoten kompatibel sind, die bis zu zwei Nebenversionen älter sind als die Steuerungsebene. Die Steuerungsebenen von Kubernetes 1.19 sind beispielsweise mit Kubernetes 1.19-, 1.18- und 1.17-Knoten kompatibel. Aktualisieren Sie die Knotenpoolversion auf eine Version, die mit der Steuerungsebene kompatibel ist, um dieses Problem zu beheben.

Wenn Sie befürchten, dass der Upgradeprozess zu Arbeitslasten führt, die auf den betroffenen Knoten ausgeführt werden, führen Sie die folgenden Schritte aus, um Ihre Arbeitslasten zu einem neuen Knotenpool zu migrieren:

  1. Erstellen Sie einen neuen Knotenpool mit einer kompatiblen Version.
  2. Cordon Knoten des bestehenden Knotenpools.
  3. Optional: Aktualisieren Sie die Arbeitslasten, die auf dem vorhandenen Knotenpool ausgeführt werden, um einen nodeSelector für das Label cloud.google.com/gke-nodepool:NEW_NODE_POOL_NAME hinzuzufügen, wobei NEW_NODE_POOL_NAME der Name des neuen Knotenpools ist. So wird sichergestellt, dass GKE diese Arbeitslasten auf Knoten im neuen Knotenpool platziert.
  4. Leeren Sie den vorhandenen Knotenpool.
  5. Prüfen Sie, ob die Arbeitslasten im neuen Knotenpool ausgeführt werden. In diesem Fall können Sie den alten Knotenpool löschen. Wenn Sie Unterbrechungen bei der Arbeitslast bemerken, planen Sie die Arbeitslasten auf den vorhandenen Knoten neu, indem Sie die Knoten im vorhandenen Knotenpool entsperren und die neuen Knoten leeren. Beheben Sie das Problem und versuchen Sie es noch einmal.

Problem: Pods bleiben nach der Konfiguration der Option „Node Allocatable“ im Status „Ausstehend“

Nachdem Sie Node Allocatable konfiguriert und ein Upgrade der Knotenversion durchgeführt haben, stellen Sie möglicherweise fest, dass Pods, die zuvor ausgeführt wurden, jetzt als ausstehend angezeigt werden.

Wenn Pods nach einem Upgrade ausstehen, empfehlen wir Folgendes:

  • Achten Sie darauf, dass die CPU- und Speicheranforderungen Ihrer Pods die maximale Auslastung nicht überschreiten. Da GKE CPU und Arbeitsspeicher für Overhead reserviert, können Pods diese Ressourcen nicht anfordern. Pods, die mehr CPU oder Arbeitsspeicher anfordern, als sie verwenden, verhindern, dass andere Pods diese Ressourcen anfordern. Der Cluster ist somit möglicherweise nicht optimal ausgelastet. Weitere Informationen finden Sie unter Pods mit Ressourcenanfragen planen.

  • Ziehen Sie eine Anpassung der Clustergröße in Betracht. Eine Anleitung finden Sie unter Clustergröße anpassen.

  • Führen Sie ein Downgrade des Clusters aus, um diese Änderung rückgängig zu machen. Eine Anleitung finden Sie unter Manuelles Upgrade eines Clusters oder Knotenpools.

Nächste Schritte

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