Come correggere le policy di risorse Kubernetes ottimizzate per la fase sbagliata

TL;DR

• Una resource policy in Kubernetes è l'insieme dei livelli che decidono quali requests e limits finisce per avere un container: ResourceQuota, LimitRange, regole di admission (Kyverno, Gatekeeper, ValidatingAdmissionPolicy), i default dei chart Helm e qualunque recommender scriva quei numeri.
• Ognuno di questi livelli presuppone un solo numero per container, valido per tutta la sua vita. I container hanno però due fasi, startup e steady state, e il divario tra le due può andare da 3x a 10x.
• Le policy tarate sullo steady state causano throttling e OOM-kill dei pod durante lo startup. Quelle tarate sullo startup riservano capacità che nessuno usa, saturano le quota dei namespace con requests inattive e lasciano i pod in Pending mentre il cluster resta mezzo vuoto.
• La soluzione è strutturale: quota sulle requests, non sui limits; LimitRange che consente il burst invece di comprimerlo; regole di admission che richiedono requests e limiti di memoria ma smettono di imporre limiti di CPU; e un recommender che tratta startup e steady state come numeri separati.
• Il resize in-place dei pod rende praticabile l'ultimo passaggio. Lo startup ottiene ciò che gli serve, poi il pod si riduce al suo plateau senza riavvio e la quota viene recuperata nello stesso istante.

Nel post precedente abbiamo visto come individuare uno spike di startup: filtrando le metriche di throttling e OOM per età del container, il burst che le medie nascondono emerge nei primi 60 secondi di vita di ogni container. Questo post spiega cosa fare una volta che lo spike è visibile, perché la parte difficile non è modificare un singolo Deployment: è che il livello di policy intorno a quel Deployment è stato scritto per una sola fase e continuerà a spingere ogni workload verso di essa.

Fix 4: memoria dimensionata sullo startup, CPU sullo steady state

Una volta che il livello di policy smette di imporre una risposta unica, la decisione per singolo workload diventa più semplice, ed è diversa per ciascuna risorsa.

Il limite di memoria deve superare il picco di startup. Per la memoria non esiste degradazione graduale. Se l'inizializzazione alloca 900Mi e il limite è 768Mi, il container muore con exit code 137 prima ancora di raggiungere il suo plateau da 400Mi. Si prende max_over_time(container_memory_working_set_bytes[5m]) su una finestra che include un rollout e si imposta il limite sopra quel numero, con margine. Per i workloads JVM va ricordato che lo heap è solo una parte del quadro: metaspace, code cache e stack dei thread stanno tutti fuori da -Xmx.

La request di memoria sta al plateau. La request è ciò che lo scheduler riserva e ciò che la quota conta. Impostarla sul working set di steady state con un margine moderato mantiene il bin-packing aderente alla realtà. Il divario tra request e limit colloca il pod nella QoS Burstable, il che significa che sotto pressione di memoria del nodo è candidato all'eviction prima dei pod Guaranteed. Per la maggior parte dei servizi stateless è un compromesso accettabile; per quelli in cui non lo è, si imposta deliberatamente la request uguale al limit e si accetta la riserva.

La CPU request sta al plateau, il limite di CPU è assente. Senza CFS quota, lo startup prende in prestito cicli inattivi dal nodo e li restituisce un minuto dopo. La request conta comunque: è ciò che Karpenter e lo scheduler usano per collocare il pod, ed è il denominatore su cui l'HPA calcola l'utilizzo. Va dimensionata sul p95 dello steady state, non sul burst.

L'unico punto in cui questo schema si rompe è un rollout che porta molti pod con spike sullo stesso nodo appena creato, tutti insieme. Senza CPU inattiva da prendere in prestito, lo startup gira lento per contesa anziché per throttling. Conviene limitare maxSurge così che i nuovi pod arrivino a ondate anziché tutti in una volta, e valutare un topologySpreadConstraint su kubernetes.io/hostname perché i nuovi pod di un rollout non si accumulino su un solo nodo. Una startupProbe con un failureThreshold dimensionato sul caso lento impedisce al kubelet di riavviare un pod che sta semplicemente facendo il boot sotto carico.

Fix 5: un recommender che vede due fasi e un pod che può cambiare dimensioni

Tutto quanto sopra impedisce alla policy di imporre il numero sbagliato. Ma non produce quello giusto. Per questo il recommender deve sapere che startup e steady state sono diversi, e il pod deve potersi spostare tra i due.

