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

Kubernetes 1.37: funzionalità stabili (GA)

1. La Metrics API diventa stabile

Feature Group: SIG Instrumentation | KEP: KEP-5207

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

Non ci sono cambiamenti funzionali. Sia v1 che v1beta1 continuano a funzionare, quindi per ora non dovete modificare nulla. Ma se state sviluppando strumenti che usano questa API, potete adottare la v1 con fiducia: è stabile e non cambierà in modo inaspettato.

2. Risorse a livello di pod

Fino a oggi era necessario impostare request e limit delle risorse per ogni container di un pod, anche quando i container erano pensati per lavorare insieme.

Le risorse a livello di pod permettono di definire request/limit di CPU, memoria e hugepages a livello di pod invece che (o insieme a quelli) a livello 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 un'allocazione fissa. Questo riduce lo spreco di risorse e funziona meglio per i workloads multi-container con picchi di utilizzo delle risorse.

3. DRA: taints e tolerations per i 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 voi, possono applicare un taint a un device specifico (ad esempio una GPU in surriscaldamento o in fase di drain per manutenzione).

Un taint NoSchedule impedisce ai nuovi pod di usare quel device, mentre un taint NoExecute rimuove i pod che lo stanno già utilizzando. Se un workload deve comunque usare il device, può aggiungere una toleration corrispondente alla propria ResourceClaim.

In questo modo potete 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% su tutto il cluster per evitare operazioni di scaling causate da 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 stabile, potete impostare una tolleranza personalizzata per ogni HPA, con valori separati per scale-up e scale-down sotto spec.behavior.scaleUp e spec.behavior.scaleDown. Ogni workload può così 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 a breve durata senza passare per i bearer token. Una nuova API PodCertificateRequest gestisce l'emissione, e un projected volume PodCertificate permette al kubelet di consegnare chiave e certificato direttamente al pod, con rotazione automatica.

Questo rende più semplice configurare in modo nativo le architetture mTLS (inclusi strumenti di terze parti come HashiCorp Vault), senza i sidecar aggiuntivi o l'infrastruttura di webhook che molte 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: parentesi graffe per le mappe, parentesi quadre per le liste, virgolette doppie per le stringhe. Consente ancora commenti e virgole finali, ma elimina le classiche trappole di YAML, come no interpretato silenziosamente come booleano false (il "problema della Norvegia").

Ora è un'opzione di output stabile per kubectl, quindi potete generare manifest in questo formato senza preoccuparvi che conversioni di tipo accidentali rompano la vostra configurazione.

7. Rietichettatura SELinux ricorsiva più veloce (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 avviarsi. Su un volume con milioni di file, questa operazione da sola 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 la label corretta in un'unica operazione di mount. Questo avviene solo quando il driver CSI del volume aderisce esplicitamente tramite CSIDriver.spec.seLinuxMount: true.

Un aspetto importante da ricordare: un singolo mount può avere un solo contesto SELinux. Se attualmente avete pod con label 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 ad avviarsi. Se vi serve il vecchio comportamento per un workload specifico, impostate seLinuxChangePolicy: Recursive nella spec del pod. I cluster senza SELinux abilitato non subiscono alcun cambiamento.

Funzionalità beta di Kubernetes 1.37

8. Kubelet in User Namespace (modalità rootless)

Feature Group: SIG Node | KEP: KEP-2033

I componenti dei nodi 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 un user namespace Linux. All'interno del namespace continua ad apparire come root, ma sull'host reale è mappato su un utente senza privilegi. Questa funzionalità passa in beta in Kubernetes v1.37 e aggiunge un ulteriore livello di isolamento senza cambiare il modo in cui usate il kubelet nel quotidiano.

9. Scaling HPA da/a zero per metriche object ed external

Feature Group: SIG Autoscaling | KEP: KEP-2021

L'Horizontal Pod Autoscaler (HPA) è in grado di scalare a zero repliche usando metriche object o external già da tempo. 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. Serializer 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 in fase di compilazione. CBOR è un formato binario che non ha questo requisito, e i primi benchmark mostrano un encoding fino a 8 volte più veloce e un decoding fino a 2 volte più veloce per le custom resource rispetto a JSON. I client lo negoziano automaticamente e ripiegano su JSON con gli API server più vecchi, quindi il rollout è sicuro.

Funzionalità alpha di Kubernetes 1.37

Queste funzionalità sono in alpha: non sono 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, di solito lo scoprite solo con un mount fallito o un blocco di I/O: non c'è un segnale strutturato su cui agire. Questa funzionalità introduce quattro nuove RPC CSI, così i driver possono segnalare lo stato di salute dei volumi in un formato 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 di salute 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 consuete 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 la funzionalità funziona solo con il profilo Privileged dei Pod Security Standards, e Kubernetes verifica il supporto del nodo prima di schedulare il pod, così da non eseguirlo 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 vendor hardware usano lo stesso nome di attributo, cosa che di solito non accade. Supponiamo che vogliate 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 permettono di scrivere un'espressione CEL nella richiesta del device che costruisce un attributo virtuale a partire da ciò che il driver già espone. Ottenete così una chiave comune, come l'ID del nodo NUMA, su cui lo scheduler può fare il match. Potete quindi abbinare GPU e NIC sullo stesso nodo NUMA senza aspettare che tutti i vendor concordino su un unico schema di denominazione.

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