Kubernetes v1.35: cosa c'è di nuovo?

Funzionalità Stable di Kubernetes v1.35

1. Aggiornamento in-place delle risorse dei Pod****

Feature Group: SIG Node | KEP: #1287

Con Kubernetes v1.35, gli aggiornamenti in-place delle risorse CPU e memoria dei Pod sono passati a General Availability (GA).

Prima di questa funzionalità, era necessario ricreare il Pod ogni volta che si modificava .spec.resources.requests o .spec.resources.limits. Kubernetes trattava le modifiche alle risorse come campi immutabili, quindi anche una piccola variazione di CPU o memoria comportava un riavvio completo. Questo era problematico per i servizi stateful, i job batch di lunga durata e le applicazioni sensibili alla latenza. Inoltre, causava downtime.

Con la v1.35, Kubernetes consente di modificare le richieste o i limiti di CPU e memoria di un Pod in esecuzione senza dover riavviare il Pod o i suoi container. Ora è possibile applicare le modifiche alle risorse direttamente al container in esecuzione, quando il runtime e la configurazione del nodo lo supportano. Il kubelet aggiorna le impostazioni cgroup in place e il Pod continua a funzionare. Se una modifica alle risorse non può essere applicata in sicurezza, Kubernetes ricorre comunque alla ricreazione del Pod, preservando la retrocompatibilità. Questo rende lo scaling verticale più semplice, sicuro ed efficace.

2. Distribuzione del traffico PreferSameNode

Feature Group: SIG Network | KEP:#3015

In Kubernetes v1.35, la distribuzione del traffico PreferSameNode è in General Availability (GA).

Prima di questa modifica, Kubernetes offriva l'opzione PreferClose nel campo trafficDistribution. Era utile, ma poco chiara. PreferClose significava implicitamente "preferisci gli endpoint vicini", il che in pratica indicava una prossimità a livello di zona, non di nodo. Non c'era un modo esplicito per esprimere una preferenza rigorosamente locale al nodo, e l'API non comunicava chiaramente la differenza tra il routing a livello di nodo e quello a livello di zona.

Con la v1.35, Kubernetes permette di scegliere dove indirizzare il traffico dei Service. Può privilegiare fortemente gli endpoint che si trovano sullo stesso nodo del Pod client e usare gli endpoint remoti solo quando non ce ne sono di locali disponibili. Viene introdotta una nuova opzione, PreferSameNode, per dare priorità agli endpoint sullo stesso nodo. Allo stesso tempo, PreferClose viene rinominata PreferSameZone, rendendo l'API autoesplicativa e più chiara. PreferClose resta supportata per retrocompatibilità, ma PreferSameZone è ora l'opzione preferita ed esplicita per il routing zonale. Insieme, queste modifiche separano chiaramente le preferenze di traffico a livello di nodo e a livello di zona. È una funzionalità utile per i workloads attenti alle prestazioni, che vogliono ridurre latenza e traffico tra nodi.

apiVersion: v1
kind: Service
metadata:
  name: node-local-service
spec:
  selector:
    app: web
  ports:
  - port: 80
    targetPort: 8080
  trafficDistribution: PreferSameNode

Con questa configurazione, se un Pod client e un Pod di backend corrispondente girano sullo stesso nodo, Kubernetes instraderà il traffico localmente. Solo in assenza di endpoint locali il traffico verrà inviato ai Pod su altri nodi.

3. Limite configurabile di nodi NUMA per il Topology Manager

Feature Group: SIG Node | KEP:#4622

In Kubernetes v1.35, il limite configurabile di nodi NUMA del Topology Manager è passato a General Availability (GA).

NUMA (Non-Uniform Memory Access) è un'architettura hardware in cui un server è suddiviso in più regioni di memoria (nodi NUMA), ognuna collegata direttamente a un insieme specifico di CPU. Il Topology Manager è un componente del kubelet che allinea le allocazioni di CPU, memoria e dispositivi in modo che i workloads girino su hardware fisicamente vicino.

Prima di questa funzionalità, Kubernetes imponeva un limite rigido di 8 nodi NUMA ogni volta che il Topology Manager era abilitato. Questa misura di sicurezza serviva a prevenire l'esplosione combinatoria degli stati durante i calcoli di affinità NUMA. Di conseguenza, il kubelet disabilitava completamente il Topology Manager sui nodi con più di 8 nodi NUMA. Questa limitazione impediva a Kubernetes di sfruttare i grandi server multi-socket in cui la precisa localizzazione di CPU, memoria e dispositivi è cruciale per le prestazioni.

Con la v1.35, l'opzione di policy max-allowable-numa-nodes è ora stabile. Kubernetes consente agli amministratori dei cluster di eseguire il Topology Manager su macchine con più di 8 nodi NUMA. Questo rimuove il tetto artificiale e permette a Kubernetes di coordinare il posizionamento di CPU, memoria e dispositivi anche su macchine molto grandi. Sebbene esistano ancora problemi di prestazioni per sistemi NUMA estremamente grandi, Kubernetes offre ora agli operatori il controllo per attivare la funzione in base al proprio hardware e alle esigenze dei workloads.

Questa funzionalità consente quindi a Kubernetes di sfruttare meglio i moderni server di fascia alta comunemente usati per HPC, AI/ML, telecomunicazioni e workloads a bassa latenza.

apiVersion: kubelet.config.k8s.io/v1
kind: KubeletConfiguration
topologyManagerPolicy: restricted
topologyManagerScope: pod
topologyManagerPolicyOptions:
  max-allowable-numa-nodes: "true"

4. Nuova opzione di policy CPUManager per limitare reservedSystemCPUs

Feature Group: SIG Node | KEP: #4540

Prima di questa funzionalità, Kubernetes permetteva agli amministratori di riservare CPU specifiche al sistema tramite reservedSystemCPUs. Tuttavia, questa riserva era applicata solo ai Pod Guaranteed con richieste di CPU intere. I Pod Burstable e BestEffort, così come i Pod Guaranteed con richieste di CPU frazionarie, potevano comunque consumare tempo CPU su questi core riservati. Nei cluster reali, ciò causava problemi di "noisy neighbor" in cui i workloads applicativi interferivano con i processi di sistema, provocando instabilità dei nodi, ritardi nello scheduling o degrado delle prestazioni sotto carico.

Con Kubernetes v1.35, l'opzione strict-cpu-reservation per la policy statica del CPUManager è ora in General Availability (GA). Quando abilitata, Kubernetes impedisce rigorosamente a tutti i Pod, indipendentemente dalla classe QoS, di girare sulle CPU elencate in reservedSystemCPUs. Questo rende l'isolamento delle CPU prevedibile e affidabile, garantendo ai daemon di sistema una capacità CPU sempre dedicata. Il risultato: nodi più stabili e prestazioni migliori per i workloads sensibili alla latenza e ad alto throughput che girano accanto a componenti di sistema critici.

apiVersion: kubelet.config.k8s.io/v1
kind: KubeletConfiguration
cpuManagerPolicy: static
reservedSystemCPUs: "0-1"
cpuManagerPolicyOptions:
  strict-cpu-reservation: "true"

Con questa configurazione, le CPU 0-1 sono riservate esclusivamente al sistema operativo e ai daemon di sistema di Kubernetes. Nessun Pod applicativo, che sia BestEffort, Burstable o Guaranteed, può girare su queste CPU.

5. Limite del kubelet per i pull paralleli delle immagini

Feature Group: SIG Node | KEP: #3673

Il limite di pull paralleli delle immagini del kubelet controlla quante immagini container un nodo può scaricare contemporaneamente. Il pull delle immagini è un'operazione intensiva per rete e disco.

Prima di questa funzionalità, il comportamento del kubelet era di fatto binario. Con serializeImagePulls impostato a true, le immagini venivano scaricate una alla volta, evitando la contesa di risorse ma rallentando notevolmente l'avvio dei pod durante gli scale-up o i riavvii dei nodi. Con serializeImagePulls impostato a false, non c'era alcun limite superiore ai pull paralleli. Su nodi molto attivi, ciò poteva saturare la rete, sovraccaricare i dischi e ritardare altre operazioni critiche sul nodo.

Con Kubernetes v1.35, l'impostazione maxParallelImagePulls è ora in General Availability (GA). Consente agli amministratori di definire un limite superiore esplicito per i pull di immagini concorrenti. Kubernetes può ora scaricare più immagini in parallelo, ma solo fino a un limite sicuro definito dall'operatore. Eventuali pull aggiuntivi vengono messi in coda fino al completamento di un pull in corso, offrendo una concorrenza controllata anziché un comportamento "tutto o niente".

