A partire dalla versione v1.35, Kubernetes rende cgroup v2 lo standard operativo, impedendo l'avvio del kubelet su nodi v1 per impostazione predefinita per migliorare l'isolamento e la gestione delle risorse.
L'annuncio del 6 ottobre 2026 introduce una modifica critica per l'amministrazione dei nodi Linux in Kubernetes. La novità principale è la deprecazione di cgroup v1: a partire dalla versione v1.35, il parametro failCgroupV1 è impostato su true per default. Questo comporta che il kubelet, l'agente responsabile della gestione dei pod su ogni nodo, non si avvierà se rileva un sistema basato su cgroup v1. I cgroups (control groups) sono una funzionalità del kernel Linux utilizzata per allocare e isolare risorse di sistema, come CPU e memoria, assegnandole a specifici container per evitare che un'applicazione interferisca con le altre. [1]
Per chi gestisce cluster aggiornati a v1.35 o versioni successive, l'impatto è immediato: ogni nodo Linux deve essere migrato a cgroup v2 per garantire la continuità operativa. Esiste una via di fuga temporanea impostando failCgroupV1 su false nel file di configurazione del kubelet, ma questa opzione è provvisoria e seguirà la politica di rimozione di Kubernetes. Chi utilizza strumenti come kubeadm noterà controlli più severi durante le fasi di init, join o upgrade, dove il sistema di verifica preflight restituirà un errore bloccante invece di un semplice avviso se viene rilevata la versione v1 del controller. [1]
Il passaggio a cgroup v2 rappresenta un cambio di paradigma nell'architettura del kernel. Mentre cgroup v1 utilizzava gerarchie separate per ogni controller (come CPU o memoria), cgroup v2 introduce una gerarchia unificata. Questo approccio elimina le incoerenze tra i diversi controller e fornisce un'interfaccia più coerente per l'isolamento delle risorse. In particolare, v2 permette una gestione più precisa della memoria e introduce il supporto ufficiale per la delega dei controller a utenti non privilegiati tramite systemd, rendendo possibile l'implementazione di container rootless, operazione che in v1 era considerata potenzialmente pericolosa. [1][2]
Un aspetto rilevante riguarda la gestione degli eventi Out-Of-Memory (OOM). Sui nodi cgroup v2, il kubelet imposta per default singleProcessOOMKill su false. Questo attiva la proprietà memory.oom.group, che assicura che, in caso di esaurimento della memoria, vengano terminati tutti i processi all'interno del cgroup del container contemporaneamente. Questo differisce dal comportamento di v1, dove il kernel poteva terminare un singolo processo alla volta, lasciando potenzialmente il container in uno stato parzialmente funzionante e instabile. [1]
Flusso di adozione e requisiti tecnici per l'avvio del kubelet
L'adozione di cgroup v2 abilita funzionalità come Memory QoS (Quality of Service), che in v1.36 rimane in stato alpha. Questa funzione introduce la protezione a livelli (Tiered Reservation) della memoria tramite i controller memory.high (per il throttling), memory.min (protezione hard) e memory.low (protezione soft). Kubernetes può mappare le classi di QoS dei Pod su questi controlli: i Pod 'Guaranteed' vengono mappati su memory.min e i 'Burstable' su memory.low. Poiché si tratta di una feature alpha, Kubernetes raccomanda di non abilitarla in produzione senza test accurati e senza aver considerato la memoria hard-reserved. [1]
L'integrazione con Pressure Stall Information (PSI) permette di monitorare i colli di bottiglia di CPU, memoria e I/O a livello di nodo, pod e container. PSI richiede obbligatoriamente cgroup v2, un kernel 4.20 o superiore, la configurazione CONFIG_PSI=y e che il kernel non sia avviato con l'opzione psi=0. Inoltre, l'aggiornamento a v2 abilita il ridimensionamento verticale dei pod in-place (stabile in v1.35 e beta in v1.36), che permette di modificare le risorse di un pod senza riavviarlo; l'applicazione accurata di queste modifiche aggregate richiede l'architettura di cgroup v2 per coordinare i limiti tra pod e container. [1]
Per implementare cgroup v2, l'infrastruttura deve soddisfare requisiti specifici. È necessario un kernel Linux versione 5.8 o superiore, sebbene sia raccomandata la 5.9 per chi intende utilizzare Memory QoS a causa di un potenziale livelock presente nelle versioni precedenti. Lato runtime, sono supportate le versioni di containerd dalla 1.4 in poi (con scoperta automatica del driver dalla 2.0) e CRI-O dalla 1.20 in poi. È fondamentale che sia il kubelet che il runtime utilizzino lo stesso cgroup driver, preferibilmente systemd, per evitare conflitti nella gestione dei parametri di sistema. [1][4]
La migrazione richiede l'aggiornamento delle applicazioni che leggono direttamente il filesystem cgroup, poiché i percorsi e i nomi dei file cambiano (ad esempio, cpu.shares in v1 diventa cpu.weight in v2). Software di monitoraggio, agenti di sicurezza e runtime come Java o Node.js devono essere aggiornati. Per Java, sono raccomandate versioni come OpenJDK 11.0.16 o 15+ per un supporto completo. Anche cAdvisor deve essere aggiornato alla versione 0.43.0 o successiva per interpretare correttamente i nuovi dati provenienti dal kernel. [1][4]
La scelta di migrare a cgroup v2 deve considerare i limiti tecnici persistenti. Chi gestisce carichi di lavoro con I/O intensivo deve sapere che il kubelet continua a trattare la memoria active_file come non recuperabile, il che può causare eviction di pod anche su v2. In questi casi, la soluzione non è il cambio di versione del cgroup, ma l'impostazione di request e limit di memoria identici per i container interessati. Chi invece necessita di isolamento stretto, supporto rootless o monitoraggio PSI troverà in v2 l'unica soluzione percorribile, rendendo l'aggiornamento prioritario. [1]
Consideriamo un esempio illustrativo: un'azienda che gestisce un cluster di database NoSQL con alta pressione di memoria. Se l'obiettivo è implementare il ridimensionamento delle risorse senza riavviare i pod (in-place scaling) e utilizzare Memory QoS per proteggere i nodi critici, l'adozione di cgroup v2 è obbligatoria. Il criterio di verifica consiste nel controllare che il kernel sia almeno 5.9 e che il runtime sia containerd 2.0+. Se l'azienda utilizza invece agenti di monitoraggio legacy che non supportano l'API v2, l'aggiornamento di tali tool è un prerequisito necessario per evitare la perdita di visibilità sulle metriche dopo l'upgrade a Kubernetes v1.35. [1]
Per verificare se un nodo è correttamente configurato per cgroup v2, l'amministratore può eseguire il comando stat -fc %T /sys/fs/cgroup/, che deve restituire cgroup2fs. Per l'analisi dei processi, strumenti come systemd-cgtop e systemd-cgls permettono di visualizzare ricorsivamente i contenuti dei gruppi di controllo e l'utilizzo delle risorse. È fondamentale non trattare il percorso cgroupsPath fornito dal runtime come un percorso del filesystem quando si usa il driver systemd, poiché in quel caso rappresenta un'unità di sistema (slice) e non una directory fisica sotto /sys/fs/cgroup. [1]
Il controllo dell'effettiva applicazione dei limiti di CPU e memoria richiede un percorso di verifica che va dall'API di Kubernetes fino al file del kernel. Dopo aver identificato il PID del container tramite crictl, è possibile leggere i file cpu.max e memory.max nel filesystem cgroup per confermare che i valori corrispondano a quanto definito nello spec del pod. Se Memory QoS è attivo, appariranno inoltre i file memory.high, memory.min e memory.low, che permettono di validare l'applicazione delle protezioni tiered reservation configurate nel kubelet. [1]
NVIDIA e Microsoft lanciano RTX Spark, un superchip che integra GPU Blackwell e CPU Grace per permettere l'esecuzione locale di agenti AI complessi su laptop e desktop Windows, riducendo la dipendenza dal cloud.
Il 5 ottobre 2026, Amazon Bedrock ha reso disponibile GLM 5.3 di Z.ai, un modello open-weight basato su architettura Mixture-of-Experts ottimizzato per l'ingegneria del software e il coding autonomo.
Dal 5 ottobre 2026, le istanze Amazon EC2 Hpc8a, basate su processori AMD EPYC di 5ª generazione, sono disponibili nella regione Asia Pacific (Singapore) per carichi HPC intensivi e a bassa latenza.
Parliamone
Hai un’esperienza da condividere o una domanda? Scrivi un commento pertinente, senza pubblicità o link.