CRI-O: cos’è?

CRI-O è un’implementazione della Container Runtime Interface (CRI) per Kubernetes, che utilizza immagini e ambienti di runtime della “Open Container Initiative” (OCI). Il progetto è stato avviato nel 2016 dalla società “Red Hat” e consegnato alla “Cloud Native Computing Foundation” (CNCF) nella primavera del 2019.

Per capire come funziona CRI-O e come interagisce con le tecnologie correlate, è utile dare un’occhiata allo sviluppo storico della virtualizzazione basata su contenitori. La base per la sua nascita è stato il software Docker, che ha reso popolare la virtualizzazione di singole app basata su contenitori leggeri. Prima, la virtualizzazione si basava principalmente sull’uso di macchine virtuali. Una macchina virtuale contiene un sistema operativo completo, mentre i contenitori multipli accedono a un kernel di sistema operativo condiviso.

Un contenitore di solito contiene una singola app, che spesso fornisce un microservizio. Nell’uso pratico, per realizzare un’applicazione completa è necessario controllare simultaneamente un gran numero di contenitori. La gestione coordinata di interi gruppi di contenitori è conosciuta come orchestrazione.

L’orchestrazione è realizzabile anche tramite Docker e strumenti come Docker Swarm, tuttavia ora si è affermato l’uso di Kubernetes come alternativa a Docker. Kubernetes raggruppa diversi contenitori in quello che viene chiamato pod. I pod a loro volta girano su macchine chiamate nodi, che possono essere fisiche o virtuali.

Uno dei problemi principali di Docker era la sua architettura monolitica. Il demone di Docker girava con i privilegi di root ed era responsabile di una varietà di compiti diversi: dal download delle immagini dei contenitori, alla loro esecuzione nell’ambiente di runtime, alla creazione di nuove immagini. Questa fusione di aree in realtà indipendenti viola il principio di sviluppo software della “separation of concerns” (separazione degli interessi), oltre a poter comportare problemi di sicurezza. Per questo motivo si è ritenuto importante disaccoppiare i singoli componenti.

Inizialmente il demone di Kubernetes kubelet includeva un runtime Docker hardcoded. Tuttavia, la necessità di supportare altri runtime divenne presto evidente. La modularizzazione di ogni aspetto ha infatti permesso di semplificarne gli ulteriori sviluppi e di aumentare la sicurezza. Per rendere diversi runtime compatibili con Kubernetes, è stata definita un’interfaccia: la Container Runtime Interface (CRI). CRI-O è un’implementazione specifica di questa interfaccia.

La procedura di base per l’utilizzo di CRI-O consiste nei seguenti passaggi:

1. Download di un’immagine del contenitore OCI
2. Decompressione dell’immagine in un bundle del file system del runtime OCI
3. Esecuzione del contenitore attraverso un runtime OCI

CRI-O è attualmente utilizzato principalmente come parte della linea di prodotti OpenShift di Red Hat. Esistono implementazioni di OpenShift per le piattaforme cloud di tutti i principali provider. Inoltre, il software può essere eseguito come parte della OpenShift Container Platform in data center pubblici o privati. Di seguito una panoramica dei vari prodotti OpenShift:

CRI-O è uno strumento relativamente nuovo nel campo della virtualizzazione dei contenitori e l’offerta per runtime alternativi per i contenitori è sempre stata piuttosto ampia. Il punto forte di CRI-O è il suo focus sull’ambiente Kubernetes. Con CRI-O, infatti, Kubernetes può eseguire direttamente i contenitori senza strumenti aggiuntivi né personalizzazioni speciali del codice. CRI-O stesso supporta i runtime esistenti e compatibili con OCI. Di seguito una panoramica dei runtime più utilizzati: