Release di Kubernetes 1.37: nuove funzionalità, beta e stable

Kubernetes 1.37: funzionalità Stable (GA)

1. Le Metrics API diventano stable

Feature Group: SIG Instrumentation | KEP: KEP-5207

L'API metrics.k8s.io è rimasta in beta per anni. È l'API dietro kubectl top e le metriche di CPU e memoria dell'Horizontal Pod Autoscaler. Con la v1.37 diventa finalmente stable.

Non ci sono cambiamenti funzionali. Sia v1 che v1beta1 continuano a funzionare, quindi per ora non devi cambiare nulla. Ma se stai sviluppando strumenti che usano questa API, ora puoi adottare la v1 con tranquillità: è stable e non cambierà in modo inatteso.

2. Risorse a livello di pod

Prima di questa novità dovevi impostare richieste e limiti di risorse per ogni container di un pod, anche se i container erano pensati per lavorare insieme.

Le risorse a livello di pod ti permettono di impostare richieste/limiti di CPU, memoria e hugepages a livello di pod invece che (o insieme a) quello di container.

spec:
  resources:
    requests:
      cpu: "1"
      memory: "512Mi"
    limits:
      cpu: "2"
      memory: "1Gi"
  containers:
  - name: app
    image: my-app
  - name: sidecar
    image: my-sidecar

Tutti i container del pod possono così condividere lo stesso pool di risorse invece di avere ciascuno una propria allocazione fissa. Questo riduce lo spreco di risorse e funziona meglio per i workloads multi-container con consumi a burst.

3. DRA: taint e toleration dei device

Feature Group: SIG Scheduling | KEP: KEP-5055

Questa funzionalità porta il modello dei taint dei nodi nella Dynamic Resource Allocation (DRA). I driver DRA, o una DeviceTaintRule scritta da te, possono applicare un taint a un device specifico (ad esempio una GPU che si sta surriscaldando o che viene svuotata per manutenzione).

Un taint NoSchedule impedisce ai nuovi pod di usare quel device, mentre un taint NoExecute rimuove i pod che lo stanno già usando. Se un workload ha comunque bisogno di usare il device, può aggiungere una toleration corrispondente nella sua ResourceClaim.

In questo modo puoi isolare una singola GPU o NIC invece di mettere in cordon l'intero nodo.

4. Tolleranza configurabile per l'HPA

Feature Group: SIG Autoscaling | KEP: KEP-4951

L'Horizontal Pod Autoscaler (HPA) ha sempre usato una tolleranza fissa del 10% per l'intero cluster, per evitare scaling dovuti a piccole variazioni nelle metriche. Ma lo stesso 10% non ha senso per ogni workload. Una variazione del 10% per un workload con 500 pod è molto diversa da una per un workload con 5 pod.

Con questa funzionalità ora stable puoi impostare una tolleranza personalizzata per ciascun HPA, con valori separati per scale-up e scale-down sotto spec.behavior.scaleUp e spec.behavior.scaleDown. Così ogni workload può scalare in modo più appropriato senza modificare il default a livello di cluster.

5. Certificati per i pod

Feature Group: SIG Auth | KEP: KEP-4317

Questa funzionalità offre ai pod un modo nativo per ottenere certificati X.509 di breve durata senza passare dai bearer token. Una nuova API PodCertificateRequest gestisce l'emissione, e un volume projected PodCertificate permette al kubelet di consegnare chiave e certificato direttamente al pod, con rotazione automatica.

Questo rende più semplice configurare in modo nativo setup mTLS (compresi strumenti di terze parti come HashiCorp Vault), senza il sidecar o il webhook aggiuntivi che molti service mesh usano oggi.

6. Output KYAML per kubectl

Feature Group: SIG CLI | KEP: KEP-5295

KYAML è un sottoinsieme di YAML più rigoroso e in salsa Kubernetes: graffe per le mappe, parentesi quadre per le liste, virgolette doppie per le stringhe. Continua a consentire commenti e virgole finali, ma elimina le classiche trappole di YAML, come il parsing silenzioso come booleano false (il "problema della Norvegia").

Ora è un'opzione di output stable per kubectl, quindi puoi generare manifest in questo formato senza preoccuparti che una coercizione di tipo accidentale rompa la tua configurazione.

7. Velocizzare il cambio ricorsivo delle etichette SELinux (SELinuxMount)

Feature Group: SIG Storage | KEP: KEP-1710

Sui nodi con SELinux abilitato, Kubernetes rietichettava ogni file di un volume uno per uno prima che un pod potesse partire. Su un volume con milioni di file, questo da solo poteva richiedere minuti.

SELinuxMount passa in GA ed è abilitato di default nella v1.37. Invece di rietichettare file per file, i volumi vengono montati con -o context=<label>; l'intero volume riceve l'etichetta corretta in una singola operazione di mount. Questo entra in gioco solo quando il driver CSI del volume aderisce tramite CSIDriver.spec.seLinuxMount: true.

Una cosa importante da ricordare: un singolo mount può portare un solo contesto SELinux. Se oggi hai pod con etichette SELinux diverse che condividono lo stesso volume sullo stesso nodo (cosa che funzionava senza problemi con la vecchia rietichettatura ricorsiva), quei pod potrebbero ora non riuscire a partire. Se ti serve il vecchio comportamento per un workload specifico, imposta seLinuxChangePolicy: Recursive nella spec del pod. I cluster senza SELinux abilitato non vedono alcun cambiamento.

