Contenedorización 2025: Por qué containerd 2.0 y eBPF están cambiando todo

El panorama de la contenedorización, perpetuamente 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 bombo" 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í hay un análisis profundo de los desarrollos que realmente importan.

El panorama en evolución del tiempo de ejecución de contenedores: containerd 2.0 y más allá

La base de nuestro mundo contenedorizado, el tiempo 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, consolidando la Interfaz de tiempo de ejecución de contenedores (CRI) como el protocolo de interacción estándar entre el kubelet y el tiempo de ejecución subyacente.

containerd 2.0 trae varias características clave al canal estable que merecen una atención cercana. La Interfaz de recursos de nodo (NRI) ahora está habilitada por defecto, proporcionando un poderoso 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 de tiempo de ejecución específicas 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. Considera un escenario en el que una organización necesita aplicar un anclaje de CPU específico o una asignación de páginas de memoria para cargas de trabajo críticas para el rendimiento; un plugin NRI ahora puede mediar esto al inicio del contenedor, asegurando una aplicación consistente en diversos tipos de nodos sin alterar el daemon containerd central.

Otro avance notable es la estabilización de los plugins de verificación de imágenes. Si bien el plugin CRI en containerd 2.0 aún no se integra completamente con el nuevo servicio de transferencia para la extracción de imágenes, y por lo tanto no está disponible inmediatamente para las cargas de trabajo de Kubernetes, su presencia señala un futuro sólido para la aplicación de políticas de imágenes en tiempo de extracción. Estos plugins son programas ejecutables que containerd puede invocar para determinar si se permite extraer una imagen, ofreciendo un punto de control crítico para la seguridad de la cadena de suministro. Una vez integrado con el CRI, esto permitirá a los administradores de Kubernetes definir políticas granulares, por ejemplo, permitiendo solo imágenes firmadas por claves específicas o aquellas con una Lista de materiales de software (SBOM) verificada, directamente a nivel del nodo, antes de que un contenedor siquiera intente iniciarse. Esto desplaza la aplicación de políticas hacia la izquierda, evitando que las imágenes potencialmente comprometidas lleguen a un nodo.

La configuración de containerd también ha visto una actualización, pasando a v3. Migrar las configuraciones existentes es un proceso sencillo utilizando containerd config migrate. Si bien la mayoría de la configuración permanece compatible, los usuarios que utilicen el snapshotter aufs obsoleto deberán pasar a una alternativa moderna. Esto fuerza una limpieza necesaria, promoviendo backends de almacenamiento más eficientes y mantenidos.

Reforzando la cadena de suministro de software: El ascenso de Sigstore

El año 2025 marca un punto de inflexión definitivo en la firma de imágenes de contenedores, con Sigstore estableciéndose firmemente como el estándar abierto para la seguridad de la cadena de suministro de software. Docker, reconociendo el panorama en evolución y la adopción limitada de su Docker Content Trust (DCT) heredado, comenzó a retirar formalmente DCT (que se basaba en Notary v1) en agosto de 2025. Este movimiento, aunque requiere migración para un pequeño subconjunto de usuarios, allana el camino para un enfoque más unificado y robusto para el linaje de imágenes.

Sigstore aborda la necesidad crítica de una integridad verificable de la cadena de suministro a través de un conjunto de herramientas: Cosign para firmar y verificar artefactos OCI, Fulcio como una Autoridad de Certificación raíz pública y gratuita que emite certificados de corta duración y Rekor como un registro de transparencia para todos los eventos de firma. Esta tríada permite la firma "sin clave", un cambio de paradigma significativo. En lugar de administrar claves estáticas de larga duración, los desarrolladores utilizan tokens OIDC de su proveedor de identidad (por ejemplo, GitHub, Google) para obtener certificados de firma efímeros de Fulcio. Cosign luego usa este certificado para firmar la imagen, y la firma, junto con el certificado, se registra en el registro de transparencia inmutable Rekor.

Por ejemplo, firmar una imagen con Cosign es notablemente simplificado:

# Autenticarse con su proveedor OIDC
# cosign a menudo detectará esto automáticamente desde las variables de entorno.

# Firmar una imagen (sin clave)
cosign sign --yes <su-registro>/<su-imagen>:<etiqueta>

# Verificar una imagen
cosign verify <su-registro>/<su-imagen>:<etiqueta>

