Padroneggiare Richieste e Limiti delle Risorse di Kubernetes per Prestazioni Ottimali

Kubernetes offre potenti funzionalità per automatizzare il deployment, lo scaling e la gestione delle applicazioni containerizzate. Tuttavia, ottenere prestazioni ottimali e mantenere la stabilità del tuo cluster dipende in modo critico da come definisci i requisiti di risorse per i tuoi workload. Impostazioni di risorse configurate in modo errato sono la causa principale di colli di bottiglia nelle prestazioni, scheduling imprevedibile e utilizzo inefficiente del cluster.

Questa guida approfondisce Richieste di Risorse e Limiti di Kubernetes. Comprendere la distinzione e applicarli correttamente è fondamentale per garantire la Qualità del Servizio (QoS) per le tue applicazioni, prevenire vicini rumorosi e ottimizzare la spesa per la tua infrastruttura. Esploreremo come queste impostazioni interagiscono con lo scheduler di Kubernetes e il sistema operativo sottostante.

Comprendere i Concetti Fondamentali: Richieste vs. Limiti

In Kubernetes, ogni specifica del container all'interno di un Pod deve definire il suo consumo previsto di risorse utilizzando resources.requests e resources.limits. Queste impostazioni governano CPU e Memoria, le due risorse più critiche per la salute dell'applicazione.

1. Richieste di Risorse (`requests`)

Le Richieste rappresentano la quantità di risorse che a un container è garantito di ricevere al momento dello scheduling. Questo è l'importo minimo di risorse che il kube-scheduler utilizza quando decide su quale nodo posizionare un Pod.

Scheduling: Un nodo deve avere abbastanza risorse allocabili disponibili che soddisfino la somma di tutte le richieste dei Pod prima che un nuovo Pod possa essere schedulato lì.
Garanzie: Se il nodo esaurisce le risorse in seguito, il container riceverà comunque almeno la quantità richiesta (a meno che non sia soggetto a evizione).

2. Limiti di Risorse (`limits`)

I Limiti definiscono la quantità massima di risorse che un container è autorizzato a consumare. Superare questi limiti comporta comportamenti specifici e definiti per CPU e Memoria.

Limiti CPU: Se un container tenta di utilizzare più CPU del suo limite, i cgroups del kernel Linux ne limiteranno l'utilizzo, impedendogli di consumare ulteriori cicli.
Limiti Memoria: Se un container supera il suo limite di memoria, il sistema operativo terminerà immediatamente il processo (OOMKill: Out Of Memory Kill).

Comportamento CPU vs. Memoria

È fondamentale comprendere la differenza qualitativa nel modo in cui Kubernetes applica i confini di CPU e Memoria:

Risorsa	Comportamento al Superamento del Limite	Meccanismo di Applicazione
CPU	Limitata (rallentata)	cgroups (controllo banda CPU)
Memoria	Terminata (OOMKill)	Kernel OOM Killer

Suggerimento: Poiché la limitazione della CPU è generalmente meno dirompente di un OOMKill, è spesso una buona prassi impostare un limite CPU leggermente superiore all'utilizzo di picco tipico, impostando al contempo un limite di memoria rigoroso per prevenire instabilità del nodo.

Definizione delle Risorse nelle Specifiche dei Pod

Le risorse sono definite all'interno del blocco spec.containers[*].resources. Le quantità sono specificate utilizzando i suffissi standard di Kubernetes (ad es. m per milli-CPU, Mi per Mebibytes).

Definizioni delle Unità CPU

1 unità CPU equivale a 1 core completo (o vCPU sui provider cloud).
1000m (millicores) equivale a 1 unità CPU.

Definizioni delle Unità di Memoria

Mi (Mebibytes) o Gi (Gibibytes) sono comuni.
1024Mi = 1Gi.

Esempio di Configurazione YAML

Considera un container che richiede un minimo garantito di 500m di CPU e 256Mi di memoria, ma non dovrebbe mai superare 1 CPU e 512Mi:

resources:
  requests:
    memory: "256Mi"
    cpu: "500m"
  limits:
    memory: "512Mi"
    cpu: "1"

Classi di Qualità del Servizio (QoS)

La relazione tra Richieste e Limiti determina la classe di Qualità del Servizio (QoS) assegnata a un Pod. Questa classe detta la priorità del Pod quando le risorse scarseggiano e il nodo necessita di recuperare memoria (evizione).

Kubernetes definisce tre classi QoS:

1. Garantito (Guaranteed)

