Containerd frente a Docker: Comprender los tiempos de ejecución de los contenedores

En el ecosistema de contenedores, suele surgir confusión cuando los programadores comparan Docker (una plataforma integral) con containerd, que en realidad es un componente de tiempo de ejecución específico. Esta comparación es como comparar un automóvil completo con su motor: ambos son esenciales, pero cumplen funciones diferentes en distintos niveles de abstracción. 

En esta guía, aclararé la relación entre estas dos tecnologías, explorando sus arquitecturas, la integración de Kubernetesn y los escenarios específicos en los que cada herramienta destaca. Tanto si estás creando contenedores localmente como si gestionas clústeres de Kubernetes en producción, saber cuándo utilizar Docker y cuándo containerd puede influir significativamente en tus decisiones sobre infraestructura.

Al final de este artículo, comprenderás claramente cómo Docker y containerd se complementan entre sí, y cómo elegir la herramienta adecuada para tus necesidades específicas, ya sea para un desarrollo local rápido o para implementaciones de producción a gran escala.

Si eres nuevo en el mundo de la contenedorización, te recomiendo encarecidamente que realices nuestro curso Conceptos de contenedorización y virtualización.

¿Qué es Docker?

Docker revolucionó el panorama del desarrollo de software al hacer que la contenedorización fuera accesible y práctica para los programadores cotidianos. Como plataforma integral, Docker proporciona todo lo necesario para crear, enviar y ejecutar aplicaciones en contenedores.

Para los principiantes, esta Guía práctica sobre contenedoresofrece una excelente introducción a Docker y los contenedores.

Una plataforma integral para contenedores

Docker funciona como una plataforma de contenedores todo en uno, , y ofrece un conjunto de herramientas integradas que cubre la mayor parte del ciclo de vida de los contenedores. Básicamente, Docker empaqueta aplicaciones con todas sus dependencias en imágenes portátiles e independientes que pueden ejecutarse de forma coherente en cualquier entorno, desde el ordenador portátil de un programador hasta los servidores de producción.

Este enfoque integral ha convertido a Docker en el estándar del sector para el desarrollo local y la experiencia de los programadores. Algunas de las principales ventajas son:

• Amplio ecosistema: Docker Hub aloja millones de imágenes preconstruidas, desde bases de datos hasta servidores web, lo que elimina los complejos procedimientos de instalación.
• Portabilidad universal: Un contenedor creado en macOS funciona de forma idéntica en Linux o Windows, siempre que tengas instalado Docker.
• Enfoque para programadores: Resume las diferencias de infraestructura para que los programadores puedan concentrarse en sus aplicaciones en lugar de en las complejidades de la implementación.
• Incorporación rápida: Los nuevos miembros del equipo pueden poner en marcha entornos de desarrollo en cuestión de minutos, en lugar de horas.

Componentes clave y flujo de trabajo

La arquitectura de Docker consta de varios componentes interconectados que funcionan juntos a la perfección. 

La CLI de Docker proporciona la interfaz de usuario desde la que los programadores ejecutan comandos. Cuando ejecutas un comando como docker run, la CLI se comunica con el demonio Docker (dockerd), que actúa como servicio central para gestionar contenedores, imágenes, redes y volúmenes.

Para los usuarios de Windows y macOS, Docker Desktop ofrece una capa adicional de comodidad con una interfaz gráfica, lo que hace que la gestión de contenedores sea accesible incluso para aquellos que no están tan familiarizados con las herramientas de línea de comandos. Este entorno integrado incluye todo lo necesario para el desarrollo local, desde compatibilidad con Kubernetes hasta gestión de volúmenes.

El flujo de trabajo típico sigue un patrón claro: 

1. Los programadores crean imágenes utilizando archivos Dockerfiles.
2. Los envían a registros como Docker Hub.
3. Por último, las imágenes se ejecutan como contenedores en cualquier host habilitado para Docker. 

Lo que muchos programadores no saben es que Docker no ejecuta los contenedores directamente. En su lugar, dockerd delega la ejecución real del contenedor a containerd, que se ejecuta en segundo plano como un proceso independiente.

