Kubernetes v1.24: “Stargazer”

Kubernetes v1.24 è la prima release del 2022. In questa release sono presenti 46 miglioramenti. 14 dei quali sono stati rilasciati in “stable”, mentre 15 sono entrati nella fase “beta” e 13 sono in “alpha”.

Inoltre, due funzionalità sono state deprecate e altre due sono state rimosse.

Temi principali

Tra i numerosi cambiamenti introdotti possiamo trovare:

• Rimozione di dockershim dal kubelet
• Le API beta saranno spente di default
• Aggiunta la firma per gli artefatti di release
• Prevenzione dei duplicati nell’allocazione degli IP per i “Service”
• Le funzionalità “Storage Capacity” e “Volume Expansion” sono generalmente disponibili
• “DynamicKubeletConfig” rimosso

Rimozione di dockershim dal kubelet

Probabilmente la notizia più grande di questa release vista la sua deprecazione nella versione 1.20. Il componente dockershim, che permetteva la comunicazione tra kubelet e docker, è stato definitivamente rimosso.

Per le successive versioni di Kubernetes, dalla 1.24 in poi, sarà necessario utilizzare un differente container runtime (come containerd o CRI-O), oppure utilizzare cri-dockerd se si stesse utilizzando ancora Docker Engine come container runtime.

Nonostante la presenza di un’alternativa come cri-dockerd, è chiaro che si voglia incentivare l’utilizzo di differenti container runtime rispetto a Docker, perciò è consigliato valutare una eventuale migrazione prima di eseguire l’aggiornamento alla versione 1.24.

Le API beta saranno spente di default

Le future API in stato “beta” non saranno più attive di default all’interno dei cluster, mentre le API beta esistenti rimarranno abilitate.

Per abilitare una API in alpha o beta sarà necessario utilizzare la funzionalità “feature gates”.

Aggiunta la firma per gli artefatti di release

Per rafforzare la sicurezza e evitare attacchi alla supply chain è stata introdotta una nuova funzionalità, attualmente in alpha, che permette agli utenti finali di verificare l’integrità delle risorse scaricate, come ad esempio i binari kubernetes.

Gli artefatti scaricabili dai repository di progetti Kubernetes saranno firmati con Cosign e verificabili con l’apposito binario.

Prevenzione dei duplicati nell’allocazione degli IP per i “Service”

Per esporre internamente al cluster le applicazioni che risiedono sui pod vengono utlizzati degli oggetti chiamati “Service”.

I “Service” hanno un IP virtuale che bilancia il traffico sui vari pod e la scelta dell’IP può avvenire in maniera dinamica, ovvero il cluster sceglierà un IP dal range configurato, oppure in maniera statica, in cui sarà l’utente stesso a definire quale IP utilizzare dal range configurato.

Nei casi in cui si utilizzi sia un approccio dinamico che statico vi è il rischio di avere un conflitto di IP, poichè non c’è modo di conoscere in anticipo se un indirizzo IP è stato assegnato a un servizio esistente.

Con Kubernetes 1.24 viene introdotta in alpha la possibilità di riservare una parte di IP del range configurato in maniera da essere utilizzati per l’allocazione statica senza timore di avere IP duplicati.

Le funzionalità “Storage Capacity tracking” e “Volume Expansion” sono GA

La versione 1.24 segna ufficialmente la disponibilità di API a livello cluster per il tracciamento dello spazio storage. Queste API possono essere utilizzate dai vari CSI driver (se supportate) per verificare se lo spazio disponibile sui volumi è sufficiente ad ospitare un pod, e nel caso in cui non lo fosse, il pod non viene neanche schedulato.

Un’altra novità riguardante lo storage è il rilascio ufficiale della funzionalità di resizing per un PVC in uso. Non sarà necessario cancellare e ricreare il pod o il deployment che sta utilizzando il PVC esistente, ma il PVC sarà automaticamente disponibile al suo pod una volta completato il resizing.

Da notare che questa funzionalità non funziona su PVC non in uso da pod o deployment.

“DynamicKubeletConfig” rimosso

Dopo la deprecazione nella versione 1.22 arriva la rimozione ufficiale dal kubelet di questa funzionalità, in beta dalla versione 1.11. Questa permetteva di cambiare la configurazione di ogni kubelet in un cluster kubernetes, creando un ConfigMap e configurando ogni nodo in modo da utilizzarlo.