containerd 2.0 se lanzó a finales de 2024 y, en ese momento, el propio consejo del proyecto era no precipitarse: las ramas 1.x seguirían con soporte durante bastante tiempo. Esa ventana ya se ha cerrado. El soporte extendido de containerd 1.7 termina en septiembre de 2026, y Kubernetes 1.35 es la última versión de Kubernetes que admite containerd 1.x: cualquier versión posterior requiere 2.x. Si un clúster sigue en containerd 1.x, esta actualización ya no es opcional. Esta guía cubre qué cambió realmente y cómo comprobar tu exposición antes de dar el paso.

containerd versionó su propia API por separado del daemon

Desde la 2.0, la versión del daemon y la versión de la API gRPC ya no son el mismo número: containerd saltó a la 2.0, pero la API en sí no tuvo cambios incompatibles y se mantuvo en una línea 1.x (pasó a la 1.8). La biblioteca cliente de Go también se movió a su propia ruta de paquete. En la práctica, esto significa que la mayoría de las integraciones directas con la API o con el cliente de Go no necesitan más que rutas de importación actualizadas, no una reescritura: los mantenedores de containerd informaron de que la migración de al menos una herramienta de terceros fue exactamente eso, una búsqueda y reemplazo en las rutas de importación.

Qué se eliminó realmente en la 2.0

• El soporte de imágenes Docker schema 1, desactivado por defecto. Schema 1 fue reemplazado por schema 2 en 2014 y luego por el formato de imagen OCI en 2017; si una imagen tiene más de unos pocos años y no se ha reconstruido, es candidata a schema 1. containerd convierte las imágenes schema 1 al descargarlas en lugar de almacenarlas tal cual, así que la solución práctica para una imagen que aún necesites es descargarla una vez y volver a subirla a tu registro, lo que realiza la conversión por ti.
• El soporte de la API CRI v1alpha2. Kubernetes mismo pasó a la API estable CRI v1 en la versión 1.23; cualquier kubelet moderno ya usa v1. Lo que realmente está en riesgo son las herramientas de terceros, agentes de monitorización, escáneres de seguridad, cualquier otra cosa que hable directamente con el socket CRI, que podrían no estar actualizadas. Conviene revisar primero todo lo que monte el socket de containerd como bind mount o se ejecute como privilegiado.
• Las dos implementaciones de shim más antiguas (io.containerd.runtime.v1.linux e io.containerd.runc.v1), dejando io.containerd.runc.v2 como la única. Esta ya era la predeterminada desde hacía años, así que la mayoría de los clústeres no ven ningún cambio de comportamiento, solo la eliminación de rutas de código que nada usaba.
• El snapshotter aufs, que dependía de un sistema de archivos del kernel que no está en upstream. overlayfs, el predeterminado desde hace mucho, es el reemplazo y no requiere ninguna acción si no estabas configurado deliberadamente para aufs.
• Las syscalls basadas en io_uring, denegadas por defecto tras CVE del kernel asociadas a ellas. Las cargas de trabajo afectadas deberían recurrir a rutas de syscalls más antiguas para la misma funcionalidad en lugar de fallar sin más, aunque containerd no puede detectarlo de antemano como sí puede con los demás cambios de aquí.

Aparte, el antiguo mecanismo de plugins de Go estilo dlopen y las opciones heredadas de mirror de registros y configuración de CRI quedaron obsoletos en la 2.0 y se eliminaron en versiones 2.x posteriores, con una justificación similar: poco uso en el mundo real y un reemplazo claro disponible (configuración de registros al estilo hosts.toml para esto último).

Averigua a qué estás realmente expuesto

containerd incluye un servicio de deprecaciones que registra una advertencia, con marca de tiempo, la primera vez que algo en un nodo usa realmente una función programada para su eliminación. Solo se dispara con uso real, no de forma especulativa, así que un informe limpio significa una actualización limpia:

ctr deprecations list
ctr deprecations list --format json   # para alimentar otras herramientas

Esta es una función de 1.x (con backport a las versiones de parche 1.6 y 1.7), no de la 2.0, y eso es exactamente lo que la hace útil: compruébalo en tu clúster actual, en el runtime que estás a punto de abandonar, antes de actualizar nada. containerd borra este estado al reiniciar el daemon, así que si ya has reiniciado containerd o reconstruido nodos recientemente, ejecuta cargas de trabajo durante un tiempo primero para que vuelvan a aflorar los patrones de uso reales.

Una secuencia de actualización práctica

1. Pasa primero a la última versión de parche 1.7.x, para que el servicio de deprecaciones sea preciso y no mezcles una actualización con correcciones de errores no relacionadas.
2. Ejecuta tráfico de producción el tiempo suficiente para que afloren los patrones de uso reales y luego revisa ctr deprecations list en toda tu flota.
3. Corrige lo que aparezca: convierte o reemplaza imágenes schema 1, actualiza las herramientas que aún llamen a CRI v1alpha2, revisa la configuración en busca de sintaxis de registros obsoleta (la mayor parte se migra automáticamente; la sintaxis antigua sigue funcionando bajo un daemon 2.x durante la transición).
4. Vuelve a ejecutar y confirma que la lista de deprecaciones sale limpia.
5. Actualiza primero un clúster de pruebas o un subconjunto de nodos a 2.x, y solo entonces despliega de forma amplia.

Si usas un proveedor de Kubernetes administrado, comprueba si él mismo muestra estas advertencias de deprecación: algunos proveedores las propagan a condiciones de nodo o a su propia consola, y las tienen en cuenta en el control automatizado de actualizaciones, lo que evita tener que entrar por SSH a cada nodo individualmente.

Dónde mirar cuando algo no encaja aquí

El proyecto containerd publica una tabla completa de cada cambio de la 2.0 y su reemplazo, junto con notas de versión detalladas, en containerd.io y en el repositorio de GitHub del proyecto. Para cualquier cosa que esta guía no cubra, esa es la fuente autorizada, junto con el canal #containerd del Slack de la CNCF para obtener ayuda directa.