Los contenedores todavía significan "Docker" para muchas personas. Docker popularizó el uso moderno de contenedores en el desarrollo y la implementación de software. En estos días, también existen otras tecnologías. Así es como Containerd, Docker y Kubernetes se relacionan entre sí.
Los comienzos
En su lanzamiento en 2013, Docker era un proyecto autónomo con todo lo necesario para crear y ejecutar contenedores. Lo que le faltaba era una manera fácil de orquestar implementaciones de contenedores en la nube.
A fines de 2013, un grupo de Googlers ya estaba abordando esto con un prototipo de lo que se convertiría en Kubernetes. Kubernetes está diseñado para simplificar la operación de cargas de trabajo en contenedores en grandes flotas de máquinas.
En aquellos primeros días, Kubernetes estaba inextricablemente vinculado a Docker. Usó Docker directamente para interactuar con los contenedores, aunque solo necesitaba un subconjunto de funciones:las partes responsables de ejecutar los contenedores.
La interfaz de usuario centrada en el desarrollador de Docker se interpuso en el camino de Kubernetes. Tuvo que pasar por alto los aspectos amigables para los humanos del proyecto utilizando una herramienta dedicada, Dockershim. Los problemas se vieron agravados por las diferentes direcciones en las que se dirigían Docker y Kubernetes. Docker lanzó Swarm, su propia alternativa a Kubernetes, que ofrece orquestación como un "modo" integrado de Docker.
El auge de Containerd
A medida que Kubernetes creció y surgieron más herramientas de terceros en torno a Docker, las limitaciones de su arquitectura se hicieron evidentes. Al mismo tiempo, Open Container Initiative (OCI) comenzó a estandarizar los formatos y los tiempos de ejecución de los contenedores. Esto resultó en una especificación OCI que define un contenedor que podría ser utilizado por múltiples tiempos de ejecución, de los cuales Docker es un ejemplo.
Luego, Docker extrajo el tiempo de ejecución de su contenedor en un nuevo proyecto, containerd. Esto incluye la funcionalidad de Docker para ejecutar contenedores, manejar almacenamiento de bajo nivel y administrar transferencias de imágenes. Containerd fue donado a Cloud Native Computing Foundation (CNCF) para proporcionar a la comunidad de contenedores una base para crear nuevas soluciones de contenedores.
La aparición de containerd facilita que proyectos como Kubernetes accedan a los elementos "Docker" de bajo nivel que necesitan. En lugar de usar Docker, ahora tienen una interfaz más accesible para el tiempo de ejecución del contenedor. La estandarización OCI de las tecnologías de contenedores significa que también se pueden usar otros tiempos de ejecución.
Comprender el papel de Containerd
Para comprender completamente el contenido, es necesario observar la naturaleza de los contenedores. Los contenedores son realmente una abstracción sobre varias características del kernel de Linux. Para ejecutar un contenedor, debe usar llamadas al sistema para configurar el entorno en contenedores. Los pasos varían según la plataforma y la distribución.
Containerd aparece para abstraer este cableado de bajo nivel. Está pensado como una "capa de cliente" sobre la que se construye el software contenedor. Puede tratarse de software orientado a desarrolladores, como Docker, o herramientas de desarrollo de dispositivos orientadas a la nube, como Kubernetes.
Anteriormente, el desarrollo de Kubernetes se quedó con dos malas opciones:seguir escribiendo shims alrededor de la robusta interfaz de Docker o comenzar a interactuar directamente con las funciones del kernel de Linux. Al separar containerd de Docker, se hizo disponible una tercera alternativa:usar containerd como una capa de abstracción del sistema, sin involucrar a Docker.
Aquí hay un resumen de cómo se combinan las tres tecnologías:
- Docker – Un software orientado a desarrolladores con una interfaz de alto nivel que le permite crear y ejecutar contenedores fácilmente desde su terminal. Ahora usa containerd como tiempo de ejecución del contenedor.
- Contenedor – Una abstracción de las funciones del núcleo que proporciona una interfaz de contenedor de nivel relativamente alto. Otros proyectos de software pueden usar esto para ejecutar contenedores y administrar imágenes de contenedores.
- Kubernetes – Un orquestador de contenedores que funciona con múltiples tiempos de ejecución de contenedores, incluido containerd. Kubernetes se centra en la implementación de contenedores en conjunto en uno o más "nodos" físicos. Históricamente, Kubernetes estuvo vinculado a Docker.
Containerd es solo un backend de contenedor. Otros contenedores que implementan la especificación Open Containers Runtime incluyen runC y CRI-O. Estos tiempos de ejecución también se pueden usar con Docker y Kubernetes; cada uno tiene sus propias distinciones.
La OCI
La OCI es el organismo encargado de definir los estándares de los contenedores. Su trabajo ha sido fundamental para facilitar la interoperabilidad entre diferentes tecnologías de componentes.
La especificación de imagen de la OCI define el aspecto que debe tener un contenedor. La especificación de tiempo de ejecución establece una interfaz para ejecutar contenedores. Proyectos como containerd luego implementan estas especificaciones.
Es importante destacar que una de las prioridades de la OCI es respaldar la experiencia de uso de contenedores popularizada por Docker. Sus imágenes deben ser ejecutables en la plataforma de destino sin argumentos definidos por el usuario (por ejemplo, docker run hello-world:latest ). Por lo tanto, las imágenes OCI deben contener suficientes metadatos para habilitar esta configuración automática.
También puede ver referencias a la interfaz de tiempo de ejecución del contenedor (CRI). Esta es una abstracción específica de Kubernetes sobre la especificación OCI. El CRI se basa en las especificaciones de OCI para habilitar la compatibilidad con tiempos de ejecución de contenedores intercambiables dentro de Kubernetes.
¿Qué pasa con mis imágenes de Docker?
Las imágenes que crea con Docker no son realmente "imágenes de Docker" en absoluto. Como Docker ahora usa el tiempo de ejecución de contenedor, sus imágenes se crean en el formato estandarizado de Open Container Initiative (OCI).
No debería preocuparse por las incompatibilidades entre sus imágenes de Docker y el entorno en el que se usan. Las imágenes que crea con Docker aún se pueden implementar con Kubernetes. Esto se debe a que Kubernetes también admite imágenes OCI, mediante el uso de containerd (y otros tiempos de ejecución que cumplen con los estándares). Depende del tiempo de ejecución para manejar la extracción y ejecución de imágenes, no la interfaz de alto nivel que proporcionan herramientas como Docker y Kubernetes.
Kubernetes y Docker
Kubernetes dejó de usar el tiempo de ejecución de Docker a fines de 2020. Se eliminará en una versión futura, actualmente programada para finales de 2021. Después de eso, Kubernetes ya no ofrecerá el tiempo de ejecución de Docker. apoyo. En su lugar, deberá utilizarse un tiempo de ejecución alternativo compatible con las especificaciones de OCI, como containerd.
Este anuncio generó preocupación sobre las implicaciones para los desarrolladores. El cambio no debería afectar a la mayoría de los flujos de trabajo existentes. Como ya hemos visto, Docker produce imágenes compatibles con OCI que pueden ejecutar tiempos de ejecución compatibles con OCI. Cualquier imagen que construyas con docker build seguirá funcionando dentro de Kubernetes, incluso después de que se elimine el tiempo de ejecución de Docker.
Se están considerando dos tecnologías diferentes:la interfaz de línea de comandos de Docker. se utiliza para crear y ejecutar contenedores, y el tiempo de ejecución de Docker que envuelve la interfaz de línea de comandos.
¡Es demasiado confuso!
En solo unos pocos años, los contenedores han transformado la forma en que trabajan muchos desarrolladores. La expansión en el ecosistema circundante ha sido un subproducto natural de este cambio. Los Containers === Docker La mentalidad resultó ser demasiado asfixiante, ya que impedía que herramientas como Kubernetes mostraran todo su potencial.
El movimiento hacia la estandarización ha resultado en una plétora de nuevos términos, herramientas y tecnologías. No obstante, nada ha cambiado realmente para los desarrolladores, ya sea que interactúen con la CLI de Docker en su máquina o con un clúster de Kubernetes en la nube.
Cada interfaz de usuario de alto nivel (como Docker y Kubernetes) ahora se beneficia de una selección de tiempos de ejecución de contenedores de bajo nivel intercambiables (como containerd y runC). Esto permite un mayor grado de flexibilidad y permite que las nuevas tecnologías basadas en contenedores se establezcan de manera alineada con los estándares.