Este diseño modular, en el que Docker utiliza containerd para operaciones de bajo nivel, permite que cada componente se centre en lo que mejor sabe hacer: Docker proporciona una interfaz y un ecosistema fáciles de usar para los programadores, mientras que containerd se encarga de los detalles técnicos de la ejecución de los contenedores.

Tanto si acabas de empezar con Docker como si quieres dar el siguiente paso, echa un vistazo a nuestras 10 ideas de proyectos con Docker para todos los niveles.

¿Qué es Containerd?

Tras haber explorado el enfoque integral de la plataforma Docker, pasemos ahora a examinar containerd, el tiempo de ejecución especializado que impulsa la ejecución de contenedores tanto dentro de Docker como en todo el ecosistema más amplio.

Un tiempo de ejecución de contenedores estándar del sector.

Containerd es un entorno de ejecución de contenedores ligero y estándar en el sector que ha obtenido la certificación de la Cloud Native Computing Foundation (CNCF), lo que demuestra su madurez, fiabilidad y amplia adopción. Originalmente parte de Docker, containerd se extrajo en 2017 y se donó a CNCF para permitir una adopción más amplia del ecosistema.

A diferencia del completo conjunto de funciones de Docker, el alcance de containerd es deliberadamente limitado: gestiona operaciones básicas del ciclo de vida de los contenedores, como iniciar, detener, pausar y eliminar, y se encarga de la transferencia y el almacenamiento de imágenes. Este enfoque específico hace que containerd sea excepcionalmente estable y eficiente, cualidades esenciales para los entornos de producción.

Piensa en containerd como «fontanería»: una infraestructura diseñada para integrarse en sistemas más grandes en lugar de ser utilizada directamente por personas. Las principales plataformas, como Kubernetes, AWS Fargate y Google Kubernetes Engine, dependen de containerd para ejecutar contenedores, aunque los usuarios interactúen con estas plataformas a través de sus propias interfaces.

Arquitectura y diseño

Para comprender por qué containerd se utiliza tan ampliamente en los sistemas de producción, debemos examinar sus principios arquitectónicos.

La arquitectura de Containerd es un ejemplo de los principios del diseño modular. Construido con los estándares de la Open Container Initiative (OCI) como base, containerd garantiza la compatibilidad en todo el ecosistema de contenedores. Esto significa que cualquier imagen compatible con OCI funcionará con containerd, independientemente de la herramienta con la que se haya creado.

La arquitectura consta de varias capas clave:

• Capa API gRPC: Proporciona un modelo cliente-servidor en el que varios clientes (Docker, Kubernetes, herramientas personalizadas) se comunican con una única instancia de containerd.
• Demonio Containerd: Mantiene el estado de los contenedores en ejecución, gestiona el almacenamiento de imágenes a través de snapshotters y coordina las redes a través de plugins.
• Tiempo de ejecución de runc: Un tiempo de ejecución ligero y compatible con OCI que interactúa directamente con las funciones del kernel de Linux, creando espacios de nombres, configurando cgroups y lanzando procesos de contenedores.
• Complementos modulares: Se pueden integrar instantáneas personalizadas para almacenamiento especializado, tiempos de ejecución alternativos (gVisor, Kata Containers) y complementos de red sin modificar containerd.

Cuando containerd necesita iniciar un contenedor, genera runc, que realiza el trabajo real de crear espacios de nombres aislados, configurar cgroups para los límites de recursos e iniciar el proceso del contenedor. 

Esta separación de responsabilidades hace que containerd sea altamente extensible. Las organizaciones pueden personalizar casi todos los aspectos sin tocar el código central de containerd.

Diferencias clave entre Containerd y Docker

Ahora que ya conoces bien las funciones de cada herramienta, veamos en qué se diferencian en la práctica, desde la arquitectura hasta los patrones de integración.

Tiempo de ejecución de contenedores frente a plataforma

La diferencia fundamental radica en el alcance y el propósito. 

Docker utiliza una arquitectura de demonio centralizada en la que dockerd coordina muchos aspectos diferentes, tales como:

• La imagen se construye
• Ejecución de contenedores
• Redes
• Gestión del volumen

