docker - remove - ¿Cómo se compara el contenido con runC?

docker tag example (3)

¿Cómo se comparan estos dos? Según tengo entendido, runC es un entorno de tiempo de ejecución para contenedores. Eso significa que este componente proporciona el entorno necesario para ejecutar contenedores. ¿Cuál es el papel de la contención aquí entonces? Si hace el resto (redes, gestión de volúmenes, etc.), ¿cuál es la función del motor Docker? ¿Y qué hay de la malla contenida? Básicamente, estoy tratando de entender qué hace cada uno de estos componentes.

Daré una descripción general de alto nivel para comenzar:

containerd es un tiempo de ejecución de contenedor que puede administrar un ciclo de vida completo del contenedor, desde la transferencia / almacenamiento de imágenes hasta la ejecución, supervisión y redes de contenedores.
la cuba del contenedor maneja los contenedores sin cabeza, lo que significa que una vez que el inicio inicializa los contenedores, sale de entregar los contenedores a la cuña del contenedor que actúa como un intermediario.
runc es un contenedor de tiempo de ejecución universal ligero, que cumple con la especificación OCI. rerd es utilizado por containererd para generar y ejecutar contenedores de acuerdo con las especificaciones de OCI. También es el reenvasado de libcontainer.
grpc utilizado para la comunicación entre Container y Docker-Engine.
OCI mantiene la especificación OCI para el tiempo de ejecución y las imágenes. Las versiones actuales de la ventana acoplable son compatibles con las especificaciones OCI de imagen y tiempo de ejecución.

Más enlaces:

El motor Docker es todo, era un monolito que permitía a los usuarios ejecutar contenedores. Luego se dividió en componentes individuales. Se desglosó en: - motor de la ventana acoplable - container - runc

runC es el componente de nivel más bajo que implementa la interfaz OCI. Interactúa con el kernel y ejecuta el contenedor.

Consigner hace cosas como encargarse de configurar la red, la transferencia / almacenamiento de imágenes, etc. Se encarga del tiempo de ejecución completo del contenedor (lo que significa que administra y hace la vida más fácil para runC, que es el tiempo de ejecución real del contenedor). A diferencia del demonio Docker, tiene un conjunto de características reducido; no admite la descarga de imágenes, por ejemplo.

El motor Docker solo hace algunas cosas de alto nivel, como aceptar los comandos del usuario, descargar las imágenes desde el registro de la ventana acoplable, etc. Se descarga mucho al contenedor.

"el demonio de Docker prepara la imagen como un paquete de imagen de contenedor abierto (OCI) y realiza una llamada a la API para que contenga para iniciar el paquete de OCI. Container luego inicia el contenedor utilizando runC".

Tenga en cuenta que los tiempos de ejecución deben ser compatibles con OCI, (como runC es), es decir, tienen que exponer una API fija a los administradores, como la administración de contenido, para que ellos puedan hacerles la vida más fácil (runC) (y pedirles que lo hagan). contenedores de parada / arranque)

rkt es otro tiempo de ejecución de contenedor, que aún no es compatible con OCI, pero es compatible con la especificación appc. Pero es una solución completa, se administra y hace que su propia vida sea fácil, por lo que no necesita contención como papá.

Entonces, eso es eso. Ahora agreguemos otro componente (y otra interfaz) a la mezcla - Kubernetes

Kubernetes puede ejecutar cualquier cosa que satisfaga la interfaz de tiempo de ejecución del contenedor CRI.

Puede ejecutar rkt con k8s, ya que rkt satisface la interfaz de tiempo de ejecución del contenedor CRI. Kubernetes no solicita nada más, solo necesita CRI, no le da a un FF cómo maneja sus contenedores, OCI o no.

Container no es compatible con CRI, pero cri-Container, que es un shim alrededor de Container, sí lo hace. Por lo tanto, si desea ejecutar containererd con Kubernetes, tiene que usar cri-contenererd (este también es el tiempo de ejecución predeterminado para Kubernetes). cri-containererd recientemente cambió su nombre a CRI Plugin.

Si desea que el motor de la ventana acoplable también esté en la mezcla, puede hacerlo. Use dockershim, agregará la protección CRI al motor de la ventana acoplable.

Ahora, al igual que Container puede administrar y hacer la vida fácil para runC (el tiempo de ejecución del contenedor), también puede administrar y hacer la vida más fácil para otros tiempos de ejecución del contenedor, de hecho, para cada tiempo de ejecución de contenedor compatible con OCI, como el tiempo de ejecución del contenedor Kata (conocido como ~ kata-runtime ~ - https://github.com/kata-containers/runtime .) - que ejecuta contenedores de kata, Clear Container runtime (por Intel).

Ahora sabemos que rkt satisface el CRI, cri-containererd (también conocido como CRI Plugin) lo hace también.

Tenga en cuenta lo que hace Containerd está haciendo aquí. No es un tiempo de ejecución, es un administrador de runC que es el tiempo de ejecución del contenedor. Solo gestiona la descarga de imágenes, el almacenamiento, etc. Diablos, ni siquiera satisface el CRI.

Es por eso que tenemos CRI-O. Es igual que Container, pero implementa CRI. CRI-O necesita un tiempo de ejecución de contenedor para ejecutar imágenes. Gestionará y facilitará la vida para ese tiempo de ejecución, pero necesita un tiempo de ejecución. Tomará cualquier tiempo de ejecución que sea compatible con OCI. Entonces, naturalmente, ~ kata-runtime ~ es compatible con CRI-O, runC es compatible con CRI-O.

El uso con Kubernetes es simple, señale Kubernetes a CRI-O como el tiempo de ejecución del contenedor. (Sí, sí, CRI-O, pero CRI-O y el tiempo de ejecución del contenedor es IS. Y Kubernetes se refiere a esa feliz pareja cuando dice el tiempo de ejecución del contenedor).

Al igual que Container tiene una ventana acoplable para que sea REALMENTE utilizable, y para administrar y hacer la vida más fácil para contenererd, CRI-O necesita que alguien se encargue de la gestión de la imagen: tiene buildah, umochi, etc.

crun es otro tiempo de ejecución que cumple con OCI y está escrito en C. Es de RedHat.

Ya hemos discutido, el tiempo de ejecución de kata es otro tiempo de ejecución que cumple con OCI. Por lo tanto, podemos usar el tiempo de ejecución de kata con CRI-O como hemos discutido.

Tenga en cuenta que aquí, el kubelet está hablando con CRI-O a través del CRI. CRI-O está hablando con cc-runtime (que es otro tiempo de ejecución para los contenedores transparentes de Intel, sí, compatible con OCI), pero también podría ser el tiempo de ejecución de kata.

No olvide contener, puede administrar y hacer la vida fácil para todos los tiempos de ejecución de quejas de OCI también - runC sure, pero también kata-runtime, cc-runtime

Aquí, tenga en cuenta que solo el tiempo de ejecución se mueve de runC a kata-runtime. Para hacer esto, en la configuración de configuración, simplemente cambie el tiempo de ejecución a "kata"

No hace falta decir que puede ejecutarse en Kubernetes por CRI-O o por cri-container (también conocido como CRI Plugin).

Esto es realmente genial: arriba:

Kubernetes, representado aquí por su Embajador, el Sr. Kubelet maneja cualquier cosa que satisfaga al CRI. Ahora, tenemos varios candidatos que pueden. - Cri-Container hace que el Container lo haga. - CRI-O lo hace de forma nativa. - Dockershim hace que el motor docker lo haga.

Ahora, los 3 tipos anteriores, pueden administrar y hacer la vida más fácil para todos los tiempos de ejecución compatibles con OCI: runC, kata-runtime, cc-run time.

También tenemos frakti, que satisface el CRI, como rkt, pero no satisface a OCI, y viene con su propio tiempo de ejecución de contenedor.

Aquí tenemos CRI-O en acción, gestionando y facilitando la vida para kata-runtime y runC, ambos compatibles.

También tenemos algunos tiempos de ejecución más:

vagón - compatible con OCI, escrito en óxido
Bolsa - el runC modificado de Alibaba
nvidia runtime - bifurcación de nvidia de runC

ref: https://github.com/darshanime/notes/blob/master/kubernetes.org#notes

runc es uno de los componentes de containerd y maneja la interacción a nivel de kernel para ejecutar contenedores. En versiones anteriores, containerd era esencialmente una abstracción de alto nivel en torno a runc pero ahora es mucho más que eso. Desde container.io :

runc es un componente de containererd, el ejecutor de contenedores. Container tiene un alcance más amplio que la ejecución de contenedores: descarga de imágenes de contenedores, administración de interfaces de red y almacenamiento, llamadas a Runc con los parámetros correctos para ejecutar contenedores.

Esta imagen de la misma fuente describe muy bien esto.

Docker Engine es el producto de usuario final que utiliza containerd como componente principal e implementa otras funcionalidades que no están dentro del alcance de containerd .

Tenga en cuenta que Docker extrajo containerd como un componente separado, por lo que también puede ser utilizado y desarrollado por otros productos.