Keine Neustarts, keine Ausfälle: Pod-Ressourcen nahtlos per In-Place-Resizing anpassen

Das Feature InPlacePodVerticalScaling ist in Clustern mit Version v1.33 standardmäßig aktiviert. Sie können es in einem minikube-Cluster mit folgendem Befehl explizit aktivieren oder das entsprechende Feature Gate in Ihrem Managed-Kubernetes-Cluster einschalten, falls es dort noch nicht aktiv ist.

minikube start --feature-gates=InPlacePodVerticalScaling=true

Deployen wir einen Beispiel-Pod im Cluster. Die neue restartPolicy in der Pod-Spezifikation gibt Ihnen die Kontrolle darüber, wie Container beim Resizing behandelt werden.

In der folgenden Beispielkonfiguration für Speicherressourcen legt die resizePolicy fest, dass Änderungen an der Speicherzuweisung einen Container-Neustart erfordern, während dies für CPU-Ressourcen nicht nötig ist.

Ob ein Container neu gestartet wird, hängt davon ab, ob die Anwendung die aktualisierten Ressourcen ohne Neustart nutzen kann. Ist beispielsweise die Speichernutzung kritisch für den Betrieb einer Anwendung, sorgt ein Neustart bei Speicheränderungen dafür, dass die Anwendung mit der korrekten Speichermenge startet. So lassen sich potenzielle Probleme oder Fehlfunktionen vermeiden.

cat <<EOF | kubectl apply -f -
---
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: nginx
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx
    resizePolicy:
    - resourceName: "memory"
      restartPolicy: "RestartContainer"
    - resourceName: "cpu"
      restartPolicy: "NotRequired"
    resources:
      limits:
        cpu: "300m"
        memory: "1Gi"
      requests:
        cpu: "100m"
        memory: "500Mi"
EOF

Warten Sie, bis der Pod in den Status "Running" wechselt, und sehen Sie sich die Pod-Konfiguration an. Im Pod-Status wurde unter containerStatuses ein neues Feld allocatedResources ergänzt, das die aktuell den Containern des Pods zugewiesenen Node-Ressourcen abbildet.

Zusätzlich gibt es im Container-Status ein neues Feld resources, das die tatsächlich konfigurierten Resource-Requests und -Limits der laufenden Container so wiedergibt, wie sie von der Container-Runtime gemeldet werden.

CPU-Resize

Passen wir die CPU-Ressourcen des Pods mit folgendem Patch-Befehl an und beobachten die Resize-Operation. Änderungen an Pod-Ressourcen müssen jetzt über die resize-Subresource des Pods erfolgen; kubectl-Versionen ab v1.32 unterstützen dieses Argument.

kubectl patch pod nginx --subresource resize --patch '{"spec": {"containers": [{"name":"nginx", "resources":{"requests": {"cpu" :"300m"},"limits": {"cpu" :"500m"}}}]}}'

Der Status einer Resize-Operation wird nun über zwei Pod-Conditions abgebildet:

• PodResizePending: Zeigt an, dass das Kubelet das Resizing nicht sofort gewähren kann (z. B. reason: Deferred bei vorübergehender Nichtverfügbarkeit, reason: Infeasible, wenn es auf dem Node nicht möglich ist).
• PodResizeInProgress: Zeigt an, dass das Resizing akzeptiert wurde und gerade angewendet wird. Fehler in dieser Phase werden in der Message dieser Condition mit reason: Error gemeldet.

Die Community hat den Pod Lifecycle Event Generator (PLEG) des Kubelets verbessert, sodass Kubelet in der Beta-Phase deutlich schneller auf Resizes reagieren und sie abschließen kann. Gelegentlich kann es jedoch zu einer Race Condition mit anderen Pod-Updates kommen. Das kann die Aktivierung des Resizings verzögern, und die aktualisierten Container-Ressourcen erscheinen unter Umständen erst mit etwas Verzögerung im Pod-Status.

Memory-Resize

Weiter geht es mit den Anpassungen der Memory-Ressourcen – der Container wird gemäß restartPolicy neu gestartet.

kubectl patch pod nginx --subresource resize --patch '{"spec": {"containers": [{"name":"nginx", "resources":{"requests": {"memory" :"700Mi"}}}]}}'

Der Screenshot zeigt den erfolgreichen Abschluss der Resize-Operation und den Container-Neustart 🚀.