CRI-O es una im­ple­me­n­ta­ción de la Container Runtime Interface (CRI) para Ku­be­r­ne­tes, que utiliza in­s­ta­n­cias y entornos en tiempo de ejecución (runtimes) de Open Container Ini­tia­ti­ve (OCI). La empresa Red Hat inició el proyecto en 2016 y se lo cedió a la Cloud Native Computing Fou­n­da­tion (CNCF) en la primavera de 2019.

Private Cloud powered by VMware
Pago por uso y el más alto nivel de seguridad de los datos.

Bajo la división Arsys Cloud Solutions, diseñamos So­lu­cio­nes a tu medida.

¿Cómo funciona CRI-O?

Para entender cómo funciona CRI-O y cómo in­ter­ac­túa con las te­c­no­lo­gías re­la­cio­na­das, merece la pena echar un vistazo al de­sa­rro­llo histórico de la vi­r­tua­li­za­ción basada en co­n­te­ne­do­res. La base de su aparición fue el software Docker, que po­pu­la­ri­zó la vi­r­tua­li­za­ción de apli­ca­cio­nes in­di­vi­dua­les basadas en co­n­te­ne­do­res ligeros. Antes, se entendía por vi­r­tua­li­za­ción pri­n­ci­pa­l­me­n­te al uso de máquinas virtuales. Una máquina virtual contiene un sistema operativo completo, mientras que varios co­n­te­ne­do­res acceden a un núcleo de sistema operativo co­m­pa­r­ti­do.

Desde Docker hasta CRI-O, pasando por Ku­be­r­ne­tes

Un co­n­te­ne­dor suele alojar una sola apli­ca­ción, que a menudo pro­po­r­cio­na un mi­cro­se­r­vi­cio. En la práctica, suele ser necesario controlar un gran número de co­n­te­ne­do­res juntos para realizar una apli­ca­ción completa. La gestión coor­di­na­da de grupos enteros de co­n­te­ne­do­res se conoce como or­que­s­ta­ción.

Aunque se puede realizar la or­que­s­ta­ción con Docker y he­rra­mie­n­tas como Docker Swarm, ha surgido Ku­be­r­ne­tes, una al­te­r­na­ti­va a Docker. Ku­be­r­ne­tes agrupa varios co­n­te­ne­do­res en lo que se conoce como pod. Los pods, a su vez, se ejecutan en máquinas llamadas nodos, que pueden ser físicas o virtuales.

Uno de los problemas pri­mo­r­dia­les de Docker era la ar­qui­te­c­tu­ra mo­no­lí­ti­ca del software. El daemon de Docker fu­n­cio­na­ba con permisos de root y era re­s­po­n­sa­ble de una serie de tareas di­fe­re­n­tes: desde la descarga de las imágenes de co­n­te­ne­do­res hasta la ejecución en el entorno en tiempo de ejecución, pasando por la creación de nuevas imágenes. Esta fusión de áreas in­de­pe­n­die­n­tes viola el principio de de­sa­rro­llo de software de “se­pa­ra­tion of concerns” (“se­pa­ra­ción de intereses”) y conlleva problemas de seguridad en la práctica, entre otras cosas. Por lo tanto, co­n­ti­nua­ron los esfuerzos para des­aco­plar cada uno de los co­m­po­ne­n­tes.

Cuando Ku­be­r­ne­tes apareció por primera vez, el daemon de Ku­be­r­ne­tes, kubelet, incluía un sistema co­di­fi­ca­do de Docker en tiempo de ejecución. Sin embargo, pronto se hizo evidente la necesidad de hacerlo co­m­pa­ti­ble con otros entornos en tiempo de ejecución. La mo­du­la­ri­za­ción de cada uno de los aspectos prometía un de­sa­rro­llo posterior si­m­pli­fi­ca­do, así como una mayor seguridad. Para lograr que di­fe­re­n­tes sistemas en tiempo de ejecución fueran co­m­pa­ti­bles con Ku­be­r­ne­tes, se definió una interfaz: Container Runtime Interface (CRI). CRI-O es una im­ple­me­n­ta­ción concreta de esta interfaz.

Ar­qui­te­c­tu­ra y fu­n­cio­na­li­dad de CRI-O

Los si­guie­n­tes co­m­po­ne­n­tes forman parte de CRI-O:

  • La bi­blio­te­ca de software de co­n­te­ne­do­res/imágenes para descargar imágenes de co­n­te­ne­do­res de varias fuentes en línea.
  • La bi­blio­te­ca de software de co­n­te­ne­do­res/al­ma­ce­na­mie­n­to para gestionar las capas de co­n­te­ne­do­res y crear el sistema de archivos para los co­n­te­ne­do­res de un pod.
  • Un tiempo de ejecución co­m­pa­ti­ble con OCI para ejecutar los co­n­te­ne­do­res. El tiempo de ejecución estándar es runC, pero se pueden utilizar otros entornos en tiempo de ejecución co­m­pa­ti­bles con OCI, como Kata Co­n­tai­ne­rs.
  • La interfaz de red de co­n­te­ne­do­res (Container Ne­t­wo­r­ki­ng Interface o CNI) para crear la red de un pod, uti­li­za­n­do co­m­ple­me­n­tos para Flannel, Weave y OpenShift-SDN.
  • La he­rra­mie­n­ta de mo­ni­to­ri­za­ción de co­n­te­ne­do­res “conmon” para la mo­ni­to­ri­za­ción continua de los co­n­te­ne­do­res.

