Kubernetes está procediendo con la desaprobación y la eliminación de dockershim en la próxima versión 1.24 . Los flujos de trabajo y los sistemas que utilizan Docker Engine como tiempo de ejecución del contenedor para su clúster de Kubernetes deberán migrar antes de pasar a la versión 1.24. La versión 1.23 conservará dockershim y será compatible durante un año más.
Docker fue el primer tiempo de ejecución de contenedor utilizado por Kubernetes. Originalmente, el soporte de Docker estaba codificado en Kubernetes, pero a medida que el proyecto evolucionó, Kubernetes comenzó a agregar soporte para más tiempos de ejecución. La comunidad de Kubernetes decidió pasar a interfaces más estructuradas y estandarizadas en lugar de integrar directamente soluciones de terceros en el código principal. Esto llevó a la creación de Container Runtime Interface (CRI) , Container Network Interface (CNI) y Container Storage Interface (CSI) .
Como afirma Adam Parco , CTO de Mirantis :
Para la mayoría de las personas, la desaprobación de dockershim no es un problema, porque aunque no lo saben, en realidad no están usando Docker per se; están usando containerd, que es compatible con CRI. Para esas personas nada cambiará.
Como Docker no es compatible con CRI, dockershim actúa como una capa de traducción entre kubelet y Docker. Docker luego interactúa con containerd para ejecutar los contenedores. Containerd se extrajo de Docker como un tiempo de ejecución de contenedor autónomo y se convirtió en el primer tiempo de ejecución compatible con CRI. El cambio para desaprobar dockershim hará que kubelet se comunique directamente con el tiempo de ejecución del contenedor, como containerd.
/filters:no_upscale()/news/2022/01/kubernetes-dockershim-removal/en/resources/1cri-containerd-1642536386693.png)
Flujo de trabajo de Kubernetes a través de contenedores en comparación con dockershim (crédito: Kubernetes )
Como se señaló en una publicación reciente en el blog de Kubernetes, el alejamiento de dockershim es para alinear mejor el código base de Kubernetes con el nuevo modelo de interfaz. Algunas funciones nuevas, como cgroups v2 y el espacio de nombres de usuario, son en gran medida incompatibles con dockershim. Como señalan los autores de esta publicación de blog reciente : “Las dependencias de Docker y dockershim se han infiltrado en varias herramientas y proyectos en el ecosistema CNCF, lo que ha dado como resultado un código frágil”.
Si Docker se está utilizando actualmente para crear los contenedores de la aplicación, estos contenedores aún se pueden ejecutar en cualquier tiempo de ejecución del contenedor. Cuando se usa un entorno de ejecución de contenedor alternativo, es posible que los comandos de Docker no funcionen o produzcan resultados diferentes. Por ejemplo,
Otras cosas a tener en cuenta para determinar una dependencia en dockershim incluyen asegurarse de que ningún Pod privilegiado ejecute comandos de Docker como
Se debe realizar una revisión de los scripts que se ejecutan fuera de la infraestructura de Kubernetes para identificar los comandos de Docker. Esto podría incluir SSH a los nodos para solucionar problemas, secuencias de comandos de inicio de nodos o agentes de supervisión y seguridad que se instalan directamente en los nodos.
Mirantis y Docker acordaron asociarse para mantener el código dockershim como una interfaz CRI compatible, independiente y de código abierto para Kubernetes. Esto significa que Mirantis Container Runtime (MCR) será compatible con CRI. Su cri-dockerd podría aprovecharse como un reemplazo externo para dockershim en los casos en que apagar dockershim no sea deseable o factible.
El equipo de lanzamiento de Kubernetes 1.24 y el CNCF se han comprometido a entregar la documentación a tiempo para el lanzamiento, actualmente programado para abril. Esto incluye publicaciones de blog, actualización de ejemplos de código, tutoriales y una guía de migración.
El equipo cree que ya no hay obstáculos importantes para continuar con la migración. Señalan que las discusiones sobre el aplazamiento ocurrieron en la reciente discusión del Nodo SIG el 11 de noviembre y en la reunión del Comité Directivo de Kubernetes el 6 de diciembre. Sin embargo, en este momento acordaron continuar con la eliminación de dockershim en la próxima versión 1.24.