El soporte de Kubernetes para contenedores Docker terminará el 3 de mayo

La próxima versión 1.24 de Kubernetes, que se lanzará con retraso el 3 de mayo, supone un cambio significativo para el popular sistema de orquestación de contenedores de código abierto, ya que se eliminará definitivamente el soporte integrado para los dockershim (contenedores Docker).

Docker fue el primer sotfware de ejecución de contenedores utilizado por Kubernetes. Pero a medida que el proyecto Kubernetes hizo la transición hacia su propia Iniciativa de  Contenedores Abiertos (OCI), necesitaba un parche para permitir la portabilidad con otros tiempos de ejecución de contenedores. Ese parche fue dockershim.

Esencialmente, dockershim fue pensado originalmente como una solución temporal para permitir que el popular tiempo de ejecución de contenedores Docker Engine convirtiera las llamadas OCI en llamadas Docker, dentro de la propia interfaz de tiempo de ejecución de contenedores (CRI) de Kubernetes. Con el tiempo, dockershim se afianzó en los despliegues de Kubernetes, pero ralentizó los despliegues y supuso una carga para los mantenedores. Tenía que desaparecer.

Cómo prepararse para la eliminación de dockershim

El lanzamiento de Kubernetes v1.24, que se espera para el 3 de mayo, requerirá que los usuarios que quieran estar en la última versión del software migren de dockershim a otro tiempo de ejecución que sea compatible con el propio de Kubernetes, o utilicen el reemplazo externo de dockershim desarrollado por Mirantis, conocido como cri-dockerd.

Aunque los nodos de Kubernetes ya no utilizarán por defecto el tiempo de ejecución de Docker, muchos desarrolladores y administradores ya habrán cambiado a otros tiempos de ejecución compatibles con CRI, como containerd —que el propio Docker donó al CNCF en 2017— y el CRI-O nativo. Esto normalmente implica asegurarse de que el agente kubelet que se ejecuta en cada nodo de un clúster está configurado para llamar a los sockets de contenedor o CRI-O.

Varios proveedores de Kubernetes administrados ya han avanzado, como Red Hat OpenShift, que adoptó CRI-O en 2019. Elastic Kubernetes Service (EKS) de Amazon, Azure Kubernetes Service (AKS) de Microsoft y Kubernetes Engine (GKE) de Google ya utilizan containerd por defecto. Microsoft también adoptó containerd para los grupos de nodos Linux de Azure Kubernetes creados con la versión 1.19 o posterior de Kubernetes.

Cambia a un tiempo de ejecución compatible con CRI 

Los desarrolladores que no sustituyan dockershim por un tiempo de ejecución compatible con CRI se arriesgan a romper sus clusters y a quedarse atrás en los parches de seguridad, además de perderse las nuevas funciones.

"En este punto, creemos que el valor que usted (y Kubernetes) obtiene de la eliminación de dockershim compensa el esfuerzo de migración que tendrá que hacer", según escribió el equipo de lanzamiento de Kubernetes en una publicación de blog de enero.

Los desarrolladores pueden seguir utilizando Docker a lo loco para desarrollar o probar sus contenedores, independientemente del tiempo de ejecución de contenedores que utilicen para los clusters de Kubernetes. Las imágenes producidas por Docker seguirán funcionando en los clústeres con todos los tiempos de ejecución compatibles con CRI, pero no seguirán recibiendo soporte.