CRI-O también se suele utilizar junto con la he­rra­mie­n­ta de gestión de pod Podman. Esto da buenos re­su­l­ta­dos, dado que Podman se basa en las mismas bi­blio­te­cas para descargar las imágenes de los co­n­te­ne­do­res y gestionar las capas de estas, al igual que CRI-O.

El proceso básico para utilizar CRI-O sigue los si­guie­n­tes pasos:

  1. Descargar una imagen del co­n­te­ne­dor de OCI.
  2. Des­em­pa­que­tar la imagen en un paquete del sistema de archivos del tiempo de ejecución de OCI.
  3. Ejecutar el co­n­te­ne­dor a través de un entorno en tiempo de ejecución de OCI.

¿Dónde se utiliza CRI-O?

En la ac­tua­li­dad, CRI-O se utiliza sobre todo como parte de la línea de productos OpenShift de Red Hat. Existen im­ple­me­n­ta­cio­nes de OpenShift para las pla­ta­fo­r­mas en la nube de los pri­n­ci­pa­les pro­vee­do­res. Además, el software puede eje­cu­tar­se como parte de la pla­ta­fo­r­ma de co­n­te­ne­do­res OpenShift en centros de pro­ce­sa­mie­n­to de datos públicos o privados. A co­n­ti­nua­ción, se ofrece una visión general de los distintos productos de OpenShift:

Producto In­frae­s­tru­c­tu­ra Ge­s­tio­na­do por Asi­s­te­n­cia de
Red Hat OpenShift Dedicated AWS, Google Cloud Red Hat Red Hat
Microsoft Azure Red Hat OpenShift Microsoft Azure Red Hat y Microsoft Red Hat y Microsoft
Amazon Red Hat OpenShift AWS Red Hat y AWS Red Hat y AWS
Red Hat OpenShift on IBM Cloud IBM Cloud IBM Red Hat e IBM
Red Hat OpenShift Online Red Hat Red Hat Red Hat
Red Hat OpenShift Container Platform Nube privada, nube pública, máquina física, máquina virtual, Edge Cliente Red Hat, otros
Red Hat OpenShift Ku­be­r­ne­tes Engine Nube privada, nube pública, máquina física, máquina virtual, Edge Cliente Red Hat, otros

¿En qué se di­fe­re­n­cia CRI-O de otros tiempos de ejecución?

CRI-O es un de­sa­rro­llo re­la­ti­va­me­n­te nuevo en el campo de la vi­r­tua­li­za­ción de co­n­te­ne­do­res. Hi­s­tó­ri­ca­me­n­te, ha habido una serie de tiempos de ejecución de co­n­te­ne­do­res al­te­r­na­ti­vos. Pro­ba­ble­me­n­te, la ca­ra­c­te­rí­s­ti­ca más exclusiva de CRI-O es su enfoque singular en Ku­be­r­ne­tes como entorno. Con CRI-O, Ku­be­r­ne­tes está ha­bi­li­ta­do para ejecutar co­n­te­ne­do­res di­re­c­ta­me­n­te sin necesidad de he­rra­mie­n­tas adi­cio­na­les o mo­di­fi­ca­cio­nes de código es­pe­cia­les. El propio CRI-O es co­m­pa­ti­ble con los sistemas en tiempo de ejecución exi­s­te­n­tes y co­m­pa­ti­bles con OCI. A co­n­ti­nua­ción, se ofrece un resumen de los entornos en tiempo de ejecución de­sa­rro­lla­dos ac­ti­va­me­n­te y uti­li­za­dos con fre­cue­n­cia:

Tiempo de ejecución Tipo De­s­cri­p­ción
runC Nivel bajo de tiempo de ejecución de OCI Tiempo de ejecución estándar de facto, derivado de Docker y escrito en Go
crun Nivel bajo de tiempo de ejecución de OCI Tiempo de ejecución eficaz; im­ple­me­n­ta­do en C en lugar de en Go
Kata Co­n­tai­ne­rs Tiempo de ejecución de OCI vi­r­tua­li­za­do Utiliza una máquina virtual (VM) ligera
co­n­tai­ne­rd Nivel alto de tiempo de ejecución de OCI Uso de runC como medida estándar
CRI-O Tiempo de ejecución de CRI ligero Puede utilizar, entre otros, runC, crun y Kata Co­n­tai­ne­rs
Ir al menú principal