La bandera --yes en cosign sign omite las indicaciones interactivas, crucial para las canalizaciones de CI/CD. El paso de verificación, cosign verify, consulta Rekor para garantizar la autenticidad e integridad de la firma, vinculándola a una identidad verificable. Esto proporciona una procedencia sólida y auditable sin la sobrecarga operativa de la PKI tradicional.

Turboalimentando las compilaciones con Buildx y BuildKit

Buildx de Docker, impulsado por el backend BuildKit, ha madurado hasta convertirse en una herramienta indispensable para cualquier flujo de trabajo de desarrollo de contenedores serio, particularmente para compilaciones de imágenes multiplataforma y estrategias de almacenamiento en caché. El comando docker build tradicional, aunque funcional, a menudo sufre de cuellos de botella en el rendimiento y soporte limitado entre arquitecturas. BuildKit reestructura fundamentalmente el proceso de compilación utilizando un gráfico acíclico dirigido (DAG) para las operaciones de compilación, lo que permite la ejecución paralela de pasos independientes y mecanismos de almacenamiento en caché superiores.

La característica destacada, las compilaciones multiplataforma, ya no es una capacidad de nicho, sino una necesidad práctica en un mundo que se diversifica rápidamente en arquitecturas amd64, arm64 e incluso arm/v7. Buildx permite que un solo comando docker buildx build produzca una lista de manifiestos que contenga imágenes para múltiples plataformas de destino, eliminando la necesidad de entornos de compilación separados.

Considera este Dockerfile:

# Dockerfile
FROM --platform=$BUILDPLATFORM golang:1.21-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
ARG TARGETOS TARGETARCH
RUN CGO_ENABLED=0 GOOS=$TARGETOS GOARCH=$TARGETARCH go build -o /app/my-app ./cmd/server

FROM --platform=$BUILDPLATFORM alpine:3.18
COPY --from=builder /app/my-app /usr/local/bin/my-app
CMD ["/usr/local/bin/my-app"]

Para compilar para linux/amd64 y linux/arm64 y enviar a un registro:

docker buildx create --name multiarch-builder --use
docker buildx inspect --bootstrap
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t myregistry/my-app:latest \
  --push .

En términos de rendimiento, el almacenamiento en caché de BuildKit es superior. Más allá del almacenamiento en caché de capas local, Buildx admite el almacenamiento en caché del registro, donde las capas de compilación anteriores enviadas a un registro se pueden aprovechar para compilaciones posteriores, lo que reduce significativamente los tiempos de compilación para los proyectos actualizados con frecuencia. Esto es particularmente impactante en las canalizaciones de CI/CD donde los entornos de compilación a menudo son efímeros.

eBPF: Redefiniendo la red y la observabilidad de Kubernetes

La integración de eBPF (Extended Berkeley Packet Filter) en las pilas de red y observabilidad de Kubernetes ha pasado de una curiosidad experimental a una tecnología fundamental a finales de 2024 y 2025. 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 conmutadores de espacio de kernel a espacio de usuario tradicionales.

Para la red, los plugins CNI (Container Network Interface) 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 de iptables para cada paquete, los programas eBPF pueden tomar decisiones de enrutamiento y política 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.

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. Herramientas como Cilium Hubble aprovechan eBPF para monitorear los flujos de red en Kubernetes, proporcionando información profunda sobre la comunicación entre servicios, incluida la latencia, los bytes transferidos y las decisiones de aplicación de políticas.

WebAssembly: Un nuevo paradigma para las cargas de trabajo nativas de la nube

WebAssembly (Wasm), inicialmente concebido para el navegador, ha cruzado innegablemente el abismo hacia los entornos de servidor y nativos de la nube, presentando una alternativa convincente a los contenedores tradicionales para casos de uso específicos en 2025. Sus ventajas principales: tiempos de inicio increíblemente rápidos, huella mínima y seguridad de sandbox sólida, lo hacen particularmente atractivo para las funciones sin servidor y la computación perimetral. Como vemos en la evolución de Node.js, Deno, Bun en 2025, el panorama de tiempo de ejecución se está diversificando para satisfacer estas demandas de rendimiento.

Los módulos Wasm normalmente se inician en milisegundos, un marcado contraste con los segundos que a menudo se requieren para los inicios en frío de contenedores tradicionales. La integración de Wasm con Kubernetes se logra principalmente a través de tiempos de ejecución compatibles con CRI y shims. Proyectos como runwasi proporcionan un shim containerd que permite a Kubernetes programar módulos Wasm junto con los contenedores Linux tradicionales.

