Cómo se compara containerd con runC

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

Runc es un componente de containerd, el ejecutor de contenedores. containerd tiene un alcance más amplio que solo ejecutar contenedores: descargar imágenes de contenedores, administrar interfaces de almacenamiento y red, llamar a runc con la derecha parámetros para ejecutar contenedores.

Esta imagen de la misma fuente describe esto muy bien.

Docker Engine es el producto de usuario final que utiliza containerd como componente principal e implementa otras funcionalidades que no entran en el ámbito 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.

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

RunC es el componente de nivel más bajo que implementa la interfaz OCI. Interactúa con el núcleo y "ejecuta" el contenedor

Containerd hace cosas como encargarse de configurar la red, transferencia/almacenamiento de imágenes, etc. cuidado del tiempo de ejecución completo del contenedor (lo que significa que administra y facilita la vida de 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 de Docker solo hace algunas cosas de alto nivel como aceptar comandos de usuario, descargar las imágenes del registro de docker, etc. Descarga mucho a Containerd.

" el demonio Docker prepara la imagen como una Imagen Contenedor Abierta (OCI) bundle y realiza una llamada API a containerd para iniciar el bundle OCI. containerd inicia el contenedor usando runC."

Tenga en cuenta que los tiempos de ejecución tienen que ser compatibles con OCI, (como lo es runC), es decir, tienen que exponer una API fija a administradores como containerd para que(containerd) puedan facilitarles la vida (runC) (y pedirles que detengan/inicien contenedores)

Rkt es otro tiempo de ejecución de contenedor, que aún no admite OCI, pero admite la appc especificación. Pero es una solución completa, gestiona y hace que su propia vida sea fácil, por lo que no necesita contenedores como papá.

Entonces, eso es todo. Ahora vamos a añadir otro componente (y otra interfaz) a la mezcla - Kubernetes

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

Puede ejecutar rkt con k8s, ya que rkt satisface la interfaz CRI - container runtime. Kubernetes no pide nada más, solo necesita CRI, no da una FF sobre cómo ejecutar sus contenedores, OCI o no.

Containerd no soporta CRI, pero cri-containerd que es una cuña alrededor de containerd sí. Por lo tanto, si desea ejecutar containerd con Kubernetes, debe usar cri-containerd (este también es el tiempo de ejecución predeterminado para Kubernetes). cri-containerd recientemente fue renombrado a CRI Plugin.

Si desea obtener el motor docker en la mezcla también, puede hacerlo. Use dockershim, agregará el CRI shim al motor docker.

Ahora, al igual que containerd puede administrar y facilitar la vida de runC (el tiempo de ejecución del contenedor), también puede administrar y facilitar la vida de otros tiempos de ejecución de contenedores, de hecho, para cada tiempo de ejecución de contenedor que admita el tiempo de ejecución del contenedor Kata similar a OCI (conocido como ~kata-runtime~ - https://github.com/kata-containers/runtime .) - que ejecuta contenedores kata, Borrar el tiempo de ejecución del contenedor (por Intel).

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

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

Es por eso que tenemos CRI-O. Es igual que containerd, pero implementa CRI. CRI-O necesita un tiempo de ejecución de contenedor para ejecutar imágenes. Administrará y hará la vida más fácil para ese tiempo de ejecución, pero necesita un tiempo de ejecución. Tomará cualquier tiempo de ejecución que sea OCI obediente. Así que, naturalmente, ~kata-runtime~ es compatible con CRI-O, runC es compatible con CRI-O.

El uso con Kubernetes es simple, apunta 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 real ES. Y Kubernetes se refiere a esa feliz pareja cuando dice tiempo de ejecución del contenedor).

Al igual que containerd tiene docker para hacerlo REALMENTE utilizable, y para administrar y hacer la vida fácil para containerd, CRI - O necesita a alguien que se encargue de la administración de imágenes-it has buildah, umochi etc.

Crun es otro tiempo de ejecución compatible con OCI y escrito en C. Es de RedHat.

Ya hemos discutido, kata-runtime es otro tiempo de ejecución que es compatible con OCI. Entonces, podemos usar kata-runtime con CRI-O como discutimos.

Nota, 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 podría ser kata-runtime También.

No se olvide de containerd, puede administrar y hacer la vida fácil para todos los tiempos de ejecución de quejas de OCI también-runC seguro, 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 del contenedor, simplemente cambie el tiempo de ejecución a "kata"

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

Esto es realmente guay: top:

Kubernetes, representado aquí por su Embajador, el Sr. Kubelet dirige todo lo que satisface al CRI. Ahora, tenemos varios candidatos que pueden. - Cri-containerd hace que containerd lo haga. - CRI-O lo hace de forma nativa. - Dockershim hace que el motor Docker lo haga.

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

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

Aquí tenemos CRI-O en acción administrando y haciendo la vida fácil para kata-runtime y runC compatibles con OCI

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

• railcar-OCI compliant, escrito en rust
• Bolsa - runC modificado de Alibaba
• nvidia runtime - bifurcación de nvidia de runC

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