apiVersion: kubelet.config.k8s.io/v1
kind: KubeletConfiguration
serializeImagePulls: false
maxParallelImagePulls: 3

Con questa configurazione, il kubelet consente il pull simultaneo di massimo tre immagini su un nodo.

6. Garbage collection delle immagini del kubelet in base all'età massima

Feature Group: SIG Node | KEP:#4210

Prima di questa funzionalità, la garbage collection delle immagini del kubelet era guidata principalmente dalle soglie di utilizzo del disco. Le immagini venivano rimosse solo quando l'utilizzo del disco superava HighThresholdPercent, e la pulizia proseguiva finché l'utilizzo non scendeva sotto LowThresholdPercent. Pur essendo efficace per prevenire l'esaurimento del disco, questo significava che immagini usate raramente o obsolete potevano rimanere su disco indefinitamente, finché il nodo non si trovava sotto pressione a livello di disco. Nel tempo, ciò portava a cache di immagini sempre più voluminose e a un utilizzo inefficiente del disco.

Con Kubernetes v1.35, l'impostazione imageMaximumGCAge è ora stabile e consente al kubelet di eliminare tramite garbage collection le immagini non utilizzate per una durata specificata, indipendentemente dall'utilizzo del disco. Gli amministratori possono definire un'età massima per le immagini inutilizzate, espressa come durata. Una volta che un'immagine supera questa età senza essere usata, diventa candidata all'eliminazione. Questo integra la GC basata sul disco esistente e rende la pulizia delle immagini proattiva anziché reattiva.

apiVersion: kubelet.config.k8s.io/v1
kind: KubeletConfiguration
imageMaximumGCAge: 24h
imageGCHighThresholdPercent: 85
imageGCLowThresholdPercent: 70

Con questa configurazione, qualsiasi immagine container non utilizzata da 24 ore può essere rimossa dal kubelet, anche se l'utilizzo del disco è sotto la soglia massima.

7. Meccanismo managedBy dell'API Job

Feature Group: SIG Apps | KEP:#4368

Prima di questa funzionalità, ogni oggetto Job veniva sempre riconciliato dal controller Job integrato. Anche se un sistema esterno (come un controller personalizzato o uno scheduler multi-cluster) voleva gestirne l'esecuzione o lo stato, Kubernetes continuava comunque a creare Pod, aggiornare le condizioni del Job, ritentare i fallimenti e applicare la semantica di completamento. Questo rendeva complicati i casi d'uso avanzati, come il mirroring dei Job tra cluster, richiedendo annotazioni, workaround nei controller o logiche di soppressione per evitare conflitti.

Con Kubernetes v1.35, il campo managedBy è ora in General Availability (GA). Quando è impostato, Kubernetes tratta il Job come gestito esternamente e non ne riconcilia i Pod o lo stato. Questo abilita sistemi come MultiKueue, in cui un Job viene creato in un cluster di gestione, eseguito in un cluster worker e lo stato viene sincronizzato di ritorno, senza interferenze da parte del controller Job nativo. La funzionalità è volutamente limitata: consente la delega della gestione dei Job, ma non modifica la semantica dei Job, il comportamento dei CronJob né passa configurazioni al controller esterno.

apiVersion: batch/v1
kind: Job
metadata:
  name: delegated-job
spec:
  managedBy: kueue.x-k8s.io/multikueue
  ........

8. Pod Generation (tracciamento affidabile degli aggiornamenti dei Pod)

Feature Group: SIG Node | KEP: #5067

Prima di questa funzionalità, i Pod non avevano un campo metadata.generation come gli oggetti di livello superiore quali Deployment o StatefulSet. Sebbene i controller potessero aggiornare lo spec di un Pod, non esisteva un modo integrato e monotonico per sapere se il kubelet avesse già elaborato una determinata modifica. Era quindi difficile rilevare in modo affidabile se un aggiornamento del Pod fosse ancora in sospeso, applicato parzialmente o completamente riflesso nello stato, soprattutto per gli aggiornamenti in-place e le modifiche rapide e successive.

Con Kubernetes v1.35, il tracciamento della generazione dei Pod è ora in General Availability (GA). Ogni Pod parte con metadata.generation: 1 e ogni aggiornamento a un campo mutabile nello spec del Pod incrementa questo valore. Il kubelet registra la generazione elaborata in status.observedGeneration. Questo rende esplicito se lo stato attuale del Pod riflette l'ultimo spec desiderato o una versione precedente. I controller esterni possono confrontare in sicurezza questi due campi per determinare se la riconciliazione è completa, senza affidarsi a tempistiche o supposizioni.