Este diseño todo en uno simplifica la experiencia de los programadores, pero introduce una sobrecarga debido a las múltiples capas de abstracción.

Containerd, por el contrario, se centra exclusivamente en la ejecución de contenedores. No incluye capacidades de creación de imágenes, funciones de orquestación ni una interfaz gráfica. Para la creación de redes, Docker incluye una interfaz de red de contenedores ( Libnetwork ) integrada en su demonio, mientras que containerd se basa en complementos externos de interfaz de red de contenedores (CNI) que se pueden intercambiar en función de las necesidades.

Esta diferencia arquitectónica tiene implicaciones en el rendimiento. En entornos con alta rotación, donde los contenedores se inician y se detienen con frecuencia, como los clústeres de Kubernetes con autoescalado, el diseño optimizado de containerd puede traducirse en tiempos de inicio más rápidos y un menor consumo de recursos. La reducción de la sobrecarga significa que containerd utiliza menos memoria y CPU, lo que resulta significativo a gran escala.

Kubernetes integration

Hablando de Kubernetes, la relación entre los tiempos de ejecución de contenedores y las plataformas de orquestación ha evolucionado significativamente, especialmente en lo que respecta a cómo Kubernetes se conecta a containerd.

La relación entre Kubernetes y los tiempos de ejecución de contenedores sufrió un cambio importante con Kubernetes 1.24, lanzado en 2022. Esta versión eliminó «Dockershim», una capa de compatibilidad que permitía a Kubernetes utilizar Docker como su tiempo de ejecución de contenedores.

Dockershim siempre se concibió como un puente temporal. Cuando Kubernetes introdujo la interfaz de tiempo de ejecución de contenedores (CRI) para estandarizar la comunicación con los tiempos de ejecución, Docker no pudo implementarla directamente porque Docker era anterior al diseño de CRI. Dockershim traducía entre Kubernetes y Docker, añadiendo una capa de traducción que, en última instancia, resultaba innecesaria.

Las versiones modernas de Kubernetes se comunican directamente con containerd a través de CRI, lo que elimina por completo la capa de traducción de Docker. Esta simplificación aporta beneficios concretos:

• Latencia reducida: La comunicación directa elimina los gastos generales de traducción en las operaciones con contenedores.
• Estabilidad mejorada: Menos piezas móviles significa menos puntos potenciales de fallo.
• Mejor rendimiento: La pila de tiempo de ejecución optimizada beneficia especialmente a las implementaciones a gran escala.
• Depuración simplificada: La integración directa de CRI facilita la resolución de problemas.

Para los usuarios de Kubernetes, este cambio es prácticamente imperceptible. Las imágenes de Docker siguen siendo totalmente compatibles porque cumplen con los estándares OCI. El impacto práctico es que los clústeres de Kubernetes de producción ahora funcionan de manera más eficiente al utilizar containerd directamente, mientras que los programadores pueden seguir utilizando Docker localmente para crear y realizar pruebas.

Si no estás seguro de las ventajas y desventajas de usar Kubernetes, consulta esta comparación entre Docker Compose y Kubernetes.

Creación y gestión de imagen

Si bien la integración en tiempo de ejecución es fundamental para la orquestación, el flujo de trabajo de los programadores depende en gran medida de cómo cada herramienta gestiona la creación y el almacenamiento de imágenes. La creación de imágenes representa una diferencia significativa en cuanto a capacidades entre Docker y containerd. 

Docker proporciona un sistema de compilación integrado a través de Dockerfiles y BuildKit, lo que permite a los programadores crear compilaciones complejas de varias etapas con almacenamiento en caché, paralelización y funciones avanzadas como secretos de compilación y reenvío de agentes SSH.

Containerd, por diseño, no incluye ningún flujo de trabajo nativo para la creación de imágenes. Para crear imágenes con containerd, los programadores deben utilizar herramientas externas. Las opciones incluyen ejecutar BuildKit como un demonio independiente y utilizar buildctl para compilaciones desde la línea de comandos, o adoptar nerdctl, una CLI compatible con Docker que integra BuildKit.

