Kubernetes v1.20: le principali novità e l’abbandono di Docker

22/12/2020

Kubernetes v1.20 è la terza ed ultima release di quest’anno. In questa release sono presenti 42 miglioramenti. 11 dei quali sono stati rilasciati in stabile, mentre 15 sono entrati nella fase beta e 16 sono in Alpha.

Questa release è estremamente densa di nuove funzionalità, anche grazie alle modifiche introdotte nella versione precedente di Kubernetes v1.19. Proprio tra le nuove funzionalità nella versione precedente, infatti, veniva introdotto un nuovo meccanismo di release.

Temi principali

Di seguito sono riportate tutte le funzionalità principali, più una extra che merita un capitolo a sé stante:

  • Le operazioni di Snapshot dei volumi arrivano in stabile.
  • kubectl debug entra in beta.
  • L’API Priority entra in beta.
  • IPv4/IPv6 dual-stack viene introdotto in Alpha.
  • Miglioramento della stabilità e gestione dei PID.
  • Introdotta una funzionalità di graceful shutdown dei nodi in Alpha.
  • I CronJobs entrano in beta.
  • Il supporto a kubelet CRI entra in beta.
  • Più metriche dal kube-scheduler in Alpha
  • Kubernetes depreca Docker come CRI

Ma vediamo ora meglio le novità nel dettaglio.

Le operazioni di Snapshot dei volumi arrivano in stabile

Questa nuova funzionalità permette di utilizzare una metodologia standard per innescare la procedura di Snapshot dei volumi, così che questa possa essere utilizzata per ogni tipo di ambiente e in modo indipendente dal fornitore dello storage. Inoltre, queste primitive di snapshot Kubernetes agiscono come “fondamenta” per lo sviluppo di procedure più complesse e avanzate. Ciò deve essere visto come un passo in avanti per venire in contro alle esigenze di livello Enterprise. È possibile dunque andare a studiare delle soluzioni che permettono di eseguire backup a livello di cluster in modo più semplice e standard.

Kubectl debug entra in beta

La funzionalità kubectl alpha debug passa in beta diventando kubectl debug. Questa funzionalità fornisce supporto per il debug direttamente da kubectl.

Tra gli scenari di troubleshooting supportati troviamo:

  • workloads che si arrestano in modo anomalo all’avvio: viene creata una copia del Pod, utilizzando un’immagine o un comando differente nel container
  • distroless container: viene inserito uno strato di tools di debug all’interno di una replica del Pod stesso oppure di un container effimero
  • nodo Kubernetes: viene creato un container istanziato all’interno del namespace dell’host, con accesso diretto al filesystem dell’host

L’API Priority entra in beta

Questa funzionalità è stata introdotta in Kubernetes v1.18 ed ora in kubernetes v1.20 abilita di default l’API Priority and Fairness (APF). Questa essenzialmente permette al kube-apiserver di categorizzare le richieste in arrivo tramite un meccanismo di priorità.

IPv4/IPv6 dual-stack viene introdotto in alpha

L’IPv4/IPv6 dual-stack è stato re-implementato per supportare meglio i servizi dual-stack, grazie al feedback ricevuto dagli utenti e dalla community Kubernetes. Questa funzionalità permette di assegnare sia IPv4 che IPv6 per i clusterIP in un singolo servizio. Inoltre, consente di eseguire la transizione di un servizio da uno stack IP singolo a uno doppio e viceversa.

Miglioramento della stabilità e gestione dei PID

I Process ID o PID sono una risorsa fondamentale per la definizione dei processi per un host Linux. È fondamentale quindi non raggiungere mai il limite di PID assegnabili, o quantomeno senza prima raggiungere altri limiti di risorse hardware, poiché questo può causare instabilità.

Gli amministratori Kubernetes necessitano dunque di un meccanismo per garantire che i Pod non possano mai esaurire i PID, impendendo l’esecuzione dei demoni da parte dell’host (es. Runtime, Kubelet, ecc.). Inoltre, è importante assicurarsi che i PID siano limitati tra i Pod al fine di garantire che abbiano un impatto limitato su altri carichi di lavoro sul nodo.

Il SIG Node ha quandi promosso in GA:

  • SupportNodePidsLimit che permette di isolare i PID da nodo a Pod
  • SupportPodPidsLimit che permette di limitare il numero di PID per Pod.

Introdotta una funzionalità di graceful shutdown dei nodi in Alpha

