I container significano ancora "Docker" per molte persone. Docker ha reso popolare l'uso moderno dei container nello sviluppo e nella distribuzione di software. In questi giorni esistono anche altre tecnologie. Ecco come si relazionano tra loro Containerd, Docker e Kubernetes.
Gli inizi
Al suo rilascio nel 2013, Docker era un progetto autonomo con tutto il necessario per creare ed eseguire container. Quello che mancava era un modo semplice per orchestrare le distribuzioni di container nel cloud.
Alla fine del 2013, un gruppo di googler stava già affrontando questo problema con un prototipo di quello che sarebbe diventato Kubernetes. Kubernetes ha lo scopo di semplificare il funzionamento di carichi di lavoro containerizzati su grandi flotte di macchine.
In quei primi giorni, Kubernetes era indissolubilmente legato a Docker. Utilizzava Docker direttamente per interagire con i container, anche se necessitava solo di un sottoinsieme di funzionalità, le parti responsabili dell'esecuzione effettiva dei container.
L'interfaccia utente incentrata sullo sviluppatore di Docker ha intralciato Kubernetes. Ha dovuto aggirare gli aspetti umani del progetto utilizzando uno strumento dedicato, Dockershim. I problemi sono stati aggravati dalle diverse direzioni in cui erano diretti Docker e Kubernetes. Docker ha lanciato Swarm, la sua alternativa a Kubernetes, che offre l'orchestrazione come una "modalità" Docker integrata.
L'ascesa di Containerd
Con la crescita di Kubernetes e la nascita di più strumenti di terze parti attorno a Docker, i limiti della sua architettura sono diventati chiari. Allo stesso tempo, l'Open Container Initiative (OCI) ha iniziato a standardizzare i formati e i tempi di esecuzione dei container. Ciò ha portato a una specifica OCI che definisce un contenitore che potrebbe essere utilizzato da più runtime, di cui Docker è un esempio.
Docker ha quindi estratto il runtime del contenitore in un nuovo progetto, containerd. Ciò include la funzionalità di Docker per l'esecuzione di container, la gestione dell'archiviazione di basso livello e la gestione dei trasferimenti di immagini. Containerd è stato donato alla Cloud Native Computing Foundation (CNCF) per fornire alla comunità di container una base per la creazione di nuove soluzioni di container.
L'emergere di containerd rende più facile per progetti come Kubernetes accedere agli elementi "Docker" di basso livello di cui hanno bisogno. Invece di utilizzare effettivamente Docker, ora hanno un'interfaccia più accessibile per il runtime del contenitore. La standardizzazione OCI delle tecnologie dei container consente di utilizzare anche altri runtime.
Capire il ruolo di Containerd
Per comprendere appieno containerd, è necessario guardare alla natura dei container. I container sono davvero un'astrazione su varie funzionalità del kernel Linux. Per eseguire un container, è necessario utilizzare syscalls per configurare l'ambiente containerizzato. I passaggi variano in base alla piattaforma e alla distribuzione.
Containerd entra per astrarre questo cablaggio di basso livello. È inteso come un "livello client" su cui si basa il software contenitore. Potrebbe trattarsi di software orientato agli sviluppatori, come Docker, o strumenti devops orientati al cloud come Kubernetes.
In precedenza, lo sviluppo di Kubernetes era lasciato con due pessime opzioni:continuare a scrivere shims attorno alla pesante interfaccia Docker o iniziare a interagire direttamente con le funzionalità del kernel Linux. Rompendo containerd da Docker, è diventata disponibile una terza alternativa:utilizzare containerd come livello di astrazione del sistema, senza coinvolgere Docker.
Ecco un riepilogo di come si combinano le tre tecnologie:
- Docker – Un software orientato agli sviluppatori con un'interfaccia di alto livello che ti consente di creare ed eseguire facilmente container dal tuo terminale. Ora utilizza containerd come runtime del container.
- Contenitore – Un'astrazione delle funzionalità del kernel che fornisce un'interfaccia contenitore di livello relativamente alto. Altri progetti software possono utilizzarlo per eseguire container e gestire le immagini dei container.
- Kubernetes – Un agente di orchestrazione del contenitore che funziona con più runtime del contenitore, incluso containerd. Kubernetes si concentra sulla distribuzione di container in forma aggregata su uno o più "nodi" fisici. Storicamente, Kubernetes era legato a Docker.
Containerd è solo un back-end di container. Altri contenitori che implementano la specifica Open Containers Runtime includono runC e CRI-O. Questi runtime possono essere utilizzati anche con Docker e Kubernetes; ognuno ha le sue distinzioni.
L'OCI
L'OCI è l'organismo responsabile della definizione degli standard dei container. Il suo lavoro è stato determinante nel facilitare l'interoperabilità tra le diverse tecnologie dei componenti.
La specifica dell'immagine dell'OCI definisce come dovrebbe essere un contenitore. La specifica di runtime definisce un'interfaccia per l'esecuzione di container. Progetti come containerd implementano quindi queste specifiche.
È importante sottolineare che una delle priorità dell'OCI è supportare l'esperienza di utilizzo dei container resa popolare da Docker. Le sue immagini devono essere eseguibili sulla piattaforma di destinazione senza argomenti definiti dall'utente (ad es. docker run hello-world:latest ). Le immagini OCI devono quindi contenere metadati sufficienti per abilitare questa configurazione automatica.
Potresti anche vedere riferimenti a Container Runtime Interface (CRI). Questa è un'astrazione specifica di Kubernetes sulla specifica OCI. Il CRI si basa sulle specifiche OCI per abilitare il supporto per runtime di container intercambiabili all'interno di Kubernetes.
E le mie immagini Docker?
Le immagini che crei con Docker non sono affatto "immagini Docker". Poiché Docker ora utilizza il runtime containerd, le tue immagini vengono create nel formato standardizzato Open Container Initiative (OCI).
Non dovresti preoccuparti delle incompatibilità tra le tue immagini Docker e l'ambiente in cui vengono utilizzate. Le immagini che crei con Docker possono ancora essere distribuite utilizzando Kubernetes. Questo perché Kubernetes supporta anche le immagini OCI, attraverso l'uso di containerd (e altri runtime conformi agli standard). Dipende dal runtime per gestire l'estrazione e l'esecuzione delle immagini, non l'interfaccia di alto livello fornita da strumenti come Docker e Kubernetes.
Kubernetes e Docker
Kubernetes ha ritirato il runtime Docker alla fine del 2020. Verrà rimosso in una versione futura, attualmente prevista per la fine del 2021. Successivamente, Kubernetes non offrirà più Docker runtime sostegno. Sarà invece necessario utilizzare un runtime alternativo compatibile con le specifiche OCI, come containerd.
Questo annuncio ha suscitato preoccupazione per le implicazioni per gli sviluppatori. La modifica non dovrebbe influire sulla maggior parte dei flussi di lavoro esistenti. Come abbiamo già visto, Docker produce immagini conformi a OCI che possono essere eseguite da runtime conformi a OCI. Qualsiasi immagine che crei con docker build funzionerà ancora all'interno di Kubernetes, anche dopo la rimozione del runtime Docker.
Sono allo studio due diverse tecnologie:l'interfaccia a riga di comando Docker utilizzato per creare ed eseguire container e Docker runtime intorno a cui avvolge l'interfaccia della riga di comando.
È tutto troppo confuso!
In pochi anni, i container hanno trasformato il lavoro di molti sviluppatori. L'espansione nell'ecosistema circostante è stata un sottoprodotto naturale di questo cambiamento. I Containers === Docker mentalità si è rivelata troppo soffocante poiché ha impedito a strumenti come Kubernetes di mostrare il loro pieno potenziale.
Il passaggio alla standardizzazione ha portato a una pletora di nuovi termini, strumenti e tecnologie. Tuttavia, non è cambiato nulla per gli sviluppatori, sia che tu stia interagendo con la Docker CLI sulla tua macchina o con un cluster Kubernetes nel cloud.
Ogni interfaccia utente di alto livello (come Docker e Kubernetes) ora beneficia di una scelta di runtime di container di basso livello intercambiabili (come containerd e runC). Ciò consente un maggiore grado di flessibilità e consente alle nuove tecnologie basate su container di affermarsi in modo allineato agli standard.