Los mecanismos de almacenamiento también difieren en cuanto a su filosofía. La gestión de volúmenes de Docker proporciona una abstracción que resulta natural para los programadores, con volúmenes con nombre que conservan los datos independientemente del ciclo de vida de los contenedores. Containerd utiliza un sistema de instantáneas de nivel más bajo, en el que se pueden conectar diferentes controladores de instantáneas para gestionar los sistemas de archivos en capas de forma diferente en función de los requisitos de almacenamiento subyacentes.

Esta diferencia refleja el público al que están dirigidas las herramientas: 

• Docker optimiza la productividad de los programadores con funciones integradas que facilitan el trabajo.
• Containerd proporciona primitivas flexibles que los creadores de plataformas pueden ensamblar según sus necesidades específicas.

CLI, experiencia de programador y nerdctl

Más allá de la arquitectura y las características, la experiencia diaria de los programadores está determinada directamente por la interfaz de línea de comandos que ofrece cada herramienta. La experiencia de la línea de comandos revela con mayor claridad las diferentes filosofías de diseño. 

La CLI de Docker es conocida por su facilidad de uso. Comandos como docker run, docker build y docker logs son intuitivos, están bien documentados y están diseñados para personas. La CLI incluye valores predeterminados útiles, mensajes de error claros y amplias opciones que cubren la mayoría de los casos de uso.

Containerd incluye ctr, una interfaz de línea de comandos mínima destinada exclusivamente a la depuración y prueba de funciones de bajo nivel de containerd. La herramienta ctr es deliberadamente poco intuitiva para los programadores. Carece de características comunes como abreviaturas de mapeo de puertos, políticas de reinicio automático e integración con ayudantes de credenciales. Está diseñado para programadores de contenedores, no para programadores de aplicaciones.

Acortando distancias con nerdctl

Esta brecha de usabilidad llevó a la creación de nerdctl, una CLI compatible con Docker para containerd. Usar nerdctl es idéntico a usar Docker: la misma sintaxis de comandos, los mismos indicadores, el mismo flujo de trabajo, pero con containerd como tiempo de ejecución subyacente. Esto convierte a nerdctl en un excelente puente para los equipos que están pasando de Docker a containerd en entornos de desarrollo.

En la práctica, los programadores rara vez interactúan directamente con containerd. Cuando lo necesitan, nerdctl proporciona la interfaz familiar que esperáis, mientras que los operadores y administradores de plataformas utilizan las API de containerd de forma programática a través de sistemas de orquestación como Kubernetes.

Para ilustrar las diferencias en la práctica, a continuación se comparan las operaciones comunes con contenedores en las tres herramientas CLI:

Nota: ctr carece de mapeo de puertos (-p) y requiere una red de host (--net-host) para exponer los servicios. Tampoco extrae imágenes automáticamente.

Resumen de las diferencias clave

Antes de entrar en las recomendaciones para casos de uso específicos, recapitulemos las diferencias que hemos visto hasta ahora. La siguiente tabla resume las principales diferencias funcionales entre Docker y containerd, destacando sus capacidades distintivas y sus públicos objetivo:

¿Por qué elegir Docker?

Ahora que ya hemos visto las diferencias técnicas, veamos algunos casos prácticos en los que cada herramienta destaca. A pesar del auge de containerd en entornos de producción, Docker sigue siendo la mejor opción para situaciones específicas en las que la experiencia de los programadores y las herramientas completas son lo más importante.

Para el desarrollo local y la creación de prototipos

Docker destaca cuando necesitas una solución «todo en uno» para escribir y probar código. La cadena de herramientas integrada permite a los programadores pasar de cero a ejecutar contenedores en cuestión de minutos, sin necesidad de ensamblar múltiples componentes ni configurar redes complejas.

El ecosistema Docker ofrece enormes ventajas en términos de productividad:

• Docker Hub: Millones de imágenes listas para usar para bases de datos, colas de mensajes y servidores web.
• Docker Compose: Define aplicaciones multicontenedor en un único archivo YAML y activa entornos de desarrollo completos con un solo comando.
• Interfaz gráfica de usuario de Docker Desktop: Gestión visual de contenedores, exploración de volúmenes, ajustes de límites de recursos y compatibilidad integrada con Kubernetes.
• Menor barrera de entrada: Las herramientas gráficas y los comandos intuitivos hacen que los contenedores sean accesibles para los programadores que recién se inician en esta tecnología.