Gli utenti e gli amministratori dei cluster Kubernetes si aspettano che i Pod abbiano un certo ciclo di vita, inclusa la parte finale dove avviene la cancellazione del Pod stesso. Attualmente, quando un nodo viene spento, i Pod al suo interno non seguono il ciclo di vita di terminazione dei Pod normale e non vengono terminati correttamente tramite le procedure usuali, ma in modo brusco. Di conseguenza questo avviene come se fossero stati terminati forzatamente, il che può causare delle problematiche non appena i Pod vengono rigenerati.

Il GracefulNodeShutdown, in alpha, è la funzionalità che rende il kubelet cosciente del fatto che un nodo del cluster ha ricevuto la direttiva di spegnimento. Quindi, inizializza la procedura di corretta terminazione dei singoli Pod durante lo spegnimento del sistema.

I CronJobs entrano in beta

I CronJobs, chiamati precedentemente ScheduledJobs, vengono utilizzati come task periodici che si eseguono su un cluster Kubernetes. I CronJobs sono strutturati similarmente a dei Cron Linux. In questa nuova versione sono state gestite e risolte le maggiori problematiche e si è portato il focus sulla scalabilità. È possibile utilizzare questa nuova versione attraverso il setting di CronJobControllerV2 a True.

Il supporto a kubelet CRI entra in beta

Il Container Runtime Interface, o CRI, è un plug-in di interfaccia che consente al kubelet di usare un’ampia tipologia di Container Runtime senza aver la necessità di dover ricompilare le immagini, quindi creando un vero e proprio standard di compilazione dei container. Tra i Container Runtime, oltre a Docker, troviamo per esempio CRI-O o Containerd.

Questa API, dopo essere stata introdotta in Alpha, non è stata più modificata ed è rimasta in questo limbo per molto tempo, tanto che è stata largamente testata anche in ambienti produttivi. Questo passaggio alla Beta, dunque, è un cambio epocale.

Più metriche kube-scheduler in Alpha

In questa nuova versione il kube-scheduler ora espone più metriche sulle risorse richieste e sui limiti desiderati di tutti i Pod in esecuzione. Ciò permetterà a tutti gli amministratori e al team del monitoraggio una più facile e completa gestione del cluster e una pianificazione dei carichi più oculata.

Queste metriche sono esposte all’endpoint http /metrics/resources, quando viene indicata l’opzione --show-hidden-metrics-for-version=1.20

Kubernetes depreca Docker

Kubernetes depreca Docker come Container Runtime dopo il rilascio della versione v1.20. Questa notizia può sembrare allarmante, ma non è così in realtà. Questo perché Docker possiede un Runtime Container Engine che usa delle Container Runtime Interface o CRI certificate per l’uso attraverso Kubernetes. Significa quindi che tutte le immagini che sono state prodotte attraverso Docker continueranno a funzionare come hanno sempre fatto.

Quindi, di fatto, per tutti gli utenti che usano Kubernetes non cambierà praticamente niente a livello di utilizzo. Inoltre, questo non significa neppure la morte di Docker in sé, né che non si può o dovrebbe più usare come strumento di sviluppo. Docker è, e rimane, uno strumento di sviluppo utilissimo e soprattutto omnicomprensivo, che permette di creare container e immagini con un semplice docker build, e questo sicuramente continuerà a funzionare anche su Kubernetes.

Il vero motivo per il quale si sta andando a deprecare Docker è il fatto che Docker stesso è piuttosto uno stack di tools e non solo una CRI. Inoltre, Docker è stato concepito per poter essere utilizzato da utenti finali. Questa caratteristica ha dei pro e dei contro: da un lato è ottimo per essere utilizzato dagli utenti (ad esempio sviluppatori), mentre dall’altro non è ottimale per essere utilizzato con Kubernetes (per fare ciò, infatti, è stato necessario scrivere un vero e proprio connettore chiamato dockershim). Il connettore dockershim ha infatti il compito specifico di collegare Kubernetes a Docker e farlo quindi parlare con la vera e propria CRI utilizzata da Docker, ovvero Containerd.

Nota

Se si sta utilizzando una versione on-premise di Kubernetes sarà necessario effettuare delle modifiche per assicurarsi che il Cluster continui a funzionare. Attualmente con Kubernetes v1.20 verrà innalzato un Deprecation Warning per Docker.    Mentre per le versioni future sarà rimosso definitivamente il supporto (attualmente pianificato per la versione 1.22, prevista per la seconda metà del 2021). Dunque, sarà necessario, nel futuro prossimo, migrare verso un diverso Container Runtime come Containerd o CRI-O.

È necessario quindi solo assicurarsi che il Runtime che si sceglie supporti le configurazioni del demone Docker che si sta usando attualmente.