Funzionalità Beta di Kubernetes 1.37

8. Kubelet in User Namespace (modalità rootless)

Feature Group: SIG Node | KEP: KEP-2033

I componenti del nodo come il kubelet vengono normalmente eseguiti come root sull'host. Se il kubelet viene compromesso, un attaccante potrebbe ottenere accesso root al nodo.

Kubelet in UserNS esegue invece il kubelet all'interno di uno user namespace Linux. All'interno del namespace continua ad apparire come root, ma sull'host reale è mappato su un utente non privilegiato. Questa funzionalità passa in beta in Kubernetes v1.37 e aggiunge un ulteriore livello di isolamento senza cambiare il modo in cui usi il kubelet nel quotidiano.

9. HPA: scale to/from zero per metriche Object ed External

Feature Group: SIG Autoscaling | KEP: KEP-2021

Da tempo l'Horizontal Pod Autoscaler (HPA) può scalare a zero repliche usando metriche object o external. Ma non c'era un modo semplice per sapere se era stato l'HPA a portare un workload a zero o se qualcuno l'aveva impostato a zero in altro modo.

Kubernetes v1.37 aggiunge una condizione di stato ScaledToZero all'oggetto HPA, rendendo chiara questa differenza. È particolarmente utile per i workloads event-driven, come quelli basati sulla profondità delle code o su trigger in stile KEDA, che scalano a zero quando sono inattivi e risalgono quando arriva nuovo lavoro.

10. Serializzatore CBOR

Feature Group: SIG API Machinery | KEP: KEP-4222

Le risorse integrate di Kubernetes usano Protobuf per mantenere veloci le chiamate API, ma le CRD non possono usare facilmente Protobuf perché richiede la generazione di codice a compile time. CBOR è un formato binario che non ha questo requisito, e i primi benchmark mostrano una codifica fino a 8 volte più veloce e una decodifica 2 volte più veloce per le risorse custom rispetto a JSON. I client lo negoziano automaticamente e ricadono su JSON con gli API server più vecchi, quindi il rollout è sicuro.

Funzionalità Alpha di Kubernetes 1.37

Queste funzionalità sono in alpha: non pronte per la produzione, ma vale la pena provarle in un cluster di staging.

11. Volume Health Monitor

Feature Group: SIG Storage | KEP: KEP-1432

Oggi, se un volume CSI ha un problema a livello di storage, in genere lo scopri solo con un mount fallito o un blocco di I/O; non c'è un segnale strutturato su cui agire. Questa novità introduce quattro nuove RPC CSI per permettere ai driver di segnalare lo stato di salute dei volumi in un modo su cui i controller possono agire. Sul lato controller, ControllerListVolumeHealth elenca i volumi non integri e ControllerGetVolumeHealth ne verifica uno specifico; un health monitor lato controller li interroga periodicamente e scrive il risultato in PersistentVolumeClaim.status.healthStatus. Sul lato nodo, il kubelet chiama NodeGetVolumeHealth per i singoli volumi (registrato in Pod.status.volumeHealth) e NodeGetStorageHealth per lo stato dei driver su quel nodo. Questo dà ai controller di remediation qualcosa di leggibile dalle macchine su cui agire, invece di dover incrociare a mano le dashboard dei vendor.

12. ulimits per container

Feature Group: SIG Node | KEP: KEP-5758

Alcune applicazioni, come i database e le applicazioni ad alta concorrenza, hanno bisogno di limiti POSIX più alti, come il numero massimo di file aperti o di processi, rispetto a quelli forniti di default dal container runtime. Finora le opzioni abituali erano script di entrypoint personalizzati o la modifica della configurazione dell'host.

Kubernetes v1.37 aggiunge un campo ulimits a Container.SecurityContext. Il kubelet passa questi limiti al container runtime. Al momento questa funzionalità funziona solo con il profilo Privileged dei Pod Security Standards, e Kubernetes verifica il supporto del nodo prima di schedulare il pod, così non finisce su un nodo che non può applicare i limiti richiesti.

13. DRA: attributi derivati

Feature Group: SIG Scheduling | KEP: KEP-6080

DRA può già abbinare i device in base ad attributi condivisi, ma solo se i diversi produttori di hardware usano lo stesso nome di attributo, cosa che di solito non accade. Supponiamo che tu voglia una GPU e una NIC veloce sullo stesso nodo NUMA: lo scheduler ha bisogno di nomi e valori di attributi corrispondenti, ma ogni vendor descrive la topologia a modo suo.

Gli attributi derivati ti permettono di scrivere un'espressione CEL nella tua device request che costruisce un attributo virtuale a partire da ciò che il driver già espone. Ottieni così una chiave comune, come l'ID di un nodo NUMA, su cui lo scheduler può fare match. Puoi quindi abbinare GPU e NIC sullo stesso nodo NUMA senza aspettare che ogni vendor concordi su uno schema di naming unico.

Questa funzionalità è in alpha e l'API sta ancora prendendo forma, quindi provala in un cluster di staging e controlla il KEP per i campi esatti prima di usarla.