Contenedorización 2025: Por qué containerd 2.0 y eBPF lo Cambian Todo

El panorama de la contenedorización, perennemente dinámico, ha visto una oleada de avances prácticos y sólidos a finales de 2024 y a lo largo de 2025. Como desarrolladores senior, hemos superado el "ciclo de la exageración" y estamos en las trincheras, evaluando características que ofrecen beneficios operativos tangibles y abordan limitaciones del mundo real. El año pasado ha consolidado varias tendencias: un impulso implacable hacia una mayor seguridad en toda la cadena de suministro, mejoras fundamentales en la eficiencia en tiempo de ejecución, un salto significativo en la ergonomía de la construcción para implementaciones multiarquitectura y la emergencia de WebAssembly como una alternativa creíble, aunque incipiente, para cargas de trabajo específicas. Aquí tienes un análisis profundo de los desarrollos que realmente importan.

La Nueva Base: containerd 2.0 y eBPF

containerd 2.0: La Base CRI Reforzada

La base de nuestro mundo contenedorizado, el entorno de ejecución de contenedores, ha experimentado una evolución significativa, sobre todo con el lanzamiento de containerd 2.0 a finales de 2024. Esto no es simplemente una actualización incremental; es una estabilización estratégica y una mejora de las capacidades centrales siete años después de su lanzamiento 1.0. El cambio de dockershim en Kubernetes v1.24 impulsó a containerd y CRI-O a la vanguardia, al igual que las herramientas CLI modernas están redefiniendo la experiencia del desarrollador en 2025.

containerd 2.0 aporta varias características clave al canal estable que merecen una atención especial. La Node Resource Interface (NRI) ahora está habilitada por defecto, proporcionando un potente mecanismo de extensión para personalizar las configuraciones de contenedores de bajo nivel. Esto permite un control más granular sobre la asignación de recursos y la aplicación de políticas, similar a los webhooks de admisión mutantes, pero operando directamente a nivel de tiempo de ejecución. Los desarrolladores pueden aprovechar los plugins NRI para inyectar configuraciones específicas en tiempo de ejecución o aplicar políticas de gestión de recursos personalizadas dinámicamente, una capacidad que antes era más engorrosa de implementar sin modificaciones directas del tiempo de ejecución.

Además, containerd 2.0 ahora es compatible con los Image Verifier Plugins. Esto es genuinamente impresionante porque permite la aplicación de políticas sobre las imágenes en el momento de la extracción de la imagen. Piénsalo: en lugar de escanear las imágenes solo durante CI/CD o en el despliegue, ahora puedes tener containerd invocando un plugin externo (que puede ser cualquier binario ejecutable o script) para validar la integridad o el cumplimiento de una imagen antes de que se extraiga y ejecute por completo. Esto se integra directamente con el transfer service (estabilizado en 2.0), aunque se señala que el plugin CRI aún no está completamente integrado, por lo que su impacto inmediato en las implementaciones de Kubernetes podría ser limitado hasta que eso se concrete. Aún así, para los usuarios directos de containerd, este es un paso robusto hacia la seguridad de la cadena de suministro en el límite del tiempo de ejecución. En el frente de la seguridad, containerd v2.2.0 también incluye correcciones para vulnerabilidades críticas como CVE-2024-25621 y CVE-2025-64329, junto con runc v1.3.3 que aborda CVE-2025-31133, CVE-2025-52565 y CVE-2025-52881, lo que demuestra un esfuerzo continuo para fortalecer los componentes centrales.

La Ascensión de eBPF: Control a Nivel de Kernel para Networking y Observabilidad

He estado esperando que eBPF realmente despegue en el ecosistema de contenedores, y desde finales de 2024 hasta 2025 lo ha logrado. La integración de eBPF (extended Berkeley Packet Filter) en las pilas de networking y observabilidad de Kubernetes ha pasado de ser una curiosidad experimental a una tecnología fundamental. eBPF permite que los programas en sandbox se ejecuten directamente dentro del kernel de Linux, activados por varios eventos, ofreciendo un rendimiento y una flexibilidad sin precedentes sin la sobrecarga de los cambios de contexto tradicionales entre kernel y espacio de usuario.

Para networking, los plugins de Container Network Interface (CNI) basados en eBPF como Cilium y Calico están reemplazando activamente o ofreciendo alternativas superiores a los enfoques basados en iptables. La ventaja principal radica en el procesamiento eficiente de paquetes. En lugar de atravesar complejas cadenas iptables para cada paquete, los programas eBPF pueden tomar decisiones de enrutamiento y políticas directamente en un punto anterior de la pila de red del kernel. Esto reduce drásticamente la sobrecarga de la CPU y la latencia, especialmente en los clústeres de Kubernetes a gran escala. Proyectos como Cilium han avanzado el networking de contenedores, reemplazando iptables con datapath eficientes basados en eBPF, y su estado graduado con CNCF y su inclusión en proyectos como OpenTelemetry lo convierten en un estándar de facto para el manejo de políticas de red.

