Zero riavvii, zero interruzioni: aggiornare le risorse dei pod con il resize in-place

La funzionalità InPlacePodVerticalScaling è abilitata di default nei cluster con versione v1.33. È possibile attivarla esplicitamente in un cluster minikube con il comando seguente, oppure abilitare il feature gate nel proprio cluster Kubernetes gestito qualora non sia già attivo.

minikube start --feature-gates=InPlacePodVerticalScaling=true

Distribuiamo un pod di esempio nel cluster: il nuovo restartPolicy nella spec del pod consente di stabilire come gestire i container quando le risorse vengono ridimensionate.

Nella configurazione di esempio riportata di seguito, per la memoria la resizePolicy indica che le modifiche all'allocazione richiedono il riavvio del container, mentre per la CPU il riavvio non è necessario durante il resize.

La scelta se riavviare o meno un container dipende dalla capacità dell'applicazione di utilizzare la risorsa aggiornata senza dover essere riavviata. Per esempio, se l'utilizzo della memoria è critico per il funzionamento dell'applicazione, riavviare il container al variare della memoria garantisce che l'applicazione parta con la quantità corretta, evitando potenziali problemi o malfunzionamenti.

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

Attendiamo che il pod passi allo stato running ed esaminiamo la sua configurazione. Allo status del pod è stato aggiunto un nuovo campo allocatedResources all'interno di containerStatuses, che riflette le risorse del nodo attualmente allocate ai container del pod.

È stato inoltre aggiunto un nuovo campo resources nello status del container, che riporta le richieste e i limiti effettivamente configurati sui container in esecuzione, così come comunicati dal container runtime.

Resize della CPU

Modifichiamo le risorse CPU del pod con il seguente comando di patch e osserviamo l'operazione di resize. Le modifiche alle risorse di un Pod ora devono passare attraverso la subresource resize del Pod; le versioni di kubectl v1.32+ supportano questo argomento.

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

Lo stato di un'operazione di resize è ora esposto tramite due condition del Pod:

• PodResizePending: indica che il Kubelet non può concedere il resize immediatamente (ad esempio reason: Deferred se l'operazione è temporaneamente impossibile, reason: Infeasible se non è realizzabile sul nodo).
• PodResizeInProgress: indica che il resize è stato accettato ed è in corso di applicazione. Eventuali errori riscontrati in questa fase vengono ora segnalati nel messaggio di questa condition con reason: Error.

La community ha migliorato il Pod Lifecycle Event Generator (PLEG) del Kubelet, consentendogli di rispondere ai resize e completarli più rapidamente in beta. Può comunque capitare che il resize di un pod entri in race condition con altri aggiornamenti dello stesso pod, causando un ritardo nell'attivazione del resize: in questi casi le risorse aggiornate del container possono richiedere un po' di tempo prima di comparire nello status del pod.

Resize della memoria

Proseguiamo con la modifica delle risorse di Memory: il container verrà riavviato in base alla restartPolicy.

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

Lo screenshot mostra il completamento corretto dell'operazione di resize e il riavvio del container 🚀.