CRI-O: cos’è?

CRI-O è un’im­ple­men­ta­zio­ne della Container Runtime Interface (CRI) per Ku­ber­ne­tes, che utilizza immagini e ambienti di runtime della “Open Container Ini­tia­ti­ve” (OCI). Il progetto è stato avviato nel 2016 dalla società “Red Hat” e con­se­gna­to alla “Cloud Native Computing Foun­da­tion” (CNCF) nella primavera del 2019.

Per capire come funziona CRI-O e come in­te­ra­gi­sce con le tec­no­lo­gie correlate, è utile dare un’occhiata allo sviluppo storico della vir­tua­liz­za­zio­ne basata su con­te­ni­to­ri. La base per la sua nascita è stato il software Docker, che ha reso popolare la vir­tua­liz­za­zio­ne di singole app basata su con­te­ni­to­ri leggeri. Prima, la vir­tua­liz­za­zio­ne si basava prin­ci­pal­men­te sull’uso di macchine virtuali. Una macchina virtuale contiene un sistema operativo completo, mentre i con­te­ni­to­ri multipli accedono a un kernel di sistema operativo condiviso.

Un con­te­ni­to­re di solito contiene una singola app, che spesso fornisce un mi­cro­ser­vi­zio. Nell’uso pratico, per rea­liz­za­re un’ap­pli­ca­zio­ne completa è ne­ces­sa­rio con­trol­la­re si­mul­ta­nea­men­te un gran numero di con­te­ni­to­ri. La gestione coor­di­na­ta di interi gruppi di con­te­ni­to­ri è co­no­sciu­ta come or­che­stra­zio­ne.

L’or­che­stra­zio­ne è rea­liz­za­bi­le anche tramite Docker e strumenti come Docker Swarm, tuttavia ora si è affermato l’uso di Ku­ber­ne­tes come al­ter­na­ti­va a Docker. Ku­ber­ne­tes raggruppa diversi con­te­ni­to­ri 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 prin­ci­pa­li di Docker era la sua ar­chi­tet­tu­ra mo­no­li­ti­ca. Il demone di Docker girava con i privilegi di root ed era re­spon­sa­bi­le di una varietà di compiti diversi: dal download delle immagini dei con­te­ni­to­ri, alla loro ese­cu­zio­ne nell’ambiente di runtime, alla creazione di nuove immagini. Questa fusione di aree in realtà in­di­pen­den­ti viola il principio di sviluppo software della “se­pa­ra­tion of concerns” (se­pa­ra­zio­ne degli interessi), oltre a poter com­por­ta­re problemi di sicurezza. Per questo motivo si è ritenuto im­por­tan­te di­sac­cop­pia­re i singoli com­po­nen­ti.

Ini­zial­men­te il demone di Ku­ber­ne­tes kubelet includeva un runtime Docker hardcoded. Tuttavia, la necessità di sup­por­ta­re altri runtime divenne presto evidente. La mo­du­la­riz­za­zio­ne di ogni aspetto ha infatti permesso di sem­pli­fi­car­ne gli ulteriori sviluppi e di aumentare la sicurezza. Per rendere diversi runtime com­pa­ti­bi­li con Ku­ber­ne­tes, è stata definita un’in­ter­fac­cia: la Container Runtime Interface (CRI). CRI-O è un’im­ple­men­ta­zio­ne specifica di questa in­ter­fac­cia.

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

1. Download di un’immagine del con­te­ni­to­re OCI
2. De­com­pres­sio­ne dell’immagine in un bundle del file system del runtime OCI
3. Ese­cu­zio­ne del con­te­ni­to­re at­tra­ver­so un runtime OCI

CRI-O è at­tual­men­te uti­liz­za­to prin­ci­pal­men­te come parte della linea di prodotti OpenShift di Red Hat. Esistono im­ple­men­ta­zio­ni di OpenShift per le piat­ta­for­me cloud di tutti i prin­ci­pa­li provider. Inoltre, il software può essere eseguito come parte della OpenShift Container Platform in data center pubblici o privati. Di seguito una pa­no­ra­mi­ca dei vari prodotti OpenShift:

CRI-O è uno strumento re­la­ti­va­men­te nuovo nel campo della vir­tua­liz­za­zio­ne dei con­te­ni­to­ri e l’offerta per runtime al­ter­na­ti­vi per i con­te­ni­to­ri è sempre stata piuttosto ampia. Il punto forte di CRI-O è il suo focus sull’ambiente Ku­ber­ne­tes. Con CRI-O, infatti, Ku­ber­ne­tes può eseguire di­ret­ta­men­te i con­te­ni­to­ri senza strumenti ag­giun­ti­vi né per­so­na­liz­za­zio­ni speciali del codice. CRI-O stesso supporta i runtime esistenti e com­pa­ti­bi­li con OCI. Di seguito una pa­no­ra­mi­ca dei runtime più uti­liz­za­ti: