Beim Upgrade eines GKE-Clusters tauchen manchmal unerwartete Hürden auf. Dieser Beitrag analysiert ein reales Szenario, in dem ein scheinbar einfaches Upgrade auf Version 1.27 durch einen "deprecated API call" blockiert wurde.
GKE pausiert automatische Upgrades
Erkennt GKE die Nutzung eines veralteten Features oder einer veralteten API, pausiert GKE die automatischen Upgrades, um zu verhindern, dass Ihr Cluster in einen fehlerhaften Zustand gerät. Upgrades auf die nächste Kubernetes-Minor-Version werden ausgesetzt, GKE liefert jedoch weiterhin Patch-Upgrades für die aktuelle Minor-Version aus.
Stellt GKE 30 Tage lang keine Nutzung des veralteten Features bzw. keine Aufrufe veralteter APIs mehr fest, wird der Cluster automatisch aktualisiert – sofern die nächste Minor-Version die Standardversion im Release Channel des Clusters ist.
Erkennt GKE weiterhin die Nutzung des veralteten Features im Cluster, bleibt der Cluster bis zum End-of-Life-Datum der Version auf der aktuellen Minor-Version. Ist dieses Datum – einsehbar im Release Schedule – erreicht, wird der Cluster automatisch auf die nächste Minor-Version angehoben. Da das entfernte Feature weiterhin im Einsatz ist, kann die Cluster-Umgebung dabei beeinträchtigt werden.
GKE-Upgrade blockiert
In diesem Fall identifizierte GKE einen Aufruf einer veralteten API als Grund dafür, das Upgrade von Version 1.26 zu blockieren. Trotz intensiver Suche im Cluster ließ sich keine Spur des Verursachers – eines "horizontalPodAutoscaler", der eine veraltete API verwendete – finden.
Vorgehen bei der Untersuchung
GKE Insights: GKE Insights zeigte zwar den veralteten API-Aufruf (
horizontalPodAutoscalerv2beta2) und einen User Agent ("v2.3.0") an, doch der User Agent lieferte keine aussagekräftigen Hinweise.Veraltete API: Ein Blick in die Liste der in 1.27 entfernten APIs bestätigt: HPA v2beta2 ist auf Clustern mit Kubernetes 1.26 nicht mehr verfügbar.
Admin Activity Audit Logs: Der erste empfohlene Schritt: Mit der untenstehenden Log-Abfrage diejenigen API-Clients aufspüren, die Write-Aufrufe an die veraltete API senden. Für diese Abfrage ist die Rolle roles/logging.viewer erforderlich.
resource.type="k8s_cluster"
labels."k8s.io/removed-release"="1.26"
protoPayload.authenticationInfo.principalEmail:("system:serviceaccount" OR "@")
protoPayload.authenticationInfo.principalEmail!~("system:serviceaccount:kube-system:")
- Data Access Audit Logs: Im nächsten Schritt suchen wir nach API-Clients, die Read-Aufrufe an veraltete APIs senden. Dazu müssen zunächst Kubernetes Data Read und Admin Read aktiviert werden. Um die Logs einsehen zu können, benötigen Sie unter Umständen zusätzlich die Rolle roles/logging.privateLogViewer.
Der Verursacher entlarvt
Nachdem sich die Logs gefüllt hatten, trat der Verursacher zutage: eine veraltete Version (2.3.0) von kube-state-metrics! Kube-state-metrics, ein Monitoring-Service für Kubernetes-Objekte, sendete list-Aufrufe an die veraltete v2beta2-API und löste so den Upgrade-Blocker aus. Der Fall zeigt eindrücklich, wie eng vernetzt Cloud-Umgebungen sind.
Im Quellcode lässt sich exakt nachvollziehen, woher der Aufruf stammt.
Die Lösung
Ein Upgrade von kube-state-metrics auf eine Version, die nicht mehr auf die veraltete API zugreift, löste das Problem und machte den Weg für ein reibungsloses GKE-Upgrade frei.
Fazit
- Exclusion Filter des Logging-Buckets prüfen: Vergewissern Sie sich, dass die Data Access Audit Logs nicht durch den Exclusion Filter des Logging-Buckets ausgeschlossen werden – das beschleunigt die Untersuchung erheblich.
- API-Änderungen im Blick behalten: Verfolgen Sie Kubernetes-API-Änderungen proaktiv, um potenzielle Upgrade-Hürden frühzeitig zu erkennen.
- Statische Versionen vs. Release Channels verstehen: Wägen Sie für Ihre Upgrade-Strategie die Vor- und Nachteile zwischen statischen Versionen (Stabilität) und Release Channels (automatische Sicherheitsupdates) ab.
- Upgrades strategisch steuern: Nutzen Sie Auto-Upgrade und Maintenance Exclusions, um den Zeitpunkt von Upgrades selbst in der Hand zu haben – und lassen Sie Patch-Upgrades für kritische Sicherheits-Fixes zu.
- Log-Kosten im Auge behalten: Das Aktivieren der Data Access Audit Logs kann zusätzliche Kosten verursachen. Prüfen Sie Ihren Bedarf, bevor Sie sie über längere Zeiträume aktivieren.
Mit diesen Tipps gehen Sie GKE-Upgrades deutlich souveräner an und reduzieren Störungen im Cloud-Betrieb auf ein Minimum.
Sie kennen DoiT International noch nicht? Dann sollten Sie uns unbedingt kennenlernen. Unser Team möchte mehr über Sie und Ihre Anforderungen im Cloud-Engineering erfahren. Ausschließlich mit erfahrenen Senior Engineers besetzt, sind wir auf anspruchsvolle Cloud-Beratung, Architektur-Design und Debugging-Support spezialisiert. Nehmen Sie Kontakt mit uns auf – wir freuen uns auf das Gespräch!
Ich hoffe, dieser Beitrag war für Sie hilfreich! Bei Fragen freue ich mich über einen Kommentar.