Kubernetes v1.19: cosa c’è di nuovo… direttamente dal KubeCon 2020

KubeCon 2020: l’Europa tiene a battesimo il primo evento virtuale per la CNCF

Dal 17 al 20 agosto è andato in scena il primo evento completamente virtuale (a causa dell’emergenza COVID-19) KubeCon e CloudNativeCon, sponsorizzato dalla CNCF, relativo alle novità del mondo Kubernetes e il panorama Cloud Native.

Proprio dai Keynote sono arrivate le novità più succulente.

Tra i molti argomenti degni di nota, ci teniamo a sottolineare i seguenti:

• Lo stato di avanzamento dei principali (e più recenti) progetti che stanno sotto il cappello della CNCF
• L’anticipazione delle nuove funzionalità della versione 19 di Kubernetes

CNCF Project Update, una breve panoramica

La prima novità è rappresentata dall’entrata ufficiale (aprile 2020) di Argo (https://argoproj.github.io/argo-cd/) all’interno del programma di incubazione della CNCF. Argo CD è leader nel settore del GitOps e questo rappresenta un chiaro segnale di quale sia la strada da seguire in ambito workflow e automazione di deployment in ambiente Cloud Native.

Nel mese di giugno, invece, è entrato a far parte dell’incubazione SPIFFE/SPIRE (https://spiffe.io/), rispettivamente Framework e Runtime Environment in ambito Identity, Security e Access Control per workload produttivi. Sicuramente progetti da tenere sott’occhio nel prossimo immediato futuro.

Scorrendo nella nostra timeline, il mese di luglio vede invece l’ingresso del progetto Contour (https://projectcontour.io/), il quale si va a posizionare nel già competitivo mercato degli Ingress Controller per cluster k8s. Così come tanti altri “cugini” anch’esso si appoggio al solido Envoy e punta tutto sulle performance e scalabilità.

Il prossimo progetto, sponsorizzato al Keynote, è TiKV (https://tikv.org/), Key Value transactional database, recentemente diventato un progetto graduated per la CNCF. Sicuramente degno di nota il boom avuto in comunità, con numeri di crescita impressionanti.

Finiamo la nostra breve panoramica con un progetto non certo nuovo, ma che ha trovato una dimensione quasi di standardizzazione per la sua categoria: Jaeger (https://www.jaegertracing.io/). Per i pochi che non l’avessero mai sentito nominare, Jaeger è diventato ormai lo standard de-facto per  end-to-end distributed tracing in ambito Cloud Native. Durante il Keynote è stato ricordato che quest’anno il progetto compie 5 anni, ma guai a giudicarlo vecchio! L’innovazione è sempre dietro l’angolo (come ad esempio l’integrazione nativa con Grafana 7…).

Kubernetes: le novità della versione v1.19

Ma veniamo al vero clou dei keynote KubeCon 2020: il rilascio di una promettente e nuova versione per Kubernetes, la versione 1.19.

Il rilascio di Kubernetes v1.19 porta numerose novità, all’insegna di una più semplice gestione e una maggiore affidabilità.

In questa nuova versione gli sviluppatori si sono focalizzati nel consolidamento della piattaforma e la semplificazione di alcune API. Il consolidamento appare evidente visto l’annuncio dell’allungamento del supporto, che passa da nove mesi a un anno.

L’API Lifecycle viene rivoluzionato con l’introduzione di meccanismi di inizializzazione delle nuove api in una pipeline di promozione o update (questo permette di evitare, per esempio, quanto visto con l’Ingress che è rimasto in beta sino la versione 1.1).

Parlando di semplificazioni, è stato introdotto il volume effimero generico, questa funzionalità riduce e semplifica la definizione dei volumi.

È stato anche aggiornato il sistema di patching, introdotto nella versione 1.16 con il compito di definire l’infrastruttura in ambienti (dev, test, prod). Gli sviluppatori hanno deciso di andare anche in questo caso a semplificare e consolidare la funzionalità preesistente. Lo strumento scelto a questo scopo è il Kubeadm il quale userà le Row patch in modo similare all’uso del Kubectl. Questo eviterà l’utilizzo di dipendenze esterne particolarmente onerose come il Kustomize.

Ma vediamo ora meglio le novità nel dettaglio.

Supporto Kubernetes Vanilla aumentato ad un anno!

Questa scelta è stata presa dal team per venire incontro a tutte quelle organizzazioni che vorrebbero effettuare un upgrade annuale di Kubernetes in modo consistente.

Questo perché in passato i rilasci delle versioni principali del software avvenivano con una cadenza di tre mesi in tre mesi. La situazione costringeva dunque a degli aggiornamenti serrati, i quali potevano essere rischiosi.

A seguito di alcuni sondaggi tenuti durante il 2019 è emerso che la maggior parte degli utenti della community avrebbe preferito gli upgrade di Kubernetes una volta ogni 12-14 mesi.

Parlando invece delle versioni di Kubernetes 1.17 e 1.18, saranno supportate con il modello precedentemente in vigore, ovvero il “supporto per le ultime tre versioni”.

Transizioni obbligatorie dalla Beta e meccanismi di Warning per le API Deprecate

In questa nuova versione il team ha deciso di introdurre una pipeline di integrazione delle nuove API, le quali hanno lo scopo di evitare quanto visto con l’API di Ingress (la quale, vi ricordiamo, è rimasta ben 5 anni in un Beta prima di essere stata stabilizzata nella v.1.18).

Per impedire il ripetersi di questo “limbo”, è stata decisa una strategia che si basa su 2 step:

• Verificare il raggiungimento delle GA e conseguente Deprecate della versione Beta
• Introduzione di una nuova versione dell’API in beta.

In tutti i casi comunque una API Beta potrà rimanere tale solo per nove mesi, passati i quali sarà promossa o deprecata.

Parlando di deprecation è stato introdotto inoltre un meccanismo di Warning il quale aiuterà gli utenti e gli amministratori del cluster Kubernetes a identificare l’uso di eventuali API deprecate tramite un messaggio.

Volume Generico Effimero

Se un Volume viene assegnato ad un Pod e questo viene cancellato, il volume connesso viene cancellato a sua volta. Questo meccanismo descrive il funzionamento di un Volume effimero.

In Kubernetes esistono molteplici tipologie di volumi effimeri, tra i quali troviamo EmptyDir, ConfigMap e Secrets. Inoltre, sarebbe possibile utilizzare i volumi effimeri CSI (Container Storage Interface) ma per usufruire di questa funzionalità è necessario aggiornare il CSI Driver.

In questa nuova release di Kubernetes viene introdotta una nuova tipologia di volume effimero, il quale viene definito Generico. Questa API per ora è in Alpha e di conseguenza deve essere abilitata manualmente.

Funziona similarmente ad una EmptyDir ma in modo più flessibile, infatti:

• Può essere utilizzata sia come Storage locale che Storage di rete.
• I volumi possono avere delle quote, le quali i Pod non possono superare.
• I volumi potrebbero contenere dei dati iniziali, a seconda del driver che si va ad utilizzare
• Le funzionalità di Snapshot, Clone, Resize e Traking dello storage possono variare a seconda del driver in uso.

Inoltre, questa funzionalità mette a disposizione una API che può funzionare con tutti gli stogare driver che supportano il Dynamic Provisioning.

Ecco qui di seguito un esempio di definizione:

Kubeadm: configurazioni e modifiche con Patch

Con la versione 1.16 venne introdotto il Kustomize, uno strumento che viene utilizzato per eseguire delle configurazioni personalizzate per deploy della soluzione. Per esempio, è possibile avere una configurazione base che vale per tutti gli ambienti e poi avere un meccanismo di sovrascrittura specifico per ogni ambiente.

Il team di sviluppo di Kubeadm ha deciso di virare verso un nuovo metodo, più semplice e meno complesso, rimuovendo le dipendenze del Kustomize, implementando una logica di Raw Patching in una modalità similare a quella del Kubectl (precisiamo però ancora che questa funzionalità è in Alpha e per essere utilizzata deve essere usato il nuovo flag –experimental-patches , che a tendere diventerà –patches).

Ecco di seguito un esempio del nuovo comando: