Kubernetes v1.37 (Garhwal): tutte le novità e i miglioramenti

TL;DR

Kubernetes v1.37 ("Garhwal") introduce 67 miglioramenti: 16 Stable, 23 Beta, 27 Alpha e 1 rimozione. Le novità principali sono il resize in-place per i container init e sidecar (GA), la tolleranza configurabile per l'HPA (GA), le node declared features (GA), lo scale-to-zero per l'HorizontalPodAutoscaler (Beta), Memory QoS (Beta), i resource manager a livello di Pod (Beta), il gang scheduling tramite la nuova Workload API (Beta) e la modalità rootless per il Kubelet (Beta). Tra le novità Alpha figurano una Eviction Request API cooperativa e il checkpoint/restore a livello di Pod, oltre ai continui progressi sulla Dynamic Resource Allocation (DRA). Azione richiesta: in questa release il labeling dei mount SELinux cambia di default e può compromettere i workloads esistenti sui cluster con SELinux abilitato.

Kubernetes v1.37, noto anche come "Garhwal", porta con sé un solido insieme di novità per i team attenti a gestione delle risorse, autoscaling e scheduling. Questa release conta 67 miglioramenti: 16 sono ora Stable (GA), 23 sono ora Beta, 27 sono ora Alpha e 1 è una rimozione. Il nome deriva da Garhwal, una regione himalayana dell'Uttarakhand, in India. Il tema è quello di strati che si collegano e si sostengono a vicenda, dai campi terrazzati ai torrenti di montagna: una metafora perfetta per una release che continua a costruire sul lavoro delle versioni precedenti.

Queste sono alcune delle funzionalità di Kubernetes v1.37 che ci entusiasmano di più: il resize in-place per i container init e sidecar, lo scale to zero per l'HorizontalPodAutoscaler, Memory QoS e il gang scheduling nativo tramite la Workload API. Molte di queste rendono Kubernetes più efficace nell'usare bene le risorse, scalare in base alla domanda reale e posizionare workloads strettamente accoppiati.

Ecco le principali novità di Kubernetes v1.37:

Funzionalità Stable di Kubernetes v1.37

1. Resize in-place dei Pod per container init e sidecar

Feature Group: SIG Node | KEP: #1287

Il resize in-place dei Pod è diventato Stable (GA) in Kubernetes v1.35. Con la v1.37 questo supporto si estende ai container init e sidecar, e anche questa parte è ora GA.

Prima di questa modifica era possibile ridimensionare CPU e memoria di un container applicativo in esecuzione senza riavvio, ma i container init e sidecar restavano esclusi. Un container sidecar è un container init con restartPolicy: Always, quindi rimane in esecuzione per tutta la vita del Pod. Se un sidecar aveva bisogno di più CPU o memoria, l'unica vera opzione era ricreare il Pod. Questo significava downtime anche per l'app principale, anche se la modifica riguardava solo il sidecar.

Con la v1.37, il feature gate InPlacePodVerticalScalingInitContainers è GA. Puoi modificare le request o i limit di CPU e memoria di un container sidecar in esecuzione, e il kubelet aggiorna in place le impostazioni cgroup del container. Il Pod continua a girare. Con resizePolicy controlli il comportamento per ogni risorsa: NotRequired applica la modifica a caldo, RestartContainer riavvia solo quel container per applicarla. La v1.37 aggiunge inoltre due componenti Alpha alla stessa funzionalità: il resize in place dei volumi emptyDir basati su memoria (il gate InPlacePodVerticalScalingMemoryBackedVolumes) e la possibilità per lo scheduler di fare preemption dei Pod a priorità più bassa per fare spazio a un resize differito (il gate InPlacePodVerticalScalingSchedulerPreemption).

apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  initContainers:
  - name: log-shipper        # sidecar
    image: log-shipper:1.0
    restartPolicy: Always
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: RestartContainer
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"
      limits:
        cpu: "200m"
        memory: "256Mi"
  containers:
  - name: app
    image: app:1.0
    # ...

Con questa configurazione puoi aumentare la CPU del sidecar senza alcun riavvio. L'aumento della memoria riavvia solo quel container, mai l'intero Pod.

2. Tolleranza configurabile per gli HorizontalPodAutoscaler

Feature Group: SIG Autoscaling | KEP: #4951

In Kubernetes v1.37, la tolleranza configurabile per l'HorizontalPodAutoscaler (HPA) è passata a General Availability (GA).