Il Vertical Pod Autoscaler con il suo recommender predefinito costruisce un istogramma a decadimento su circa otto giorni di campioni. Un burst di 45 secondi per lui è rumore, quindi raccomanda il plateau, e al rollout successivo scatta il throttling. Lo si può vincolare con minAllowed perché non scenda mai sotto una soglia che sopravvive al boot, ma questo non fa che ricodificare il numero di startup come riserva permanente, passando da un'altra porta.

Il resize in-place dei pod cambia la forma del problema. È diventato stabile in Kubernetes 1.35 ed è attivo per impostazione predefinita nella 1.36, e consente di modificare requests e limits di un container in esecuzione senza riavvio. Il pattern è: avviare il pod con CPU e memoria sufficienti per un boot pulito, poi ridimensionarlo ai valori di steady state una volta che risulta ready. Lo startup CPU boost di GKE ne implementa una versione per Autopilot. La spec del pod deve solo dichiarare che una modifica della CPU non deve innescare un riavvio:

containers:
- name: app
  resizePolicy:
  - resourceName: cpu
    restartPolicy: NotRequired
  - resourceName: memory
    restartPolicy: NotRequired   # oppure RestartContainer se il runtime non può ridurre lo heap a caldo
  resources:
    requests:
      cpu: "2"          # valore di startup; ridimensionato a ~200m dopo la readiness
      memory: 1Gi
    limits:
      memory: 1Gi

È qui che il lavoro sulla quota del Fix 1 ripaga. Un resize viene verificato rispetto alla ResourceQuota come qualsiasi altra modifica delle requests, quindi quando il pod si riduce da 2 core a 200m il namespace recupera immediatamente 1,8 core di quota. Quaranta repliche si avviano a ondate, ciascuna mantiene la propria riserva di startup per circa un minuto, e il footprint di steady state del namespace si assesta a 8 core invece di 80. I pod smettono di restare in Pending dietro riserve che descrivono una fase in cui nessuno si trova più.

Un vincolo di cui tenere conto in fase di progettazione: un resize non può cambiare la classe QoS di un pod. Un pod partito Burstable resta Burstable, e un pod Guaranteed deve mantenere requests uguali ai limits a ogni resize. Un motivo in più per non imporre Guaranteed via policy ai workloads che non ne hanno bisogno.

Checklist per riscrivere le policy

1. Inventariare i livelli. Per ogni namespace: kubectl get resourcequota,limitrange -o yaml, più ogni regola Kyverno/Gatekeeper/VAP che tocca resources. Annotare cosa impone ciascuna.
2. Individuare la fase presupposta da ogni livello. Qualsiasi limits.cpu in una quota, qualsiasi max.cpu o maxLimitRequestRatio.cpu basso in un LimitRange, qualsiasi regola di admission "deve impostare un limite di CPU" è una policy da steady state. Qualsiasi defaultRequest sopra qualche centinaio di millicore, o qualsiasi obbligo di requests uguali ai limits, è una policy da startup.
3. Misurare il divario. Eseguire la query del rapporto requests/utilizzo per namespace. Qualsiasi valore sopra 3-4 è quota consumata dalla fase sbagliata.
4. Spostare la quota sulle requests. Eliminare limits.cpu dalla ResourceQuota; mantenere requests.* e limits.memory.
5. Aprire il LimitRange. Rimuovere default.cpu, alzare o rimuovere max.cpu, applicare maxLimitRequestRatio solo alla memoria.
6. Riscrivere l'admission. Richiedere requests di CPU e memoria e un limite di memoria. Smettere di richiedere un limite di CPU.
7. Ridimensionare i dieci workloads che si riavviano di più. Limite di memoria al picco di startup, requests di memoria e CPU al p95 dello steady state, nessun limite di CPU. Aggiungere maxSurge e vincoli di spread se i rollout creano contesa.
8. Abilitare il dimensionamento a due fasi dove il cluster lo supporta. Su 1.33+ con resize in-place disponibile, dichiarare resizePolicy e lasciare che un controller riduca i pod dopo la readiness.
9. Rieseguire il punto 3 una settimana dopo. Il rapporto dovrebbe scendere verso 1,5-2 e, allo stesso tempo, il tasso di throttling dei container giovani dovrebbe scendere verso zero. Se si è mosso solo uno dei due, è stata sistemata una risorsa e non l'altra.

