Kubernetes abbandona Docker: ecco perchè non deve spaventare

Dopo il rilascio della v1.20, Kubernetes sta pubblicamente abbandonando Docker come container runtime. A Docker come ambiente di runtime sono preferibili runtime che utilizzano la Container Runtime Interface (CRI) creata appositamente per Kubernetes.
Kubernetes abbandona Docker

Ma niente panico! Non è così drammatico come potrebbe sembrare.
Infatti le immagini prodotte da Docker continueranno a funzionare nel tuo cluster come hanno sempre fatto.

Per gli utenti finali di Kubernetes questa indicazione non porterà sostanziali cambiamenti.

Allo stesso modo, questo non significa la fine di Docker e nemmeno che questo strumento di sviluppo non debba più venire utilizzato.

Docker rimane uno strumento utile per la creazione di container e le immagini risultanti dall’esecuzione della Docker build possono ancora essere eseguite nel cluster Kubernetes.

Se stai utilizzando un servizio Kubernetes gestito come GKE, EKS o AKS (che per impostazione predefinita è containerd), assicurati solamente che i worker node stiano utilizzando un container runtime supportato e assicurati di farlo prima che Docker venga rimosso in un prossimo aggiornamento di Kubernetes.
Se, invece, i tuoi worker node hanno impostazioni personalizzate potrebbe essere necessario un aggiornamento. In questo caso ti consigliamo di metterti in contatto con il fornitore dei tuoi servizi in modo che i cambiamenti vengano effettuati in modo corretto.

Per pianificare gli aggiornamenti necessari in modo che rispettino i requisiti di runtime del tuo ambiente personalizzato puoi metterti in contatto con noi: utilizziamo la metodologia DevOps e lavoriamo da anni nello sviluppo a container.

Se invece hai installato in autonomia i tuoi cluster, ricordati di apportare le modifiche necessarie per evitare che questi si rompano.

Con l’arrivo della v1.20, riceverai un avviso specifico riguardante l’utilizzo di Docker perchè nella versione di Kubernetes successiva (il passaggio alla v1.22 è pianificato per la fine del 2021) il supporto runtime di Docker verrà rimosso e non sarà più supportato.

Diventerà, quindi, necessario passare a uno degli altri container runtime conformi con i requisiti del sistema, come Containerd o CRI-O . Assicurati solo che il runtime che sceglierai supporti le configurazioni del Docker che usi attualmente (es. login).

Kubernetes abbandona Docker: perché c’è confusione e cos’è che sta facendo impazzire tutti?

Quello che sta creando confusione è il fatto che stiamo parlando di due ambienti diversi. All’interno del cluster Kubernetes, c’è un componente chiamato container runtime che è responsabile dell’estrazione e dell’esecuzione delle immagini del container.

Sebbene Docker sia una soluzione popolare per svolgere quel tipo di operazione, allo stesso tempo non è nata e non è stata progettata per essere incorporata in Kubernetes.

Qui sta l’origine del problema.

Ciò che chiamiamo “Dockernon è in realtà un unico tool ma un intero stack tecnologico e, solo una parte di esso, è ciò che chiamiamo “containerd”, che è, di per sé, un container runtime di alto livello. Docker è uno strumento popolare e utile perché pone grande attenzione alla UX che rende molto facile l’interazione con lo strumento durante il lavoro di sviluppo. Tuttavia, questi miglioramenti della UX non sono necessari per Kubernetes, poiché non si tratta di un essere umano.

Proprio per via dell’esistenza di questo layer, pensato per l’interazione umana di Docker, il cluster Kubernetes deve utilizzare un ulteriore strumento, chiamato Dockershim, per gestire ciò di cui ha veramente bisogno, cioè ciò che è containerizzato. L’utilizzo di questo strumento aggiuntivo non è ideale perché aggiunge alla struttura un altro tool che necessita di manutenzione e che può rompersi.

Ciò che sta accadendo è che nella v1.23 di Kubernetes Dockershim verrà rimosso, cioè significa che il supporto che permette di utilizzare correttamente Docker come container runtime non esisterà più.

In questo momento potresti stare pensando, tra te e te, “ma se containerd è incluso nello stack Docker, perché Kubernetes ha bisogno di Dockershim?”

Docker non rispetta i requisiti CRI, la Container Runtime Interface. Se li rispettasse, non ci sarebbe bisogno di un layer aggiuntivo e il problema non si porrebbe. In ogni caso, questo aggiornamento non sarà la fine del mondo: basterà solo cambiare il container runtime passando da Docker ad un altro container runtime supportato.

NB: se ti affidi al socket docker (/var/run/docker.sock) come parte di un flusso di lavoro all’interno del tuo cluster, il passaggio ad un runtime diverso non ti permetterà più di usarlo. Questo modello è spesso chiamato Docker in Docker. Ma non ti preoccupare, ci sono molte opzioni per questo caso specifico, tra cui kaniko, img e buildah.

Ma cosa significa questo cambio per gli sviluppatori?

Si possono scrivere ancora Dockerfiles? Ha senso sviluppare con Docker?

Questa modifica riguarda un ambiente diverso da quello utilizzato dalla maggior parte delle persone per interagire con Docker.

L’installazione Docker utilizzata in fase di sviluppo non è correlata al runtime Docker all’interno del cluster Kubernetes.

Questo può generare confusione, ma Docker rimarrà utile negli stessi modi in cui lo era prima che questa modifica venisse annunciata.
L’immagine prodotta da Docker non è realmente un’immagine specifica di Docker: è un’immagine OCI (Open Container Initiative). Qualsiasi immagine conforme a OCI, indipendentemente dallo strumento utilizzato per crearla, avrà lo stesso aspetto per Kubernetes. Sia Containerd che CRI-O sanno come estrarre quelle immagini ed eseguirle. Questa la ragione per cui esiste uno standard sull’aspetto dei container.

In conclusione Kubernetes abbandona Docker ma il cambiamento che si profila all’orizzonte non deve preoccupare. La strada di Kubernetes con un runtime diverso da Docker è già stata percorsa da altri senza impatti negativi.

Il passaggio potrebbe causare dei problemi a seconda di come interagisci con Kubernetes: fai una valutazione, chiediti cosa significa questo cambiamento per te e se c’è del lavoro da fare i nostri tecnici sono pronti a darti il supporto necessario!

Se hai ancora dei dubbi a riguardo, è normale: Kubernetes è sempre in movimento. Speriamo di aver aiutato a chiarire alcuni dubbi ma se hai ancora delle domande, contattaci!

Fonte: puoi trovare l’articolo originale qui