Bei DoiT International betreuen wir Kunden jeder Größenordnung und stoßen dabei immer wieder auf wiederkehrende Probleme – vor allem bei einigen unserer größeren Accounts. Ein Problem, das uns kürzlich beim Upgrade von Googles GKE (managed Kubernetes) begegnet ist, möchten wir teilen – für alle, die ihre Upgrades planen oder auf ähnliche Effekte stoßen.
Symptome
Vorab wichtig: Nicht alle Kunden sind betroffen. Folgende Symptome haben wir jedoch beobachtet:
- Nach dem Upgrade kann die kubectl-CLI nicht mehr mit dem Cluster kommunizieren (API-Server antwortet nicht).
- Der Upgrade-Prozess scheint zu "hängen" und ist auch nach mehr als 20 Minuten nicht abgeschlossen.
- Fehlermeldung in der Konsole oder in den Logs mit folgendem oder ähnlichem Wortlaut: "All cluster resources were brought up, but: component "kube-apiserver" from endpoint "gke-XXXXXXXX-XXXXXXX" is unhealthy."
Risikoanalyse
Auch wenn nicht alle betroffen sind, zeigen sich folgende Gemeinsamkeiten:
- GKE-Cluster-Version unter 1.16
- Zonaler Cluster (Single-Zone-Master für die Control Plane)
- "Gesprächige" workloads, die laufend mit dem API-Server interagieren – etwa Istio, Flux oder ArgoCD
- Upgrades zwischen Versionen wie 1.12 -> 1.13, 1.13 -> 1.14, 1.14 -> 1.15, 1.15 -> 1.16 (bei Patch-Updates in der Regel nicht zu beobachten)
Wer könnte betroffen sein?
Noch einmal zur Einordnung: Bislang ist dies nur bei wenigen Kunden aufgetreten – die meisten passen ins Profil mit zonalen Clustern und hoher Last auf dem API-Server. Dadurch hat dieser die Health Checks beim Upgrade zu langsam bestanden und blieb in einem "hängenden" Zustand stecken. Wir hoffen, diese Hinweise helfen Ihnen – sei es bei der Planung künftiger Versions-Upgrades oder bei der Behebung bestehender Probleme.
Lösungsansätze
Google-Support-Ticket zur Erhöhung des Health-Check-Timeouts
Falls Sie bereits betroffen sind, Ihre Worker-Nodes aber weiterhin Traffic ausliefern (lediglich der kubectl-Zugriff auf die Control Plane fehlt), können Sie ein Support-Ticket beim Google Support oder bei Ihrem Technical-Support-Partner (idealerweise DoiT International) eröffnen, um das Health-Check-Timeout auf 3 Minuten anzuheben. So bekommt der API-Server mehr Zeit zur Wiederherstellung, und eine Endlosschleife fehlgeschlagener Health Checks wird vermieden.
Node-Pool-Größe und Last auf dem API-Server reduzieren
Wenn Sie eine kurzzeitige Downtime der Worker-Nodes in Kauf nehmen können, lässt sich der Druck auf den API-Server entlasten: Entweder Sie deaktivieren die "gesprächigen" workloads zeitweise und skalieren sie herunter, oder Sie skalieren Ihren Node-Pool kurzerhand auf 0, lassen das Upgrade durchlaufen und fahren ihn anschließend wieder hoch.
Weitere mögliche Ursachen
Einige unserer Engineers sind auf Szenarien gestoßen, in denen die Control Plane wegen einer Race Condition in der Linux-netfilter/conntrack-Tabelle nicht erreichbar war. Das Problem ist inzwischen behoben, ältere Versionen waren jedoch anfällig dafür.
Langfristige Lösung
Die Google Engineers sind sich des Problems bewusst; ein Fix für Version 1.16 oder höher (manuelles Upgrade) ist innerhalb des nächsten Monats geplant. Zum Zeitpunkt dieses Blogbeitrags gibt es noch keinen öffentlichen Issue-Tracker-Link.
Cluster von zonal auf regional umstellen
Leider gibt es keine "One-Click-Lösung", um einen Cluster von zonal auf regional umzustellen. Einer unserer Cloud-Architekten hat jedoch einen Artikel verfasst, der einen Migrationsansatz mit dem beliebten Open-Source-Tool Velero beschreibt.