FAQ

Che cos'è una resource quota in Kubernetes? Una ResourceQuota è un oggetto a livello di namespace che limita il totale delle risorse che tutti i pod di quel namespace possono richiedere o avere come limite, oltre al numero di oggetti come pod, service e PVC. Viene applicata in admission: un pod le cui requests o i cui limits porterebbero il namespace oltre i valori hard viene rifiutato. Le quota contano i numeri nella spec del pod, non l'utilizzo effettivo, ed è per questo che una quota può esaurirsi mentre i nodi dietro di essa restano inattivi.

Una ResourceQuota deve vincolare i limits o le requests? Vanno limitate requests.cpu e requests.memory, perché le requests sono ciò che lo scheduler riserva e ciò che si paga in capacità dei nodi. Va limitato anche limits.memory, perché è una vera barriera di sicurezza contro un namespace che consuma tutta la memoria dei nodi. Meglio evitare limits.cpu nelle quota: spinge i team a ridurre i limiti di CPU per rientrare, il che causa throttling dei pod durante lo startup senza proteggere il nodo.

Qual è la differenza tra ResourceQuota e LimitRange? ResourceQuota imposta un totale a livello di namespace. LimitRange imposta default, minimi, massimi e il rapporto consentito tra limit e request per singolo container (o pod, o PVC). La quota risponde alla domanda "quanto può usare questo team in totale"; il LimitRange risponde a "cosa riceve un container se non dichiara nulla, e qual è il massimo che può chiedere". Entrambi vengono applicati in admission.

I resize in-place dei pod vengono conteggiati nella ResourceQuota? Sì. Un resize che aumenta le requests viene validato rispetto alla quota del namespace e rifiutato se la supererebbe. Un resize che riduce le requests restituisce immediatamente la differenza alla quota. È questo che permette al pattern "startup e poi riduzione" di mantenere il footprint di quota di steady state di un namespace vicino al suo utilizzo reale.

Perché i miei pod subiscono throttling allo startup anche se il nodo ha CPU inattiva? Perché un limite di CPU viene applicato dalla CFS quota del kernel per singolo container, indipendentemente dal carico del nodo. Se il limite è 500m, il container ottiene 50ms di ogni periodo da 100ms a prescindere da quanto il nodo sia scarico. Il lavoro di startup, come la compilazione JIT o il caricamento dei moduli, esaurisce quella quota all'inizio di ogni periodo e poi aspetta. Rimuovere il limite di CPU, o alzare maxLimitRequestRatio perché il limit possa stare ben sopra la request, consente allo startup di usare la capacità inattiva.

Policy che rispecchiano il comportamento reale dei container

Tutto quanto sopra si può fare a mano: riscrivere la quota, aprire il LimitRange, aggiornare la policy di admission, ridimensionare i workloads più rumorosi, e ripetere quando il codice cambia. La parte difficile è proprio quest'ultimo passaggio. I profili di startup cambiano a ogni aggiornamento di dipendenza e a ogni modifica dei flag JVM, e una policy tarata correttamente a marzo è di nuovo sbagliata a giugno.

PerfectScale by DoiT profila ogni container a livello di workload, così il comportamento di startup e quello di steady state emergono come pattern separati anziché come un'unica media aggregata, e le sue raccomandazioni dimensionano la memoria perché superi il picco di boot mantenendo le requests al plateau. Per i workloads Java rileva automaticamente i container JVM una volta abilitato l'agent Coroot, traccia heap, non-heap e GC nel tempo, segnala i container in esecuzione senza impostazioni esplicite dello heap e rispetta -Xms e -Xmx quando raccomanda o applica una modifica. Sui cluster con Kubernetes 1.33 o successivo, la sua automazione applica il right-sizing in place senza riavviare il pod, e ricorre a un rolling restart solo quando un resize non è fattibile sul nodo corrente, così la quota del namespace riflette ciò che i workloads stanno usando adesso e non ciò di cui hanno avuto bisogno per 45 secondi dopo l'ultimo deploy.

Vuole vedere un pod avviarsi a 2 core e assestarsi a 200m senza riavvii e senza quota rimasta bloccata? Partecipi al workshop sullo spike di startup della JVM, oppure prenoti una sessione tecnica e analizzeremo insieme le policy di quota e LimitRange dei suoi cluster.