Más allá del rendimiento, eBPF mejora profundamente la observabilidad. Al adjuntar programas eBPF a llamadas al sistema, eventos de red y actividades de procesos, los desarrolladores pueden capturar datos de telemetría detallados directamente desde el kernel en tiempo real. Esto proporciona una visibilidad granular del comportamiento del contenedor, los flujos de red y las llamadas al sistema sin requerir proxies laterales intrusivos o instrumentación de la aplicación. Por ejemplo, un programa eBPF puede monitorear todas las conexiones de red iniciadas por un contenedor específico, detectar patrones de acceso a archivos inusuales o rastrear llamadas al sistema, ofreciendo una poderosa herramienta tanto para la depuración del rendimiento como para la detección de amenazas de seguridad en tiempo real.

Modernizando el Flujo de Trabajo de Construcción y Desarrollo

BuildKit 2.0 & Docker Build Cloud: Construcciones Más Inteligentes, Más Rápidas y Más Seguras

Si todavía estás tratando docker build como una caja negra, te estás perdiendo algo. BuildKit ha sido el constructor predeterminado en Docker Engine desde la versión 23.0, y BuildKit 2.0, junto con Docker Build Cloud, representa un salto significativo en la forma en que construimos imágenes de contenedores. BuildKit 2.0 no se trata solo de velocidad; es un cambio de paradigma hacia pipelines de construcción más seguros, portátiles e inteligentemente optimizados.

Una de las características destacadas de BuildKit 2.0 es el Federated Caching. El almacenamiento en caché basado en registros (--cache-from) siempre ha sido un poco lento e intensivo en red. Federated Caching, sin embargo, introduce un mecanismo de almacenamiento en caché entre pares, lo que permite que tus agentes de construcción formen un clúster de caché distribuido. Cuando un agente construye una capa, puede estar disponible instantáneamente para otros en la misma red sin un viaje de ida y vuelta a un registro remoto. Esto reduce drásticamente los tiempos de construcción para los equipos, especialmente en arquitecturas de microservicios donde las imágenes base se reconstruyen con frecuencia, transformando un descanso para el café en una actualización rápida.

Igualmente emocionante es la introducción de los Native WASM Build Steps. Los comandos RUN complejos que involucran curl, tar y sed son notorios por crear construcciones inestables e inseguras. BuildKit 2.0 aborda esto permitiendo que los módulos WebAssembly (WASM) se utilicen como pasos de construcción nativos. En lugar de encadenar comandos de shell, puedes usar un binario WASM precompilado y en sandbox para realizar tareas como buscar activos, generar código o realizar linting. Esto ofrece ejecución en sandbox y portabilidad mejorada, lo que hace que tus construcciones sean más confiables y seguras. Además, BuildKit 2.0 se integra profundamente con las prácticas de seguridad modernas, generando automáticamente atestaciones SLSA y firmando imágenes usando Sigstore/Cosign como parte nativa del proceso de construcción.

Complementando a BuildKit 2.0, Docker Build Cloud, lanzado en enero de 2024, tiene como objetivo acelerar las construcciones descargándolas a la nube. Este servicio aprovecha la computación en la nube y la caché para lograr tiempos de construcción hasta 39 veces más rápidos que las construcciones locales. Cuenta con soporte nativo para construcciones multiarquitectura (AMD64, ARM64) eliminando la necesidad de emulación lenta o el mantenimiento de varios constructores nativos. El comando docker buildx build --platform linux/amd64,linux/arm64 -t myregistry/my-app:latest --push . hace que la construcción para múltiples arquitecturas sea perfecta.

Docker Compose v5: Elevando los Flujos de Trabajo de Desarrollo Local

Docker Compose siempre ha sido el caballo de batalla para el desarrollo multi-contenedor local, pero la evolución reciente, culminando en Compose v5 en diciembre de 2025, lo ha convertido en una herramienta aún más potente e integrada. El cambio estructural más significativo ha sido la integración completa de docker compose (la implementación basada en Go) directamente en la CLI de Docker, deprecando oficialmente el docker-compose más antiguo basado en Python (con un guión).

Una de las características que he estado esperando es docker compose watch. Este comando rastrea archivos y actualiza automáticamente los contenedores en ejecución en el momento en que se guarda un archivo, eliminando la necesidad de ciclos manuales de docker compose up o restart. Para un desarrollador de aplicaciones web, esto significa un ciclo de retroalimentación ajustado: escribir-guardar-ver sucede en segundos, perfecto para iterar en puntos finales de API o vistas previas front-end en vivo. Puedes habilitarlo con una simple etiqueta en tu compose.yml:

services:
  web:
    build: .
    ports:
      - "80:80"
    labels:
      com.docker.compose.watch: "true" # Habilita el modo de observación para este servicio

Otras mejoras notables de la CLI incluyen docker compose attach para la depuración, docker compose stats para el monitoreo de uso de recursos en vivo y docker compose cp para copiar fácilmente archivos entre el host y un contenedor de servicio. El campo version en docker-compose.yml ahora está completamente obsoleto; los archivos Compose modernos deben omitirlo, comenzando directamente con el bloque services:. Compose v5 también introduce un nuevo SDK oficial de Go, que proporciona una API completa para integrar la funcionalidad de Compose directamente en las aplicaciones.

IA/ML y la Evolución de Docker Desktop

El Giro de Docker Desktop hacia la IA/ML: Más Allá de la Contenedorización Pura

Docker Desktop continúa evolucionando como una estación de trabajo de desarrollador completa, y sus características en 2025 muestran un giro distinto hacia el soporte de flujos de trabajo de desarrollo de IA/ML. Más allá de su función principal de proporcionar un Docker Engine y un clúster de Kubernetes locales, Docker Desktop ahora está integrando herramientas que abordan directamente los puntos débiles de los desarrolladores de IA.

La característica Model Runner, por ejemplo, tiene como objetivo simplificar la ejecución local de LLM. Ejecutar modelos de IA localmente a menudo implica lidiar con entornos Python, instalaciones de CUDA, formatos de modelo específicos y dependencias complejas. Docker's Model Runner abstrae gran parte de esta complejidad, lo que permite a los desarrolladores extraer y ejecutar modelos con un simple comando docker model pull ai/llama3.2:1B-Q8_0 (a partir de Docker Desktop 4.40+). Esto es genuinamente impresionante porque reduce la barrera de entrada para experimentar con modelos de lenguaje grandes y otras aplicaciones de IA, proporcionando un entorno contenedorizado consistente para la ejecución de modelos.

Para las cargas de trabajo que superan los recursos de la máquina local, Docker Offload proporciona una forma perfecta de ejecutar modelos y contenedores en GPU en la nube. Esto libera a los desarrolladores de las limitaciones de la infraestructura al descargar tareas que consumen muchos recursos, como modelos de lenguaje grandes y la orquestación de agentes múltiples, a entornos en la nube de alto rendimiento. Además, el MCP Toolkit (para el desarrollo de agentes de IA) y Docker Debug (para una solución de problemas mejorada con contenedores de depuración delgados) completan las capacidades ampliadas de Docker Desktop, lo que lo convierte en una herramienta más versátil para el desarrollo moderno e intensivo en recursos.

Fortaleciendo la Cadena de Suministro y la Privacidad de los Datos

Seguridad Avanzada de Imágenes y Imágenes Reforzadas

La creciente dependencia de los componentes de código abierto significa que las imágenes de contenedores son un punto de control principal para la seguridad de la cadena de suministro de software, y Docker ha mejorado significativamente su juego en 2024-2025. Más del 90% de las aplicaciones modernas dependen del código abierto, y las imágenes de contenedores pueden incluir cientos de dependencias, lo que convierte a la capa de la imagen en una de las superficies de ataque más grandes y menos visibles.

Docker Scout (anteriormente Docker Scan) es ahora una pieza central de esta estrategia, ofreciendo análisis continuo de vulnerabilidades para repositorios ilimitados habilitados para Scout dentro de los planes Docker Team y Business. Proporciona información en tiempo real sobre el riesgo de la imagen y las remediaciones recomendadas, integrándose perfectamente con la CLI de Docker y las pipelines de CI/CD. Este enfoque de "desplazamiento a la izquierda" es crucial, lo que permite a los desarrolladores identificar y abordar las vulnerabilidades en las primeras etapas del ciclo de desarrollo, evitando que las imágenes inseguras lleguen a la producción.

Un desarrollo particularmente impactante es la decisión de Docker de hacer que las Docker Hardened Images sean gratuitas para todos. Estas imágenes proporcionan una base segura por defecto, reduciendo la fricción entre la velocidad de desarrollo y la seguridad. Vienen con soporte de ciclo de vida extendido, lo que ayuda a las empresas a mantenerse en cumplimiento y mitigar los riesgos de fin de vida útil. Este movimiento señala el compromiso de Docker de establecer un nuevo estándar para todo el ecosistema de contenedores, haciendo de la seguridad una expectativa básica en lugar de una característica premium.