Funzionalità Beta di Kubernetes v1.35

9. Tolleranza configurabile per gli HorizontalPodAutoscaler

Feature Group: SIG Autoscaling | KEP: #4951

L'Horizontal Pod Autoscaler (HPA) regola automaticamente il numero di repliche dei Pod di un workload in base a metriche osservate come l'utilizzo di CPU o memoria.

Prima di questa funzionalità, l'HPA usava una tolleranza fissa del 10% a livello di cluster per decidere se scalare. Questo valore non era configurabile per singolo workload. Di conseguenza, le applicazioni molto sensibili potevano non scalare quando dovevano reagire a piccoli aumenti di carico, mentre altri workloads potevano subire scaling non necessari o oscillazioni. Modificare questo comportamento richiedeva la modifica di un flag globale del controller, con impatto su ogni HPA del cluster.

Con Kubernetes v1.35, la tolleranza configurabile è passata in Beta ed è abilitata per impostazione predefinita. Ora è possibile definire valori di tolleranza per singolo HPA e per direzione di scaling tramite il campo behavior. Questo offre un controllo granulare sulla sensibilità dell'autoscaling senza influire su altri workloads. Gli operatori possono configurare i servizi critici per scalare in modo aggressivo, mantenendo stabili i workloads meno sensibili.

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

Con questa configurazione, l'HPA effettua lo scale-up solo quando l'utilizzo della CPU supera il 65% (5% oltre il target).

10. Limiti di attach dei volumi modificabili

Feature Group: SIG Storage | KEP:#4876

I limiti di attach dei volumi definiscono quanti volumi di storage possono essere collegati a un nodo in un dato momento. Kubernetes si basa su questa informazione per decidere dove schedulare i Pod che usano volumi persistenti. I driver CSI segnalano questi limiti tramite l'oggetto CSINode.

Prima di questa funzionalità, la capacità di attach dei volumi riportata in CSINode.spec.drivers[*].allocatable.count era statica. Una volta che un driver CSI registrava il proprio limite di attach all'avvio, Kubernetes assumeva che quel valore fosse sempre accurato. Se gli slot dei volumi venivano consumati in seguito, a causa di operazioni esterne, riavvii del nodo o guasti transitori, lo scheduler poteva comunque posizionare Pod su nodi che non avevano più capacità. Il risultato erano Pod bloccati in ContainerCreating perché il volume non poteva effettivamente essere collegato.

Con Kubernetes v1.35, il limite di attach allocabile dei volumi è ora modificabile e la funzionalità è in Beta, abilitata per impostazione predefinita. I driver CSI possono aggiornare dinamicamente la capacità di attach disponibile di un nodo a runtime. Kubernetes introduce inoltre un intervallo di aggiornamento configurabile tramite l'oggetto CSIDriver, permettendo ai driver di controllare la frequenza di ricalcolo dei conteggi allocabili. Inoltre, Kubernetes aggiorna automaticamente il conteggio allocabile quando rileva fallimenti di attach dovuti a capacità insufficiente. Questo rende le decisioni di scheduling più accurate e riduce significativamente gli avvii di Pod falliti o bloccati.

apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
  name: example.csi.storage
spec:
  attachRequired: true
  nodeAllocatableUpdatePeriodSeconds: 30  # Note: minimum is 10 seconds

Questo configura chiamate periodiche del kubelet all'endpoint NodeGetInfo del driver CSI ogni 30 secondi per aggiornare CSINode.spec.drivers[].allocatable.count

11. Opportunistic batching

Feature Group: SIG Scheduling | KEP: #5598

L'opportunistic batching è un'ottimizzazione dello scheduler che migliora le prestazioni quando Kubernetes schedula molti Pod con requisiti di scheduling identici o equivalenti.

Prima di questa funzionalità, il kube-scheduler elaborava i Pod uno alla volta, con una complessità di scheduling proporzionale al numero di Pod moltiplicato per il numero di nodi. Anche quando più Pod erano identici dal punto di vista dello scheduling — stesse richieste di risorse, affinità e vincoli — lo scheduler ripeteva gli stessi calcoli di filtering e scoring per ogni Pod. Questo comportava lavoro ridondante e scheduling lento, in particolare per i job batch, i workloads di ML e la creazione di repliche su larga scala.

