Tun Sie dies, bevor Sie GKE auf K8S v1.25 aktualisieren, sonst könnte es Ihnen leid tun!

In diesem Blog erfahren Sie, wie Sie sicherstellen können, dass Ihre durch ein persistentes Volume gesicherten Pods nach einem Upgrade von Kubernetes (K8S) auf v1.25 starten. Der Blog beginnt mit einer kurzen Einführung in das Problem. Danach gehen wir darauf ein, wie sich das Problem manifestiert hat, was wir versucht haben und wie wir es schließlich behoben haben. Zum Schluss dieses Blogposts zeige ich Ihnen ein Skript, mit dem Sie sicherstellen können, dass Sie nicht von diesem Problem betroffen sind.

Kürzlich (13. Januar 2023) wurde K8S v1.25 zum neuen Standard für den regulären Release Channel auf Google Kubernetes Engine (GKE). Das bedeutet, dass GKE-Cluster, die diesen Release Channel abonniert haben, in Kürze ein Upgrade der Control Plane durchführen werden. Nach dem Upgrade der Steuerebene werden Node-Pools mit konfiguriertem automatischen Upgrade folgen. Dies könnte jedoch ein undokumentiertes Problem mit Ihren von der Google Compute Engine (GCE) unterstützten persistenten Volumes auf GKE verursachen.

Wir haben kürzlich ein Upgrade unseres Clusters von K8S v1.24 auf v1.25 durchgeführt. Die Steuerebene wurde problemlos aktualisiert (), aber die Probleme begannen, als wir die Knotenpools aktualisierten. Wir stellten fest, dass einige unserer Workloads nach dem Upgrade der Nodes nicht mehr hochgefahren wurden. Die Arbeitslasten befanden sich im Zustand Unschedulable und die Ereignisse in kubectl describe pods ... gaben uns einen ziemlich klaren Hinweis darauf, warum der Scheduler den Pod nicht planen konnte;

1 node(s) had untolerated taint {node.kubernetes.io/not-ready: }
24 node(s) had no available volume zone
3 Insufficient cpu
28 node(s) had volume node affinity conflict.
preemption: 0/28 nodes are available: 28 Preemption is not helpful for scheduling.

Das Problem war, dass die neuen GKE-Knoten, auf denen K8S v1.25 läuft, nicht in der Lage waren, die GCE persistent disks (24 node(s) had no available volume zone) zu verbinden. Es war unklar, warum sie nicht in der Lage waren, da wir keine anderen diesbezüglichen Protokollmeldungen finden konnten. In der Zwischenzeit versuchte der Autoscaler ständig, Knoten zu aktivieren, die in der Lage sein würden, die Festplatte zu verbinden.

Dann haben wir versucht, eine neue PVC zu erstellen, die mit der folgenden Meldung ausstand: Waiting for volume to be created either by external provisioner "pd.csi.storage.gke.io" or manually created by system administrator.. Dies wies uns auf den externen Provisioner hin, da wir vor dem Upgrade keine Volumes selbst erstellt hatten. Die Lektüre der Google-Dokumentation über den Provisioner brachte uns auf die Lösung: die Aktivierung des Compute Engine persistent disk CSI Driver. Die Control Plane brauchte sehr lange, um das Plugin zu aktivieren, da der Autoscaler immer noch hoch- und runterskalierte. Nachdem wir ein paar Minuten gewartet hatten, war das Plugin aktiviert und der Cluster sah wieder gesund aus.

Ein paar Hintergrundinformationen zu diesem Problem: Kubernetes verfügte früher über integrierte CSI-Treiber, unter anderem für , die wichtigsten Cloud-Anbieter. Die CSI-Treiber sorgen für die Kommunikation zwischen Kubernetes und dem Disk Provisioner (d.h. GCE Persistent Disks). Seit ein paar Jahren ist der Plan von , diese Treiber aus dem Kubernetes-Quellcode zu entfernen und stattdessen als Plugin neu zu implementieren. Auch wenn ich es in den K8S/GKE-Versionshinweisen nicht finden konnte, scheint dieser integrierte Treiber in der Version v1.25 entfernt worden zu sein bzw. nicht mehr zu funktionieren.

GKE-Cluster, die mit K8S v1.18 oder später erstellt wurden, sind standardmäßig so konfiguriert, dass das Compute Engine persistent disk CSI Driver-Plugin verwendet. Bei GKE-Clustern, die ursprünglich mit einer älteren Version von K8S erstellt wurden, ist dieses Plugin jedoch nicht standardmäßig aktiviert. Das bedeutet, dass, wenn Sie die Knoten auf K8S v1.25 aktualisieren, die persistenten GCE-Volumes nicht mehr automatisch angehängt werden. Dies führt dazu, dass die Pods, die mit einem Persistent Volume Anspruch konfiguriert sind, in den Zustand Unschedulable übergehen. Der GKE-Cluster-Autoscaler wird versuchen, Knoten hinzuzufügen , bis ein Knoten auftaucht, auf dem der erforderliche Treiber installiert ist.

Wenn Sie wissen möchten, ob Sie für dieses Problem anfällig sind, stellen Sie fest, ob Ihre Arbeitslasten persistente Volumes verwenden und ob das Funktionsflag Compute Engine persistent disk CSI Driver aktiviert ist. Wenn Sie sich nicht sicher sind, können Sie den folgenden Befehl von Ihrem Terminal aus ausführen:

gcloud container clusters list --format 
'value(name, location, addonsConfig.gcePersistentDiskCsiDriverConfig.enabled)'

Führen Sie den folgenden Befehl aus, wenn in einem Ihrer Cluster der Treiber nicht aktiviert ist und sie über persistente Volumes verfügen, die durch GCE persistente Festplatten gesichert sind:

gcloud container clusters update <CLUSTER-NAME> 
--update-addons=GcePersistentDiskCsiDriver=ENABLED

Alternativ können Sie das folgende Skript (zur Verfügung gestellt von Mark van Holsteijn) verwenden, um die Compute Engine persistent disk CSI Driver automatisch für alle Cluster in einem Projekt zu aktivieren:

#!/bin/bash
# NAME
#   check-gce-csi-driver-enabled -- checks whether the GCE CSI driver is enabled on your clusters
#
gcloud container clusters 
    list 
    --format 'value(name, location, addonsConfig.gcePersistentDiskCsiDriverConfig.enabled, selfLink)' | 
    while read name location enabled selflink; do
    project=$(awk -F/ '{print $6}' <<< "$selflink")
    location=$(awk -F/ '{print $8}' <<< "$selflink")
    location_type=$(awk -F/ '{if($7 == "zones"){print "zone"} else{print "region"}}' <<< "$selflink")

    if [[ $enabled != True ]]; then
        echo "WARN: cluster $name in $location_type $location does not have the GCE CSI driver enabled." >&2
        echo "# change your terraform configuration, or run to following command to update"
        echo "gcloud container clusters update $name --$location_type $location --project $project --update-addons=GcePersistentDiskCsiDriver=ENABLED"

    else
        echo "INFO: cluster $name in $location_type $location has the GCE CSI driver enabled o/" >&2
    fi
done