Por ejemplo, para ejecutar una aplicación Wasm con crun:

# runtimeclass.yaml
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: wasm-crun
handler: crun
---
# wasm-app.yaml
apiVersion: v1
kind: Pod
metadata:
  name: wasm-demo
  annotations:
    module.wasm.image/variant: compat
spec:
  runtimeClassName: wasm-crun
  containers:
  - name: my-wasm-app
    image: docker.io/myuser/my-wasm-app:latest
    command: ["/my-wasm-app"]

Evolución de la API de Kubernetes: Mantenerse a la vanguardia de las deprecaciones

Kubernetes refina constantemente su superficie de API para introducir nuevas capacidades y eliminar características obsoletas. A finales de 2024 y 2025, la vigilancia contra las deprecaciones y eliminaciones de API sigue siendo una tarea operativa crítica. El proyecto Kubernetes se adhiere a una política de depreciación bien definida en las API Alpha, Beta y GA.

Las implicaciones son claras: los desarrolladores deben monitorear activamente las advertencias de depreciación. Desde Kubernetes v1.19, cualquier solicitud a una API REST obsoleta devuelve una advertencia. Las herramientas automatizadas y las comprobaciones de la canalización de CI/CD son esenciales para identificar los recursos que utilizan las API obsoletas.

# Ejemplo: Buscar implementaciones que utilizan la API obsoleta extensions/v1beta1
kubectl get deployments.v1.apps -A -o custom-columns="NAMESPACE:.metadata.namespace,NAME:.metadata.name,APIVERSION:.apiVersion" | grep "extensions/v1beta1"

La planificación proactiva de la migración, mucho antes de una ventana de actualización, es el único enfoque sólido para mantener la estabilidad del clúster. Los lanzamientos Kubernetes v1.34 (agosto de 2025) y v1.31 (julio de 2024) incluyeron ambos deprecaciones y eliminaciones que requirieron atención.

Primitivas de seguridad de contenedores mejoradas: Más allá del escaneo de imágenes

Si bien el escaneo de vulnerabilidades sigue siendo una práctica fundamental, los desarrollos recientes se centran en fortalecer las primitivas de seguridad a nivel de tiempo de ejecución. Un avance significativo en containerd 2.0 es el soporte mejorado para Espacios de nombres de usuario. Esta característica permite que los contenedores se ejecuten como root dentro del contenedor, pero se asignen a un ID de usuario (UID) no privilegiado en el sistema host, lo que reduce drásticamente el radio de explosión de un escape de contenedor.

Más allá de los espacios de nombres de usuario, el énfasis en la infraestructura inmutable y el monitoreo en tiempo de ejecución se ha intensificado. Las soluciones de seguridad en tiempo de ejecución, a menudo aprovechando eBPF, proporcionan una visibilidad crucial del comportamiento del contenedor, detectando anomalías y violaciones de políticas en tiempo real. Además, el impulso hacia el privilegio mínimo se extiende a las capacidades del contenedor. Se anima a los desarrolladores a eliminar las capacidades de Linux innecesarias (por ejemplo, CAP_NET_ADMIN) y aplicar sistemas de archivos de solo lectura siempre que sea posible.

Experiencia del desarrollador y refinamientos de las herramientas

El refinamiento continuo de las herramientas de desarrollo, particularmente en torno a Docker Desktop y los entornos locales de Kubernetes, ha sido un tema persistente a lo largo de 2025. Estas mejoras se centran en mejorar la seguridad y simplificar los flujos de trabajo complejos para los millones de desarrolladores que confían en estas plataformas.

Docker Desktop ha visto una corriente constante de parches de seguridad que abordan vulnerabilidades críticas (por ejemplo, CVE-2025-9074). Para el desarrollo local de Kubernetes, las herramientas como kind y minikube continúan evolucionando, ofreciendo un aprovisionamiento de clúster más rápido. La integración de BuildKit y Buildx en los entornos locales ha mejorado significativamente la eficiencia de la construcción de imágenes, particularmente para aquellos que trabajan con objetivos de múltiples arquitecturas.

En esencia, la experiencia del desarrollador se ha vuelto más segura de forma predeterminada, con un énfasis en los procesos de compilación sólidos y el parcheo de seguridad continuo. Las herramientas están haciendo que los flujos de trabajo existentes sean más prácticos, seguros y eficientes, lo que para los desarrolladores senior suele ser el tipo de progreso más valioso.