Cuando Docker lo petó en el mundo de los contenedores bastante con saber que el demonio Docker se encargaba de todo….

Por suerte (o no) los contenedores ya no están acoplados a Docker ya que alrededor han aparecido nuevas tecnologías y algunas han ido estandarizándose, así que es importante conocer el significado de algunos términos como OCI, CRI, CRI-O, containerd,…

De entre estas las más importantes serían:

• CRI (Kubernetes Container Runtime Interface) que define un API entre Kubernetes y el Runtime del Contenedor
• OCI (Open Container Initiative) que publica las especificadores para imágenes y contenedores

Relación entre tecnologías

En la siguiente imagen aparecen estas tecnologías y cómo trabajan entre ellas:

Docker:

Aún hoy (y a pesar de muchos) Docker sigue siendo la herramienta más popular para trabajar con contenedores. Y hay que reconocer que Docker inició esta revolución.

Dentro de Docker tenemos:

Docker está diseñado para ser instalado tanto en un PC como en un servidor e incluye un conjunto de herramientas para facilitar la construcción y ejecución de contenedores:

• docker-cli: es la línea de comandos con la que se interactúa mediante comandos docker ….
• containerd: Es el proceso demonio que gestiona y ejecuta los contenedores. Hace el Push y pull de las imágenes, gestiona el almacenamiento, la red y supervisa la ejecución de los contenedores. Por eso se dice que es un fat-daemon.
• runc: es el runtime de bajo de nivel de los contenedores, incluye libcontainer, una implementación nativa basada en Go para crear contenedores.

En realidad, cuando se ejecuta un contenedor con docker, se está ejecutando a través del demonio Docker, containerd, y luego runc.

Dockershim

Kubernetes incluye un componente llamado dockershim, que le permite soportar Docker, aunque Kubernetes prefiere ejecutar los contenedores a través de cualquier runtime de contenedores que soporte su Container Runtime Interface (CRI). Pero Docker, al ser más antiguo que Kubernetes, no implementa la CRI. Por eso existe el dockershim, para básicamente permitir usar Docker dentro de Kubernetes.

Todos hemos oído que en el futuro, Kubernetes eliminará la compatibilidad con Docker directamente, sólo soportando la ejecución de contenedores que implementen su Container Runtime Interface (CRI), bien sea vía containerd o CRI-O.

Por otro lado, esto no significa que Kubernetes no pueda ejecutar contenedores con formato Docker. Tanto containerd como CRI-O pueden ejecutar imágenes con formato Docker (en realidad con formato OCI), sólo que lo hacen sin tener que utilizar el comando docker o el demonio Docker.

Imágenes Docker

Cuando hablamos de imágenes Docker en realidad tenemos imágenes empaquetadas en el formato Open Container Initiative (OCI) y por tanto se pueden usar con el comando Docker, con Podman, con Kubernetes o con cualquier herramienta que soporte la especificación del formato de imagen OCI.

Container Runtime Interface (CRI)

Como hemos dicho, CRI es la API que Kubernetes utiliza para controlar los diferentes runtimes que crean y gestionan los contenedores.

CRI facilita a Kubernetes el uso de diferentes runtimes de contenedores,

containerd

containerd es un runtime de contenedores (que proviene de Docker) e implementa la especificación CRI. containerd fue separado del proyecto Docker, para hacer Docker más modular, así que Docker utiliza containerd internamente y cuando se instala Docker, también se instala containerd.

CRI-O

CRI-O es otro runtime de contenedores de alto nivel que implementa la interfaz CRI. Nació de la mano de Red Hat, IBM, Intel, SUSE y otros.

Fue creado específicamente desde el principio como un runtime de contenedores para Kubernetes.

Open Container Initiative (OCI)

La OCI es un grupo de empresas tecnológicas que mantienen una especificación para el formato de imagen de los contenedores, y cómo deben ejecutarse.

La idea detrás de la OCI es que se puede elegir entre diferentes runtimes que se ajusten a la especificación siguiendo el enfoque mismo enfoque de «un estándar, muchas implementaciones«.

En el siguiente post compararemos Docker con Podman, el que parece su sustituto natural…

Leer más