containerd 2.0 en producción: migraciones reales

Actualizado: 2026-05-03

containerd 2.0 se publicó en noviembre de 2024 y hemos tenido seis meses para ver cómo se comporta en despliegues reales. La 1.7 sigue recibiendo soporte, pero la rama 1.6 entró en fin de soporte en marzo de 2025 y forzó a muchos equipos a plantear el salto. En este tiempo han aparecido suficientes informes para hacer una lectura honesta: qué se rompe, qué mejora y cuándo compensa planificar la migración.

Puntos clave

• El mayor motor para saltar es que la 1.6 ya no tiene soporte, no que la 2.0 traiga funcionalidades imprescindibles.
• CRI v1alpha2 se elimina: hay que actualizar kubelet a 1.26+ antes de migrar en clusters Kubernetes.
• El formato del archivo de configuración cambia: version = 3 en lugar de version = 2.
• Schema 1 de imágenes OCI se retira: imágenes construidas antes de 2017 pueden no ejecutarse.
• La migración en Docker Swarm es más suave que en Kubernetes porque Swarm no depende de CRI.
• Las métricas clave durante la migración son: contenedores activos, ratio de pull fallidos, latencia de la API de tasks y errores de shim.

Qué trae 2.0 que justifique la migración

Dejando a un lado la limpieza interna, cuatro cosas aportan valor operativo concreto:

• Soporte nativo de sandboxes. Kata Containers y Firecracker pueden integrarse como runtimes vía la API de sandbox sin necesidad de shims externos. Para equipos que evalúan aislamiento reforzado esto reduce el número de piezas móviles en el stack. Conecta directamente con lo que describimos en Firecracker: microVMs para servicios multi-tenant.
• CRI v1 estable y v1alpha2 retirado. Kubernetes 1.26 en adelante usa CRI v1 por defecto. containerd 2.0 elimina la implementación de v1alpha2, lo cual simplifica el código pero rompe compatibilidad con kubelet anteriores a 1.26.
• Mejoras en el runtime shim. El shim de runc se refactorizó y consume menos memoria por contenedor. En un host con cientos de contenedores el ahorro es perceptible: del orden de decenas de megabytes menos de overhead total.
• NRI como API de plugins estable. El Node Resource Interface, antes experimental, es ahora la interfaz oficial para integrar CNI custom, device plugins y agentes de seguridad.

Lo que se rompe al migrar

No es una actualización drop-in en la mayoría de casos. Hay al menos cinco puntos donde hay que tocar configuración o scripts:

1. Formato del archivo de configuración. La cláusula version = 2 deja de reconocerse; hay que declarar version = 3 en /etc/containerd/config.toml. Scripts de Ansible o Puppet que inyectan configuración deben ajustar la plantilla. containerd 2.0 convierte automáticamente la versión 2 pero emite aviso, y la 2.1 planea retirar la conversión automática.
2. Plugins desregistrados. Varios plugins del tipo io.containerd.grpc.v1.introspection cambiaron de namespace o nombre. Si hay integraciones externas que hacen introspección de plugins, hay que revisar.
3. Soporte de Schema 1 de imágenes OCI retirado. Imágenes viejas construidas antes de 2017 pueden ser Schema 1 y containerd 2.0 no las ejecuta. La mayoría de registros modernos convierten al hacer pull, pero si hay imágenes en registros privados antiguos hay que reempaquetarlas.
4. Comportamiento de ctr en contenedores compartidos entre namespaces. Algunos comandos que antes trabajaban silenciosamente across namespaces ahora piden el namespace explícito. Los scripts que usaban ctr sin --namespace fallan con errores claros, pero si esos scripts corren en cron o CI hay que adaptarlos.
5. Deprecación de CNI 0.x. containerd 2.0 requiere plugins CNI 1.0 o superior. Si el cluster tiene Calico 3.17 o Flannel pre-0.20, hay que actualizarlos.

El caso de Docker Swarm

Para quien aún opera Swarm, la migración es más suave que en Kubernetes porque Swarm no depende de CRI. Lo que importa es que Docker Engine acepte containerd 2.0 como runtime subyacente.

Docker Engine 27.x, publicado a lo largo de 2024, ya soporta containerd 2.0 como backend. Para instalaciones con containerd standalone (el containerd del sistema usado por Docker Engine vía socket, como funciona en servidores Debian bien configurados), el orden fue:

1. Actualizar containerd de 1.7 a 2.0.
2. Reiniciar containerd.service.
3. Verificar ctr version y que los contenedores existentes seguían corriendo.
4. Subir Docker Engine a 27.x y reiniciar docker.service.

No hubo caídas de contenedores, pero dos imágenes tuvieron que reconstruirse porque eran Schema 1.

Observabilidad durante la migración

Algo que aprendí a la fuerza en una migración anterior: el containerd por defecto no emite métricas Prometheus sin configurarlo. Antes de migrar hay que asegurarse de que metrics.address = "0.0.0.0:1338" está en la config y de que el exporter está scrapeado. Sin eso, la única señal de que algo va mal es que los contenedores mueren.

Las métricas clave a vigilar durante y después de la migración son:

• Contador de contenedores activos.
• Ratio de pull fallidos.
• Latencia de la API de tasks.
• Errores de shim.

Con esas cuatro señales cubiertas, una migración que va mal se detecta en minutos en vez de horas. El mismo principio de observabilidad antes de actuar aplica a la gestión de operaciones en Kubernetes 1.32.

Mi lectura

containerd 2.0 es una migración obligatoria pero no urgente para la mayoría de equipos. El mayor motor para saltar es que la 1.6 ya no tiene soporte. Si el cluster está en 1.7 y no hay presión regulatoria, esperar a la 2.1 (prevista para finales de 2025) puede evitar algunos bordes afilados que todavía veo.

Lo que me parece más positivo del release es la limpieza. Retirar CRI v1alpha2 y Schema 1 de OCI son decisiones que la comunidad llevaba posponiendo años y que pagarán dividendos en mantenibilidad futura.

Mi recomendación práctica:

• Si operas Kubernetes: revisa el kubelet de todos los nodos antes de tocar nada, actualiza Calico o el CNI que uses a 1.0 y ten una ventana de mantenimiento con plan de reversión.
• Si operas Swarm: más sencillo pero vigila las imágenes antiguas.
• Si operas docker puro sin Swarm ni Kubernetes: la migración es casi transparente siempre que actualices Docker Engine en el mismo ciclo.