Definizione: Tutti i container nel Pod devono avere Richieste e Limiti identici e non nulli per sia CPU che Memoria.

Vantaggio: Questi Pod sono gli ultimi ad essere evinti in caso di pressione sulle risorse, garantendo la massima stabilità.
Caso d'uso: Componenti critici di sistema o database che richiedono un isolamento rigoroso delle prestazioni.

2. Spostabile (Burstable)

Definizione: Almeno un container nel Pod ha Richieste definite, ma o le Richieste e i Limiti non sono uguali per tutti i container, o alcune risorse non sono limitate (sebbene sia altamente raccomandato impostare limiti).

Vantaggio: Permette ai container di superare le loro richieste, utilizzando la capacità inutilizzata sul nodo, fino ai loro limiti definiti.
Priorità di Evizione: Evinti prima dei Pod BestEffort, ma dopo i Pod Garantiti.
Caso d'uso: La maggior parte delle applicazioni stateless standard dove una leggera variazione nella latenza è accettabile.

3. BestEffort

Definizione: Il Pod non ha Richieste o Limiti definiti per alcun container.

Vantaggio: Nessuno, a parte la semplicità.
Rischio: Questi Pod sono i primi candidati all'evizione quando il nodo sperimenta pressione sulle risorse. Sono anche soggetti a limitazione o OOMKill immediatamente se la capacità del nodo viene superata.
Caso d'uso: Job batch non critici o agenti di logging che possono essere facilmente riavviati.

Strategie di Ottimizzazione Pratica

Una gestione efficace delle risorse richiede misurazione, iterazione e pianificazione attenta.

Strategia 1: Misurare e Impostare le Richieste in Modo Accurato

Le Richieste dovrebbero riflettere il carico tipico o minimo sostenibile richiesto dalla tua applicazione. Se imposti richieste troppo alte, sprechi capacità del cluster perché lo scheduler riserva quella risorsa anche se il container non la sta utilizzando.

Migliore Pratica: Utilizza strumenti di monitoraggio (come Prometheus/Grafana) per analizzare i dati di utilizzo storici. Imposta le richieste vicino al 90° percentile dell'utilizzo osservato durante il normale funzionamento.

Strategia 2: Definire Limiti Conservativi

I Limiti agiscono come una rete di sicurezza. Per la memoria, imposta sempre i limiti leggermente al di sopra del picco misurato per prevenire crash. Per la CPU, impostare limiti previene che un processo fuori controllo affami processi fratelli critici sullo stesso nodo.

Attenzione ai Limiti CPU: Impostare limiti CPU troppo aggressivi (ad es., 50% del fabbisogno effettivo) porta a un grave degrado delle prestazioni a causa di limitazioni costanti. Prediligi sempre la QoS Burstable a meno che tu non abbia un'esigenza specifica di isolamento Garantito.

Strategia 3: Sfruttare Vertical Pod Autoscaler (VPA)

La regolazione manuale delle risorse è difficile e richiede tempo. Il Vertical Pod Autoscaler (VPA) monitora l'utilizzo in runtime e regola automaticamente le Richieste e i Limiti definiti nelle tue specifiche dei Pod nel tempo. VPA aiuta a migrare i workload da configurazioni scarse (o BestEffort) a configurazioni Burstable o Guaranteed ottimali.

Strategia 4: Resource Quotas per Namespaces

Per prevenire l'accaparramento di risorse tra team o ambienti, gli amministratori dovrebbero utilizzare Resource Quotas a livello di Namespace. Una ResourceQuota impone limiti aggregati sulla quantità totale di Richieste e Limiti di CPU/Memoria che possono esistere all'interno di quel namespace, garantendo equità.

Esempio di Quota Namespace

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: development
spec:
  hard:
    requests.cpu: "10"
    limits.memory: "20Gi"

Ciò garantisce che la CPU totale richiesta da tutti i Pod nel namespace development non possa superare 10 core, e i limiti di memoria totali non possano superare 20Gi.

Conclusione

Padroneggiare le Richieste e i Limiti delle Risorse di Kubernetes non significa solo prevenire crash; significa ottenere prestazioni prevedibili e massimizzare il ritorno sul tuo investimento infrastrutturale. Impostando correttamente le Richieste per garantire lo scheduling e i Limiti per la sicurezza contro consumi incontrollati, elevi i tuoi Pod alla classe QoS desiderata (preferibilmente Burstable o Guaranteed). Rivedi regolarmente le metriche di performance e considera di sfruttare strumenti come VPA per mantenere un allineamento ottimale delle risorse man mano che le tue applicazioni evolvono.