¿Qué es CRI-O?

CRI-O es una implementación de la Container Runtime Interface (CRI) para Kubernetes, que utiliza instancias y entornos en tiempo de ejecución (runtimes) de Open Container Initiative (OCI). La empresa Red Hat inició el proyecto en 2016 y se lo cedió a la Cloud Native Computing Foundation (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 Soluciones a tu medida.

¿Cómo funciona CRI-O?

Para entender cómo funciona CRI-O y cómo interactúa con las tecnologías relacionadas, merece la pena echar un vistazo al desarrollo histórico de la virtualización basada en contenedores. La base de su aparición fue el software Docker, que popularizó la virtualización de aplicaciones individuales basadas en contenedores ligeros. Antes, se entendía por virtualización principalmente al uso de máquinas virtuales. Una máquina virtual contiene un sistema operativo completo, mientras que varios contenedores acceden a un núcleo de sistema operativo compartido.

Desde Docker hasta CRI-O, pasando por Kubernetes

Un contenedor suele alojar una sola aplicación, que a menudo proporciona un microservicio. En la práctica, suele ser necesario controlar un gran número de contenedores juntos para realizar una aplicación completa. La gestión coordinada de grupos enteros de contenedores se conoce como orquestación.

Aunque se puede realizar la orquestación con Docker y herramientas como Docker Swarm, ha surgido Kubernetes, una alternativa a Docker. Kubernetes agrupa varios contenedores 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 primordiales de Docker era la arquitectura monolítica del software. El daemon de Docker funcionaba con permisos de root y era responsable de una serie de tareas diferentes: desde la descarga de las imágenes de contenedores 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 independientes viola el principio de desarrollo de software de “separation of concerns” (“separación de intereses”) y conlleva problemas de seguridad en la práctica, entre otras cosas. Por lo tanto, continuaron los esfuerzos para desacoplar cada uno de los componentes.

Cuando Kubernetes apareció por primera vez, el daemon de Kubernetes, kubelet, incluía un sistema codificado de Docker en tiempo de ejecución. Sin embargo, pronto se hizo evidente la necesidad de hacerlo compatible con otros entornos en tiempo de ejecución. La modularización de cada uno de los aspectos prometía un desarrollo posterior simplificado, así como una mayor seguridad. Para lograr que diferentes sistemas en tiempo de ejecución fueran compatibles con Kubernetes, se definió una interfaz: Container Runtime Interface (CRI). CRI-O es una implementación concreta de esta interfaz.

Arquitectura y funcionalidad de CRI-O

Los siguientes componentes forman parte de CRI-O:

  • La biblioteca de software de contenedores/imágenes para descargar imágenes de contenedores de varias fuentes en línea.
  • La biblioteca de software de contenedores/almacenamiento para gestionar las capas de contenedores y crear el sistema de archivos para los contenedores de un pod.
  • Un tiempo de ejecución compatible con OCI para ejecutar los contenedores. El tiempo de ejecución estándar es runC, pero se pueden utilizar otros entornos en tiempo de ejecución compatibles con OCI, como Kata Containers.
  • La interfaz de red de contenedores (Container Networking Interface o CNI) para crear la red de un pod, utilizando complementos para Flannel, Weave y OpenShift-SDN.
  • La herramienta de monitorización de contenedores “conmon” para la monitorización continua de los contenedores.

CRI-O también se suele utilizar junto con la herramienta de gestión de pod Podman. Esto da buenos resultados, dado que Podman se basa en las mismas bibliotecas para descargar las imágenes de los contenedores y gestionar las capas de estas, al igual que CRI-O.

El proceso básico para utilizar CRI-O sigue los siguientes pasos:

  1. Descargar una imagen del contenedor de OCI.
  2. Desempaquetar la imagen en un paquete del sistema de archivos del tiempo de ejecución de OCI.
  3. Ejecutar el contenedor a través de un entorno en tiempo de ejecución de OCI.

¿Dónde se utiliza CRI-O?

En la actualidad, CRI-O se utiliza sobre todo como parte de la línea de productos OpenShift de Red Hat. Existen implementaciones de OpenShift para las plataformas en la nube de los principales proveedores. Además, el software puede ejecutarse como parte de la plataforma de contenedores OpenShift en centros de procesamiento de datos públicos o privados. A continuación, se ofrece una visión general de los distintos productos de OpenShift:

Producto Infraestructura Gestionado por Asistencia 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 Kubernetes Engine Nube privada, nube pública, máquina física, máquina virtual, Edge Cliente Red Hat, otros

¿En qué se diferencia CRI-O de otros tiempos de ejecución?

CRI-O es un desarrollo relativamente nuevo en el campo de la virtualización de contenedores. Históricamente, ha habido una serie de tiempos de ejecución de contenedores alternativos. Probablemente, la característica más exclusiva de CRI-O es su enfoque singular en Kubernetes como entorno. Con CRI-O, Kubernetes está habilitado para ejecutar contenedores directamente sin necesidad de herramientas adicionales o modificaciones de código especiales. El propio CRI-O es compatible con los sistemas en tiempo de ejecución existentes y compatibles con OCI. A continuación, se ofrece un resumen de los entornos en tiempo de ejecución desarrollados activamente y utilizados con frecuencia:

Tiempo de ejecución Tipo Descripció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; implementado en C en lugar de en Go
Kata Containers Tiempo de ejecución de OCI virtualizado Utiliza una máquina virtual (VM) ligera
containerd 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 Containers
¿Le ha resultado útil este artículo?
Page top