Ma come? Non abbiamo appena detto che il progetto Docker è in buona salute e che è ben lungi dal dichiararsi defunto? E allora il changelog della versione 1.20 di Docker che recita:

Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called “dockershim” which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community. We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available.

Il supporto Docker in kubelet è ora deprecato e sarà rimosso in una futura release. Kubelet utilizza un modulo chiamato “dockershim” che implementa il supporto CRI per Docker e ha comportato problemi di manutenzione nella community di Kubernetes. Incoraggiamo gl utenti a valutare il passaggio a un runtime container che sia una vera e propria implementazione del CRI (v1alpha1 o v1 compliant) man mano che diventano disponibili.

Come va interpretato?

Abbiamo sbagliato tutto? Docker è davvero destinato ad una fine ingloriosa? In realtà le cose sono un poco diverse, e ci pensa l’annuncio congiunto degli sviluppatori di Kubernetes a chiarire la questione.

Imperativo categorico:

Niente panico.

Anzitutto, il problema della deprecazione. Questo viene da lontano: Docker usa la propria container runtime ossia il software che consente di gestire (avvio, stop e restart) i container. La gestione di questa runtime è stata a suo tempo integrata in Kubelet (il motore di Kubernetes) poiché, di fatto, non esistevano alternative. Già dalla versione 1.3 il supporto venne esteso ad una runtime alternativa, rkt, ben presto però gli sviluppatori si son ritrovati di fronte a un problema manutentivo: gestire l’integrazione di componenti tanto diversi (e integrati) diventa complicato.

Come si risolvono quindi questo genere di problemi? Creando uno standard, che nel caso di Kubernetes è rappresentato da CRI, la Container Runtime Interface(CRI). Questa, nelle intenzioni, consente di astrarre la runitme, utilizzando un’interfaccia a plugin, come spiega il diagramma (che arriva direttamente da kubernetes.io):

Il problema quindi è presto detto: la runtime Docker è incompatibile con quanto descritto sopra, viene gestita ancora direttamente da Kubelet e per questo quindi verrà deprecata poiché, logicamente, tutti gli sviluppi verranno dedicati a CRI.

Ma cosa cambia quindi nella pratica?

Per gli utilizzatori finali di Kubernetes cambierà poco, essendo questi per natura agnostici nei confronti della runtime utilizzata da Kubelet.

Se invece il dubbio è relativo a pipeline e sviluppi secondo la consueta modalità, quindi utilizzando il comando docker build e i Dockerfile, ci pensa il comunicato a far chiarezza:

This doesn’t mean the death of Docker, and it doesn’t mean you can’t, or shouldn’t, use Docker as a development tool anymore. Docker is still a useful tool for building containers, and the images that result from running docker build can still run in your Kubernetes cluster.

Questo non significa la morte di Docker, e non significa che non si possa o non si debba più usare Docker come strumento di sviluppo. Docker è ancora uno strumento utile per la costruzione di container, e le immagini che risultano dall’esecuzione di Docker possono ancora essere eseguite nel vostro cluster Kubernetes.

Quindi se proprio di morte dobbiamo parlare, è della morte del supporto alla runtime di Docker nativa all’interno di Kubelet.

Tutto chiaro? Speriamo di sì. Se sviluppate container con Docker non preoccupatevi, non dovrete cambiare nulla.