Con Kubernetes v1.35, l'opportunistic batching viene introdotto come funzionalità Beta, abilitata per impostazione predefinita. Lo scheduler ora calcola una signature di scheduling del pod, che cattura tutti gli aspetti rilevanti per lo scheduling di un Pod, inclusi gli spec del pod, gli attributi dei nodi e lo stato del cluster. Quando Pod con la stessa signature arrivano consecutivamente nella coda di scheduling, lo scheduler li raggruppa in batch. Memorizza in cache i risultati di scheduling del primo Pod e li riutilizza per i Pod successivi con la stessa signature, evitando calcoli ripetuti. La cache ha vita breve e viene aggiornata automaticamente per garantire la correttezza al variare dello stato del cluster.

Questa ottimizzazione funziona in modo trasparente — non è richiesta alcuna configurazione da parte dell'utente — e va a vantaggio soprattutto dei workloads con molti Pod identici, come Job, worker ML paralleli e deployment su larga scala. Riducendo il lavoro di scheduling ridondante, Kubernetes può posizionare i Pod più velocemente e scalare i workloads in modo più efficiente sotto carichi elevati.

12. maxUnavailable per gli StatefulSet

Feature Group: SIG Apps | KEP: #961

Uno StatefulSet gestisce un insieme di Pod che richiedono identità stabili, avvio e terminazione ordinati e storage persistente.

Prima di questa funzionalità, gli StatefulSet con strategia RollingUpdate aggiornavano i Pod rigorosamente uno alla volta, partendo dall'ordinal più alto. Non c'era modo di controllare quanti Pod potessero essere indisponibili durante un aggiornamento. Anche se un'applicazione stateful poteva tollerare la temporanea indisponibilità di più Pod, Kubernetes imponeva comunque aggiornamenti serializzati, con tempi di rollout lunghi per gli StatefulSet di grandi dimensioni.

Con Kubernetes v1.35, il campo maxUnavailable per i rolling update degli StatefulSet è ora in Beta e abilitato per impostazione predefinita. Consente agli operatori di specificare quanti Pod possono essere indisponibili durante un aggiornamento, come numero assoluto o come percentuale delle repliche. In combinazione con podManagementPolicy: Parallel, Kubernetes può aggiornare più Pod contemporaneamente pur rispettando i vincoli di disponibilità. Se non impostato, il valore predefinito resta 1, preservando il comportamento precedente.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: database
spec:
  replicas: 10
  podManagementPolicy: Parallel
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 20%
      ........

13. Stato dei Deployment: conteggio delle repliche in terminazione

Feature Group: SIG Apps | KEP: #3973

Un Deployment gestisce i rolling update e lo scaling dei Pod, e il suo stato viene usato da operatori e automazioni per comprendere l'avanzamento dei rollout.

Prima di questa funzionalità, lo stato del Deployment riportava solo campi come replicas, updatedReplicas, readyReplicas e availableReplicas. I Pod in fase di terminazione non erano esplicitamente visibili nello stato del Deployment. Era quindi difficile capire se un Deployment fosse realmente stabile o avesse ancora Pod in fase di pulizia in background. Operatori e controller dovevano elencare i Pod manualmente e filtrare per deletionTimestamp, un approccio inefficiente e soggetto a errori.

Con Kubernetes v1.35, il campo status.terminatingReplicas è promosso a Beta e abilitato per impostazione predefinita (con il feature gate DeploymentReplicaSetTerminatingReplicas abilitato sull'API server e sul controller manager). Questo campo riporta il numero di Pod in terminazione ma non ancora completamente rimossi. Migliora l'osservabilità durante i rollout e gli eventi di scale-down e getta le basi per futuri miglioramenti nel comportamento dei Deployment, come politiche di sostituzione dei Pod più intelligenti che tengano conto dell'avanzamento dello shutdown.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
status:
  replicas: 5
  updatedReplicas: 5
  readyReplicas: 4
  availableReplicas: 4
  terminatingReplicas: 1
  ........

14. Esposizione delle label di topologia dei nodi tramite la Downward API

Feature Group: SIG Node | KEP:#4742

Le label di topologia dei nodi descrivono dove un Pod è in esecuzione nell'infrastruttura, ad esempio la regione o la zona di disponibilità del nodo.

Prima di questa funzionalità, i Pod non potevano accedere direttamente alle informazioni di topologia del nodo. I workloads che avevano bisogno dei dati di zona o regione dovevano interrogare l'API server di Kubernetes, affidarsi a sidecar o ottenere permessi RBAC aggiuntivi. Questo aumentava la complessità operativa e introduceva rischi di sicurezza, ampliando i permessi dei Pod applicativi oltre il necessario.

Con Kubernetes v1.35, le label di topologia dei nodi vengono ora iniettate nei Pod ed esposte tramite la Downward API, con la funzionalità in Beta e abilitata per impostazione predefinita. Il kubelet propaga le label standard come topology.kubernetes.io/zone e topology.kubernetes.io/region dal nodo al Pod, rendendole disponibili come variabili d'ambiente o file proiettati. Questo consente ai workloads di diventare topology-aware senza accesso all'API, semplificando la configurazione e rispettando il principio del privilegio minimo.

apiVersion: v1
kind: Pod
metadata:
  name: topology-aware-pod
spec:
  containers:
  - name: app
    image: busybox
    command: ["sh", "-c", "env"]
    env:
    - name: ZONE
      valueFrom:
        fieldRef:
          fieldPath: metadata.labels['topology.kubernetes.io/zone']
    - name: REGION
      valueFrom:
        fieldRef:
          fieldPath: metadata.labels['topology.kubernetes.io/region']

Con questa configurazione, il Pod riceve automaticamente la zona e la regione del nodo su cui è in esecuzione.

Funzionalità Alpha di Kubernetes v1.35

15. Supporto al gang scheduling in Kubernetes

Feature Group: SIG Scheduling | KEP: #4671

Prima di questa funzionalità, Kubernetes schedulava i Pod individualmente. Per i workloads strettamente accoppiati, questo comportava scheduling parziali: alcuni Pod si avviavano mentre altri restavano in attesa per carenza di risorse. Questi job parzialmente schedulati potevano andare in deadlock, sprecare risorse del cluster e bloccare altri workloads, costringendo gli utenti a ricorrere a scheduler esterni o controller personalizzati per applicare la semantica di gang.

Con Kubernetes v1.35, il gang scheduling nativo viene introdotto come funzionalità Alpha, tramite la nuova Workload API e le policy di gruppo dei pod. Gli utenti definiscono un Workload che raggruppa i Pod e specifica un requisito minCount. Lo scheduler trattiene i Pod finché il gruppo non è completo, poi tenta di posizionarli insieme. Se non riesce a schedulare almeno il numero richiesto di Pod entro un timeout, nessuno viene assegnato e i Pod attendono finché non ci sono risorse sufficienti. Questo porta il supporto alla semantica di gang direttamente in Kubernetes, a livello di scheduler e come funzionalità di prima classe.

Esempio:

Workload che definisce un gruppo (gang) di Pod

apiVersion: scheduling.k8s.io/v1alpha1
kind: Workload
metadata:
  name: ml-training
spec:
  podGroups:
  - name: workers
    policy:
      gang:
        minCount: 4

Pod collegato al Workload:

apiVersion: v1
kind: Pod
metadata:
  name: worker-0
spec:
  workloadRef:
    name: ml-training
    podGroup: workers
  containers:
  - name: trainer
    image: <your-image>

Con questa configurazione, Kubernetes schedula i Pod solo quando almeno quattro worker possono girare insieme. Se il cluster non può soddisfare questo requisito, nessuno dei Pod viene avviato.

16. Operatori di toleration estesi per il posizionamento basato su soglie

Feature Group: SIG Scheduling | KEP: #5471

In Kubernetes, taint e toleration servono a controllare dove i Pod possono girare. I nodi usano i taint per dire "non posizionare Pod qui", mentre i Pod usano le toleration per dire "posso girare su questo nodo".

Prima di questa funzionalità, le toleration supportavano solo operatori di base come Exists ed Equal. Un Pod poteva quindi tollerare un taint oppure no, ma non poteva esprimere gradi di tolleranza. Ad esempio, un workload non poteva dire "esegui solo su nodi con SLA ≥ 99,9" o "evita i nodi con affidabilità sotto una certa soglia". Di conseguenza, i cluster che volevano un posizionamento basato sugli SLA dovevano affidarsi a scheduler personalizzati, node pool multipli o logiche di admission complesse.

Con Kubernetes v1.35, le toleration acquisiscono operatori di confronto numerico (con semantiche come maggiore-di o minore-di) e diventano parte dello scheduling esteso. I nodi possono esporre taint orientati agli SLA (ad esempio punteggi di affidabilità o qualità del fault domain), e i Pod possono specificare toleration che corrispondono solo se il valore del taint del nodo soddisfa una condizione numerica. Questo permette ai workloads critici di puntare a nodi con SLA elevati, mentre i workloads best-effort possono girare intenzionalmente su infrastrutture a costo e SLA più bassi, migliorando l'utilizzo senza sacrificare l'affidabilità.

Taint del nodo che esprime un livello di SLA:

kubectl taint nodes node-a
servicelevel.org.example/agreed-service-level=800:NoSchedule

Pod che tollera solo nodi con SLA sufficiente:

apiVersion: v1
kind: Pod
metadata:
  name: sla-tolerant-pod
spec:
  tolerations:
  - key: servicelevel.org.example/agreed-service-level
    operator: LessThan
    value: "900"
    effect: NoSchedule
  containers:
  - name: app
    image: busybox
    command: ["sh", "-c", "echo running on lower-SLA node"]

Con questa configurazione, il Pod verrà schedulato solo sui nodi il cui valore del taint SLA è inferiore a 900.

17. Risorse dei container modificabili quando un Job è sospeso

Feature Group: SIG Apps | KEP: #5440

Un Job di Kubernetes esegue un task fino al completamento con successo e ne garantisce la conclusione.

Prima di questa funzionalità, il template dei Pod all'interno di un Job era di fatto immutabile. Se un Job falliva per CPU o memoria insufficienti (ad esempio ripetuti OOM kill), gli utenti non avevano modo di modificare i valori delle risorse sul Job esistente. L'unica opzione era eliminare il Job e crearne uno nuovo con risorse aggiornate, perdendo così la cronologia del Job, lo stato e qualsiasi strumento che ne tracciasse i progressi o i retry.

Con Kubernetes v1.35, per i Job in stato sospeso è possibile modificare richieste e limiti delle risorse dei container, quando il feature gate MutableJobPodResourcesForSuspendedJobs è abilitato. Gli utenti possono sospendere un Job in errore, aggiornare il template dei Pod con valori di risorse appropriati e poi riprendere il Job. Kubernetes prosegue l'esecuzione con la configurazione aggiornata, preservando l'identità e lo stato del ciclo di vita del Job, rendendo molto più agevole il recupero da risorse configurate in modo errato.

apiVersion: batch/v1
kind: Job
metadata:
  name: data-processor
spec:
  suspend: true
  template:
    spec:
      restartPolicy: OnFailure
      containers:
      - name: worker
        image: busybox
        command: ["sh", "-c", "echo processing && sleep 30"]
        resources:
          requests:
            cpu: "1"
            memory: "1Gi"
          limits:
            cpu: "2"
            memory: "2Gi"

Dopo aver aggiornato le risorse, il Job può essere ripreso impostando spec.suspend a false. Il Job prosegue con i nuovi valori di CPU e memoria, senza eliminare o ricreare il Job.

18. Dichiarazione delle funzionalità dei nodi prima dello scheduling

Feature Group: SIG Node | KEP: #5328

Prima di questa funzionalità, Kubernetes assumeva che i nodi fossero ampiamente compatibili con il control plane, entro lo skew di versione supportato. Quando nuove funzionalità venivano abilitate a livello di control plane, lo scheduler poteva comunque posizionare Pod che usavano tali funzionalità su nodi più vecchi che non le supportavano ancora. Il risultato erano errori a runtime, comportamenti anomali difficili da individuare o Pod bloccati dopo lo scheduling, anche se la decisione di posizionamento in sé sembrava valida.

Con Kubernetes v1.35, una funzionalità Alpha introduce un meccanismo formale con cui i nodi dichiarano le funzionalità supportate tramite un nuovo campo status.declaredFeatures sull'oggetto Node. Quando abilitata, i nodi pubblicano l'insieme delle funzionalità di Kubernetes che comprendono. Lo scheduler, gli admission controller e i componenti esterni possono quindi usare queste informazioni per validare i Pod e limitare lo scheduling ai nodi compatibili, prevenendo i problemi di feature skew prima dell'assegnazione dei Pod.