Contenedores Confidenciales: Aportando Confianza a Entornos No Confiables

Para las cargas de trabajo altamente sensibles, el concepto de Contenedores Confidenciales (CoCo) ha madurado significativamente, pasando de la investigación de nicho a las implementaciones prácticas. CoCo es un proyecto sandbox de la CNCF que tiene como objetivo habilitar la computación confidencial nativa de la nube aprovechando los Entornos de Ejecución Confiables (TEEs) para proteger los contenedores y los datos. Esto es un cambio de juego para la privacidad de los datos, especialmente en industrias reguladas o para el procesamiento de información de identificación personal (PII).

La idea central es crear enclaves seguros dentro de un procesador, que protejan los datos que se están procesando del entorno circundante, incluido el CPU, el hipervisor e incluso los administradores de la nube. Las tecnologías como Intel SGX, Intel TDX y AMD SEV forman la base del hardware, cifrando la memoria del contenedor y evitando que los datos en la memoria estén en texto plano. Este enfoque de "caja negra" garantiza que los flujos de trabajo confidenciales estén protegidos contra el acceso no autorizado.

El objetivo del proyecto CoCo es estandarizar la computación confidencial a nivel de contenedor y simplificar su consumo en Kubernetes. Esto significa que los usuarios de Kubernetes pueden implementar cargas de trabajo de contenedores confidenciales utilizando flujos de trabajo y herramientas familiares, sin necesidad de un conocimiento extenso de las tecnologías subyacentes de computación confidencial. Si bien todavía está en vista previa para algunos proveedores de la nube y conlleva una sobrecarga de rendimiento inherente debido al aislamiento adicional, la capacidad de lograr un nuevo nivel de confidencialidad e integridad de los datos al evitar que los datos en la memoria sean legibles es un avance poderoso.

La Realidad de Wasm y el Camino a Seguir

El Matiz de Wasm: Un Cuento de Dos Implementaciones

WebAssembly (Wasm) en el ecosistema de contenedores presenta una dualidad interesante. Por un lado, la introducción de Native WASM Build Steps de BuildKit 2.0 es un desarrollo convincente para mejorar la seguridad y la portabilidad de la construcción. Aquí, los módulos Wasm se utilizan dentro del proceso de construcción para ejecutar tareas específicas, ofreciendo una alternativa en sandbox y eficiente a los scripts de shell tradicionales. Este es un avance práctico y sólido que aborda problemas reales de confiabilidad y seguridad de la construcción.

Sin embargo, la historia de Wasm como entorno de ejecución de contenedor directo dentro de Docker Desktop parece tomar un rumbo diferente. Las notas de la versión de Docker Desktop 4.55.0 de diciembre de 2025 indican explícitamente que las cargas de trabajo de Wasm serán obsoletas y eliminadas en una futura versión de Docker Desktop. Esta es una realidad crucial. Si bien runwasi existe como un proyecto no central de containerd para un shim WASM, la decisión de Docker para Desktop sugiere que la ejecución directa de Wasm en tiempo de ejecución podría no haber cumplido con la adopción o la viabilidad técnica esperada para los flujos de trabajo generales de los desarrolladores dentro de su producto de escritorio.

Conclusión: El Camino a Seguir

¡Qué año ha sido! Los avances en Docker, containerd y Kubernetes a finales de 2024 y a lo largo de 2025 son nada menos que impresionantes. Hemos visto que containerd 2.0 consolida su papel como la base robusta y extensible para los entornos de ejecución de contenedores, ofreciendo nuevos ganchos potentes como NRI y los plugins de verificación de imágenes. La ascensión de eBPF ha transformado fundamentalmente nuestra forma de pensar sobre el networking de contenedores, la observabilidad y la seguridad, impulsando la eficiencia a nivel de kernel y la visibilidad a la corriente principal.

Para los desarrolladores, Docker Compose v5 y las nuevas características de Docker Desktop centradas en la IA/ML como Model Runner y Docker Offload demuestran un compromiso de agilizar los flujos de trabajo más allá de la simple gestión de contenedores, adoptando las tendencias emergentes. Y quizás lo más crítico, el enfoque implacable en la seguridad de la cadena de suministro, ejemplificado por el análisis continuo de Docker Scout y la disponibilidad de Docker Hardened Images gratuitas, está estableciendo un estándar más alto de confianza en nuestros artefactos de software. Si bien algunas características, como la ejecución directa de Wasm en Docker Desktop, enfrentan una reevaluación, la trayectoria general es clara: los contenedores se están volviendo más seguros, más eficientes y más integrados en los paradigmas de desarrollo avanzados de hoy y del mañana.