L'HPA modifica il numero di repliche dei Pod in base a metriche come CPU o memoria. Prima di questa funzionalità, l'HPA usava una tolleranza fissa del 10% per l'intero cluster: non interveniva finché l'utilizzo non si scostava di oltre il 10% dal target. Un valore unico non andava bene per tutti i workloads. I servizi sensibili potevano reagire troppo lentamente e, per cambiarlo, bisognava modificare un flag globale del controller che toccava ogni HPA del cluster.

Con la v1.37, il feature gate HPAConfigurableTolerance è GA. Puoi impostare la tolleranza per singolo HPA e per direzione di scaling nel campo behavior. Una tolleranza stretta in scale up permette a un servizio critico di reagire a piccoli aumenti di carico. Una tolleranza più ampia altrove mantiene stabili i workloads più tranquilli. Era Beta nella v1.35 ed è ora il comportamento standard.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60
  behavior:
    scaleUp:
      tolerance: 0.05

La tolleranza è un rapporto, non un numero di punti percentuali. Con 0.05 e un target del 60%, l'HPA scala verso l'alto quando l'utilizzo della CPU supera circa il 63% (60% per 1,05). Reagisce quindi prima di quanto consentisse la vecchia tolleranza fissa del 10%.

3. Node Declared Features

Feature Group: SIG Node | KEP: #5328

In Kubernetes v1.37, le node declared features sono passate a General Availability (GA).

Prima di questa funzionalità, Kubernetes assumeva che un nodo potesse gestire qualsiasi funzionalità supportata dal control plane, purché le versioni rientrassero nello skew supportato. Non è sempre vero. Quando una nuova funzionalità veniva attivata sul control plane, lo scheduler poteva comunque posizionare un Pod che la usava su un nodo più vecchio che non la supportava ancora. Il Pod falliva quindi a runtime o restava bloccato dopo lo scheduling, anche se il posizionamento sembrava corretto.

Con la v1.37, il feature gate NodeDeclaredFeatures è GA. Ogni nodo pubblica ora l'insieme delle funzionalità che riconosce nel campo status.declaredFeatures dell'oggetto Node. Lo scheduler e i controlli di admission lo usano per posizionare i Pod che usano determinate funzionalità solo sui nodi che le supportano. Un errore a runtime si trasforma così in una decisione di scheduling chiara, cosa che conta soprattutto durante gli upgrade, quando le versioni dei nodi sono miste. Le node declared features erano Alpha nella v1.35.

Funzionalità Beta di Kubernetes v1.37

4. Scale to zero per gli HorizontalPodAutoscaler

Feature Group: SIG Autoscaling | KEP: #2021

In Kubernetes v1.37, lo scale to zero per l'HorizontalPodAutoscaler è passato a Beta ed è attivo di default.

Prima di questa funzionalità, un HPA non poteva portare un workload a zero repliche: il minimo era una. Per un servizio che ha lavoro solo a tratti, come un consumer di code o un worker batch, significava pagare per tenere in esecuzione almeno un Pod anche quando non c'era nulla da fare.

Con la v1.37 puoi impostare spec.minReplicas: 0 su un HPA e lasciare che riduca il workload a zero quando è inattivo, per poi riportarlo su quando torna la domanda. Funziona per i workloads guidati da metriche Object o External, come la lunghezza di una coda. Non funziona per le metriche di CPU o memoria, perché quelle metriche arrivano dai Pod in esecuzione, e a zero non ce ne sono. Questo può ridurre i costi per consumer di code, job batch e workloads GPU che restano inattivi tra un'esecuzione e l'altra. Mentre l'HPA mantiene un workload a zero, registra una condizione ScaledToZero impostata a True, così puoi distinguere un workload scalato a zero da uno disattivato manualmente. Quando torna a scalare verso l'alto, la condizione diventa False con la reason NotScaledToZero.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: worker-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: queue-worker
  minReplicas: 0
  maxReplicas: 20
  metrics:
  - type: External
    external:
      metric:
        name: queue_messages
      target:
        type: AverageValue
        averageValue: "30"

Con questa configurazione, il workload scende a zero Pod quando la coda è vuota e l'HPA lo riporta su non appena arrivano nuovi messaggi.

5. Memory QoS

Feature Group: SIG Node | KEP: #2570

In Kubernetes v1.37, Memory QoS è passata a Beta.

Prima di questa funzionalità, il kubelet impostava un limite rigido di memoria per un container (cgroup memory.max), ma non dava al kernel segnali più graduali. Un container poteva usare memoria fino al limite e poi subire un OOM kill quasi senza preavviso. Non esisteva inoltre una protezione della memoria legata alla request del container, quindi sotto pressione di memoria il kernel poteva recuperare pagine da un container ancora entro la propria request.