Para los equipos que utilizan Docker Desktop, la interfaz gráfica de usuario ofrece comodidades adicionales que aceleran considerablemente la incorporación y los flujos de trabajo diarios.

Para procesos de compilación complejos

Más allá del desarrollo, las capacidades de compilación de Docker lo convierten en la opción natural para flujos de trabajo sofisticados de integración y despliegue continuos.

El BuildKit integrado de Docker proporciona funciones avanzadas esenciales para los modernos procesos de CI/CD. Las compilaciones en varias etapas minimizan el tamaño de las imágenes y mantienen la legibilidad de los archivos Dockerfile. Los mecanismos de almacenamiento en caché de BuildKit reutilizan de forma inteligente las capas entre compilaciones, lo que reduce drásticamente los tiempos de compilación en entornos de integración continua.

La mayoría de las plataformas de automatización, como GitHub Actions, GitLab CI, Jenkins y otras, cuentan con integraciones Docker maduras y probadas en la práctica. Estas integraciones gestionan la autenticación, el almacenamiento en caché y la publicación de imágenes sin ningún tipo de fricción. 

Aunque otras herramientas pueden lograr resultados similares, la ubicuidad de Docker significa que las soluciones y la ayuda para la resolución de problemas están fácilmente disponibles, lo cual es otra gran ventaja.

¿Por qué elegir Containerd?

Containerd destaca en entornos de producción en los que el minimalismo, el rendimiento y la estabilidad prevalecen sobre la comodidad de las herramientas integradas.

Para clústeres de Kubernetes de producción

El uso de containerd como tiempo de ejecución para los nodos de Kubernetes aporta ventajas cuantificables:

• Reducción de los gastos generales: La eliminación del demonio de Docker supone un menor consumo de recursos por nodo y un ahorro significativo a gran escala.
• Estabilidad mejorada: Menos piezas móviles significa menos puntos potenciales de fallo en tu infraestructura.
• Superficie de ataque más pequeña: Menos código que auditar y menos vulnerabilidades de seguridad potenciales.
• Depuración simplificada: La integración directa de CRI elimina la capa de traducción de dockershim, lo que facilita la resolución de problemas.
• Mejor rendimiento: La pila de tiempo de ejecución optimizada mejora los tiempos de inicio y la capacidad de respuesta de los contenedores.

El estatus de graduación de Containerd en la CNCF es señal de tu madurez y fiabilidad. Los principales proveedores de servicios en la nube, entre ellos AWS, Google Cloud y Azure, han estandarizado containerd para sus ofertas gestionadas de Kubernetes, lo que demuestra su confianza en la preparación para la producción de esta tecnología en infraestructuras críticas.

Para entornos especializados y minimalistas

Aunque Kubernetes es el caso de uso más habitual en producción, la naturaleza ligera de containerd abre la puerta a escenarios de implementación en los que Docker resultaría poco práctico.

La computación periférica y los dispositivos IoT suelen funcionar con graves limitaciones de recursos. El diseño ligero de Containerd lo hace viable en estos entornos, donde la pila completa de Docker sería prohibitiva. Cada megabyte de memoria y cada ciclo de CPU son importantes cuando se ejecuta en hardware integrado.

Los escenarios de seguridad avanzados se benefician de la arquitectura modular de tiempo de ejecución de containerd. Las organizaciones pueden integrar entornos de ejecución aislados para cargas de trabajo que requieran límites de seguridad adicionales. Algunos ejemplos son:

• gVisor: proporciona un fuerte aislamiento del núcleo.
• Kata Containers: ejecuta contenedores en máquinas virtuales ligeras.

Estas integraciones se conectan a containerd sin necesidad de modificaciones importantes.

Migración de Docker a Containerd

Es importante saber cuándo utilizar cada herramienta, pero saber cómo pasar de una a otra es igualmente crucial. La transición de Docker a containerd en entornos existentes requiere una planificación cuidadosa, pero el proceso está bien documentado y es sencillo.

