Separare il runtime dal client
Docker ha vinto la prima fase del movimento container (2013-2016), ma il suo design monolitico (CLI + daemon + image management + runtime + networking) genera attrito quando Kubernetes cresce come orchestratore. I componenti low-level che fanno davvero girare i container possono essere estratti e standardizzati.
Nel marzo 2017 Docker dona containerd al CNCF come progetto Incubating (Graduated 2019). containerd è il runtime core di Docker: gestisce ciclo di vita del container (create, start, stop, exec, snapshot del filesystem), pull di immagini OCI, ma senza la CLI Docker né le feature high-level.
In parallelo Red Hat e un consorzio (Intel, SUSE, Hyper) sviluppano CRI-O come runtime Kubernetes-specific: implementazione pulita del Container Runtime Interface (CRI) di K8s, senza ambizioni più ampie. Prima release 1.0.0 nell’ottobre 2017.
Container Runtime Interface (CRI)
Kubernetes 1.5 (2016) ha introdotto CRI: API gRPC standard tra kubelet e container runtime. Abilita il pluggable runtime model:
- kubelet parla CRI
- Il runtime (containerd, CRI-O, docker-shim ponte verso Docker) implementa CRI
- K8s non vincolato a Docker
containerd — da Docker a standalone
containerd 1.0 (dicembre 2017) è un binario Go con:
- API gRPC con CRI plugin built-in
- Pull/push di immagini OCI
- Snapshot plugins (overlayfs, btrfs, zfs, native)
- ctr CLI minimale per debug
- Plugin architecture per estensioni
containerd diventa il runtime di default in molte distribuzioni Kubernetes managed (GKE, AKS, EKS, OpenShift 4.x) progressivamente fino al 2020-2022.
CRI-O — progettato per K8s
CRI-O è più piccolo di containerd, pensato per fare solo quello che K8s chiede via CRI:
- Image pull/unpack
- Pod sandbox management
- Container lifecycle
- Streaming server per
kubectl exec/attach/logs
È il runtime di default di OpenShift 4 e Fedora CoreOS. Licenza Apache 2.0.
La “dockershim deprecation”
Nel dicembre 2020 Kubernetes annuncia la rimozione di dockershim (il ponte che permetteva di usare Docker come runtime) in K8s 1.24 (aprile 2022). Il messaggio: Kubernetes 1.24+ non usa più Docker direttamente. Deve usare containerd, CRI-O, o un’altra implementazione CRI. L’impatto pratico per utenti finali è minimo (docker build continua a funzionare, le immagini OCI sono identiche) ma simbolicamente segna la fine dell’era “docker in K8s”.
Nel contesto italiano
Adoption seguì le distribuzioni K8s managed: per chi usa GKE, AKS, EKS, OpenShift — il cambio è stato silenzioso. Per deploy K8s su self-hosted, il passaggio da Docker a containerd o CRI-O è stato pianificato nel 2021-2022.
Riferimenti: containerd donato a CNCF (marzo 2017), Graduated (2019). CRI-O 1.0 (ottobre 2017), Red Hat-led. Kubernetes CRI (1.5, 2016). Dockershim deprecation (annuncio dicembre 2020, rimozione K8s 1.24 aprile 2022). OpenShift 4 usa CRI-O.