Con la v1.37, il feature gate MemoryQoS è Beta. Usa i controlli di memoria di cgroup v2 per dare al kernel segnali migliori. Il kubelet imposta memory.min in base alla memory request del container, proteggendo dal reclaim quella quantità di memoria. Quando imposti memoryThrottlingFactor nella configurazione del kubelet, il kubelet imposta anche memory.high come soglia di throttling sotto il limite. Il kernel rallenta quindi il container e recupera pagine prima che raggiunga il limite rigido e subisca un OOM kill. Di default memoryThrottlingFactor non è impostato e memory.high resta disattivato se non lo configuri. È richiesto cgroup v2, che dalla v1.35 è comunque l'unica modalità supportata.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
memoryThrottlingFactor: 0.9

Con questa impostazione, il kubelet imposta memory.high per i container al di sotto del loro limite di memoria, usando il fattore 0,9. Il kernel recupera memoria e applica throttling al container prima che raggiunga il limite rigido, rendendo meno probabili gli OOM kill sotto pressione.

6. Resource manager a livello di Pod

Feature Group: SIG Node | KEP: #5526

In Kubernetes v1.37, i resource manager a livello di Pod sono passati a Beta.

Kubernetes v1.34 ha aggiunto le risorse a livello di Pod (KEP #2837), che permettono di impostare request e limit di CPU e memoria per l'intero Pod invece che solo per singolo container. Ma i resource manager del kubelet non comprendevano ancora quei valori a livello di Pod. Prima di questa funzionalità, il CPU Manager, il Memory Manager e il Topology Manager guardavano solo le request per container. Un Pod che impostava le risorse a livello di Pod poteva perdere il pinning esclusivo delle CPU o l'allineamento NUMA.

Con la v1.37, il feature gate PodLevelResourceManagers è Beta. Nella v1.37 è disattivato di default: era stato attivato, poi disattivato di nuovo verso la fine del ciclo di release dopo che il team ha individuato problemi critici, quindi va abilitato manualmente se vuoi usarlo. Quando è attivo, il CPU Manager (policy static), il Memory Manager e il Topology Manager tengono conto delle risorse a livello di Pod quando assegnano CPU, memoria e località hardware. Questo aiuta i workloads sensibili alla latenza e di fascia alta che impostano le risorse a livello di Pod, che così ottengono comunque core esclusivi e memoria allineata a NUMA.

apiVersion: v1
kind: Pod
metadata:
  name: guaranteed-pod
spec:
  resources:              # pod-level resources
    requests:
      cpu: "2"
      memory: "4Gi"
    limits:
      cpu: "2"
      memory: "4Gi"
  containers:
  - name: app
    image: app:1.0
    # containers can set their own resources, or use the pod-level ones

Con questa configurazione, il Pod è Guaranteed a livello di Pod e i manager del kubelet possono riservargli intere CPU e allineare la memoria, anche quando il container non imposta le proprie request.

7. Gang scheduling con la Workload API

Feature Group: SIG Scheduling | KEP: #4671

In Kubernetes v1.37, il gang scheduling nativo tramite la Workload API è passato a Beta.

Prima di questa funzionalità, Kubernetes schedulava i Pod uno alla volta. Per un job strettamente accoppiato, come un training distribuito in cui tutti i worker devono partire insieme, questo causava scheduling parziali: alcuni Pod partivano mentre altri restavano pending, occupando risorse senza concludere nulla. I team dovevano aggiungere uno scheduler esterno per ottenere un comportamento all-or-nothing (gang). Kubernetes v1.35 ha introdotto il gang scheduling nativo come Alpha tramite una nuova Workload API.

Con la v1.37, l'API è ora scheduling.k8s.io/v1beta1. Si attiva con il feature gate GenericWorkload. Nella v1.37, i vecchi gate GangScheduling e WorkloadAwarePreemption sono stati fusi in GenericWorkload, quindi un unico gate copre ora sia il gang scheduling sia la preemption workload-aware. Il modello ha tre parti. Un Workload contiene uno o più podGroupTemplates, ognuno con una policy di scheduling come gang e un minCount. Un PodGroup viene creato da un template e traccia un singolo gruppo in esecuzione. Ogni Pod punta al proprio gruppo con schedulingGroup.podGroupName. Lo scheduler trattiene i Pod finché almeno minCount di essi non possono girare insieme, e a quel punto li posiziona. Se non riesce a soddisfare minCount, nessuno viene assegnato e i Pod attendono finché non c'è spazio. Il campo minCount resta modificabile dopo la creazione, il che aiuta i job elastici a scalare in su o in giù.

Il Workload definisce il template:

apiVersion: scheduling.k8s.io/v1beta1
kind: Workload
metadata:
  name: training-job
spec:
  podGroupTemplates:
  - name: workers
    schedulingPolicy:
      gang:
        minCount: 4

Un PodGroup viene creato da quel template:

apiVersion: scheduling.k8s.io/v1beta1
kind: PodGroup
metadata:
  name: training-job-workers-0
spec:
  workloadRef:
    workloadName: training-job
    templateName: workers
  schedulingPolicy:
    gang:
      minCount: 4

Ogni Pod entra nel gruppo tramite il nome:

apiVersion: v1
kind: Pod
metadata:
  name: worker-0
spec:
  schedulingGroup:
    podGroupName: training-job-workers-0
  containers:
  - name: trainer
    image: trainer:1.0
    # ...

Con questa configurazione, Kubernetes schedula i worker solo quando almeno quattro di essi possono girare insieme. Se il cluster non ha spazio per quattro, non ne parte nessuno.

8. Kubelet in user namespace (modalità rootless)

Feature Group: SIG Node | KEP: #2033

In Kubernetes v1.37, l'esecuzione del kubelet in uno user namespace, detta anche modalità Rootless, è passata a Beta.

Prima di questa funzionalità, i componenti del nodo come il kubelet giravano come root sull'host. Se il kubelet veniva compromesso, un attaccante poteva ottenere i privilegi di root sull'intero nodo.

Con la v1.37, il feature gate KubeletInUserNamespace è Beta. Esegue il kubelet e gli altri componenti del nodo dentro uno user namespace Linux. All'interno del namespace continuano ad apparire come root, ma sull'host sono mappati su un utente non privilegiato. Questo aggiunge un livello di isolamento senza cambiare l'uso quotidiano del kubelet. Questa funzionalità era in sviluppo dalla v1.22, quindi il passaggio a Beta è un traguardo importante.

Funzionalità Alpha di Kubernetes v1.37

9. Eviction Request API

Feature Group: SIG Node | KEP: #4563

Prima di questa funzionalità, il drain di un nodo per manutenzione era un'azione lato client. Uno strumento come kubectl drain sottoponeva a eviction i Pod uno per uno rispettando i PodDisruptionBudget, ma l'intento risiedeva nel client, non nel cluster. Controller e applicazioni non potevano vedere che un nodo era in fase di drain, coordinare un passaggio di consegne sicuro o partecipare alla decisione. Un'app stateful poteva subire eviction nel momento sbagliato perché nulla la informava della manutenzione imminente.

Con la v1.37, una funzionalità Alpha aggiunge l'API EvictionRequest, così l'eviction può essere cooperativa invece di una cancellazione forzata. Un richiedente crea un EvictionRequest per un Pod e i componenti registrati tramite il nuovo campo spec.evictionResponders del Pod gestiscono un passaggio di consegne graceful. La v1.37 aggiunge anche nuove condizioni del ciclo di vita del Node (MaintenancePlanned, MaintenanceInProgress, GracefulNodeShutdownInProgress, DrainInProgress e Drained) che i controller possono osservare per capire a che punto del flusso di manutenzione si trova un nodo. Insieme, questi elementi permettono a un'applicazione o a un operator di gestire il drain alle proprie condizioni, ad esempio spostando un leader o svuotando lo stato prima che il suo Pod venga rimosso.

10. Checkpoint e restore a livello di Pod

Feature Group: SIG Node | KEP: #5823

Prima di questa funzionalità, Kubernetes poteva fare il checkpoint di un singolo container (KEP #2008), principalmente per analisi forensi. Si poteva catturare lo stato di un singolo container, ma non di un intero Pod in una volta sola, quindi un Pod multi-container non poteva essere acquisito come singola unità.

Con la v1.37, una funzionalità Alpha aggiunge checkpoint e restore a livello di Pod. Estende la Container Runtime Interface (CRI) con le chiamate CheckpointPod e RestorePod, così il kubelet e un runtime compatibile possono fare lo snapshot di tutti i container di un Pod insieme e poi ripristinarli. È utile già oggi per il lavoro forense e getta le basi per usi futuri, come lo spostamento di un Pod in esecuzione tra nodi. La funzionalità richiede un container runtime che supporti le nuove chiamate CRI.