Migración de nodos de Kubernetes

Los pasos operativos para migrar nodos Kubernetes de Docker a containerd siguen un patrón estándar:

1. Cordón el nodo: Evita que se programen nuevos pods (kubectl cordon )

2. Vaciar las cápsulas existentes: Migrar cargas de trabajo a otros nodos (kubectl drain )

3. Actualiza la configuración de Kubelet: Apunta al socket CRI de containerd en /run/containerd/containerd.sock

4. Verificar los complementos CNI: Asegúrate de que containerd tiene instalados los complementos de red necesarios.

5. Reinicia Kubelet: Regístrate con el nuevo tiempo de ejecución y vuelve a unirte al clúster.

Probar primero la migración en nodos que no sean de producción ayuda a identificar problemas específicos del entorno antes de implementar cambios en todo el clúster. Para evitar errores comunes, asegúrate de seguir las siguientes prácticas recomendadas:

• Cambios en la ruta del registro: Docker y containerd utilizan diferentes ubicaciones de registro predeterminadas, por lo que debes actualizar tu infraestructura de registro en consecuencia.
• Instala los complementos CNI que faltan: Containerd requiere binarios de complementos CNI para la red; estos no siempre se instalan de forma predeterminada.
• Ten cuidado con las diferencias en la obtención de imágenes: Es posible que sea necesario ajustar las configuraciones de autenticación y registro.
• Ten cuidado con las incompatibilidades entre controladores de almacenamiento: Asegúrate de que tus volúmenes persistentes sean compatibles con el snapshotter de containerd.

Navegando por las diferencias de la CLI

Una vez migrada la infraestructura, los programadores deben adaptar vuestros flujos de trabajo diarios para trabajar con el nuevo tiempo de ejecución.

Para los programadores acostumbrados a los comandos de Docker, nerdctl ofrece una experiencia casi idéntica. Los comandos como nerdctl run, nerdctl build y nerdctl compose up funcionan exactamente igual que sus equivalentes en Docker, lo que facilita la transición.

Para la depuración, es esencial comprender cómo asignar los flujos de trabajo de depuración de Docker a containerd. Si bien puedes utilizar docker inspect para examinar un contenedor, ctr containers info proporciona información similar, aunque en un formato diferente. Del mismo modo, ctr tasks list muestra los contenedores en ejecución.

La mayoría de los programadores consideran que nerdctl elimina la necesidad de aprender la sintaxis de ctr para las tareas cotidianas. ctr, de bajo nivel, sigue siendo útil para solucionar problemas específicos del tiempo de ejecución o cuando se trabaja directamente con las API de containerd.

Conclusión

La relación entre Docker y containerd es un ejemplo perfecto de diseño modular exitoso en infraestructura de software. Docker sigue siendo la herramienta óptima para las personas que escriben código, ya que ofrece una experiencia integrada, un ecosistema completo e interfaces fáciles de usar para los programadores que hacen que la creación de aplicaciones en contenedores sea productiva (y agradable).

Por su parte, Containerd destaca como entorno de ejecución para máquinas que ejecutan código,ya que ofrece la estabilidad, el rendimiento y el minimalismo necesarios para las plataformas de orquestación de producción. El hecho de que Docker Engine utilice containerd en segundo plano demuestra cómo ambas herramientas se complementan entre sí en lugar de competir entre ellas.

Recomiendo un enfoque pragmático para la mayoría de las organizaciones: seguir utilizando Docker en los portátiles de los programadores, donde sus herramientas aceleran los flujos de trabajo de desarrollo, pero considerar la posibilidad de migrar los clústeres de Kubernetes de producción directamente a containerd para obtener las ventajas operativas de una reducción de los gastos generales y una simplificación de las pilas de tiempo de ejecución.

Tanto si eliges la plataforma integral de Docker como el tiempo de ejecución específico de containerd, ambos siguen siendo componentes esenciales del ecosistema de contenedores moderno, cada uno optimizado para diferentes etapas del ciclo de vida de las aplicaciones.

Para seguir aprendiendo, asegúrate de inscribirte en nuestro programa de formación sobre contenedorización y virtualización con Docker y Kubernetes.