La compatibilidad con Docker en kubelet ahora está obsoleta y se eliminará en una versión futura. La versión 1.20 de Kubernetes muestra esta advertencia después del inicio de Kubelet, si se usa Docker como tiempo de ejecución. Además, Dockershim se eliminará de Kubelet en versiones futuras, lo que elimina la compatibilidad con Docker como tiempo de ejecución de contenedores. Entonces, ¿podemos decir que Docker se está muriendo?
Antes de seguirle, entendamos algunos conceptos básicos; Docker no es igual a Container. Docker se benefició un poco del efecto Kleenex, el nombre de la marca se generaliza; en este caso, algunas personas tienden a pensar que Docker es igual a Container.
Cada vez que se usa Docker, usa una pila que consiste en un daemon docker que hace llamadas a containerd, que a su vez llama a «runc«.
La compañía Docker creó una herramienta muy ergonómica para trabajar con contenedores llamada docker. Cuando instalamos el motor Docker en el clúster de Kubernetes (nodo de trabajo), la herramienta Docker se instala en una estación de trabajo y contiene:
- CLI : utilidad de línea de comandos
- API
- Servidor, que tiene tiempo de ejecución de contenedor ( containerd), Docker Volume, interfaz de red y función para crear imágenes.
containerd : es un proceso daemon (tiempo de ejecución de contenedor de alto nivel) que proviene de Docker e implementa la especificación CRI. Extrae imágenes de los registros, las administra y luego las entrega a un tiempo de ejecución de nivel inferior (runc), que en realidad crea y ejecuta los procesos del contenedor. Gestiona el almacenamiento y las redes, y supervisa el funcionamiento de los containerd. containerd implementa la interfaz de tiempo de ejecución del containerd (CRI) de Kubernetes a través de su complemento cri.
runc : un tiempo de ejecución de contenedor de bajo nivel compatible con OCI para expandir y ejecutar contenedores. Utiliza espacios de nombres de Linux, grupos de control para crear, ejecutar y proporcionar aislamiento a los procesos del contenedor.
Es una implementación nativa basada en Go para crear contenedores y surgió del proyecto Docker. Su nombre anterior era “libcontainer”, y fue donado a la OCI (Open Container Initiative), que se encarga desde entonces. Algunas alternativas a «runc» son: crun, kata-runtime, gVisor de Google (crea contenedores con su propio kernel)
Entonces ahora podemos entender fácilmente: cuando ejecuta un contenedor con docker, lo está ejecutando a través del demonio Docker, containerd y luego runc.
¿Qué sigue?
Ahora los contenedores ya no están estrechamente relacionados con el nombre Docker. Existe un conjunto completo de herramientas de contenedores, Docker es una de ellas y Docker (la empresa) respalda algunas de ellas, pero no todas. Entonces, ¿tenemos que actuar sobre esto? Depende de su rol/función.
- Las canalizaciones de CI-CD seguirán utilizando el motor de Docker para crear imágenes.
- El tiempo de ejecución del contenedor es transparente para Dev-ops, ingenieros y desarrolladores. No necesitan preocuparse por eso.
- Los principales servicios de K8 en la nube pública (AKS, EKS, GKE) han utilizado containerd como tiempo de ejecución. Por lo tanto, los administradores de K8s que han utilizado servicios gestionados no necesitan realizar ninguna acción. De todos modos, no instalamos el tiempo de ejecución en el servicio K8 administrado en la nube.
- Los clústeres k8s autoadministrados en las instalaciones deben cambiar el tiempo de ejecución de docker a containerd/CRI-O o instalar Dockershim por separado y mantener las prácticas anteriores.
- El escritorio Docker y el minicubo tienen su tiempo de ejecución de contenedor. Así que no se ven afectados por este cambio.
Para resumir, no hay necesidad de entrar en pánico. Docker todavía está vivo, mucho.
- Los cambios no son tan dramáticos como parece.
- Hay tiempo suficiente. Los cambios/la función final ocurrirá en varios meses.
- Dockershim va a desaparecer, pero podemos instalarlo por separado y mantener el estilo antiguo.
Fuente
