Quizás sea un poco prematuro, o debiera cambiar el título a “Crónica de una muerte anunciada”. La comunidad de desarrolladores y devops conoció recientemente una noticia impactante: “Kubernetes dejará de dar soporte a Docker como runtime de contenedor”. Agárrense, que vienen curvas.

Las preguntas que nos formulamos todos son muchas, pero quizás las podríamos resumir en estas tres: ¿Qué diablos significa esto? ¿Por qué Kubernetes no quiere usar Docker? ¿Cómo va a impactarme en mis desarrollos y despliegues?

Como sabemos, Kubernetes soporta una gran variedad de runtime de contenedor, donde Docker es sólo uno de ellos. El matrimonio Kubernetes+Docker ha funcionado mucho tiempo, y para Kubernetes sirvió para alcanzar el objetivo de llegar al gran público, gracias a la popularidad alcanzada por Docker. Ahora es el momento de que cada uno siga su camino por separado.

El motor de Docker, como ya sabrás, ofrece los servicios de runtime de contenedor, volúmenes, networking y gestión de imágenes. Cuando dimos el salto a Kubernetes, éste ofrecía de forma nativa estos servicios, excepto el runtime de contenedor. En una implementación típica de k8s, Kubernetes ofrece el CLI, los volúmenes y el networking, usando el runtime de Docker para gestionar el ciclo de vida de los contenedores.

Kubernetes interactúa con el runtime de Docker a través del servicio “dockershim”, que ha formado parte del código de k8s desde el principio. A partir de la versión 1.20 de k8s, Kubernetes dejará de dar soporte a dockershim (Dockershim Deprecation FAQ | Kubernetes) y, en consecuencia, el cluster no podrá administrar contenedores de Docker. ¡¡¡¡¡¡GUAUUUU!!!!!!

La razón de este cambio tiene mucho sentido. Si Kubernetes no necesita a este intermediario para gestionar los contenedores, se consiguen inmediatamente beneficios de rendimiento, ahorro de recursos, y seguridad (se reduce la superficie de ataque al retirar servicios no necesarios)

En consecuencia, Kubernetes debe elegir otro runtime de contenedor y abandonar Docker. La elección natural ha sido “containerd”. Entre sus características más destacables, podemos mencionar que: es el segundo runtime más popular, ya se usa como runtime de contenedor para los contenedores de los servicios de Kubernetes en la mayoría de los clústeres administrados (los que nos ofrecen los proveedores cloud)

Muy interesante, pero es el momento de contestar a las preguntas que nos planteamos al principio.

¿Qué significa este cambio para mí?

Para los DESARROLLADORES, cuando tu aplicación se despliega en un cluster, el cambio del runtime de k8s NO TE AFECTA y en consecuencia no debes preocuparte de nada, ya que Kubernetes abstrae completamente la gestión de los contenedores. Por lo tanto, se trata de una gran noticia. ¡¡¡¡¡UFFFFFF, MENOS MAL!!!!!.

Si eres DEVOPS y el cluster es NO administrado, tampoco debes preocuparte demasiado, ya que los proveedores cloud ya usan containerd como runtime de contenedor en sus clústeres desde siempre. Solo en el caso de que tengas que desplegar los nodos, por ejemplo, un cluster no administrado on-prem, entonces tendrás que tener en cuenta lo que te comento a continuación.

Hasta el momento, hemos instalado Docker y k8s. Como a partir de la 1.20 se empieza a perder el soporte de Docker, entonces tendrás dos posibilidades: Sustituir Docker por otro runtime (containerd) o instalar “dockershim” para poder seguir usando Docker. Dockershim es ahora un proyecto independiente bajo open-source.

¿Cuánto tiempo tengo para decidir estos cambios?

Cuando instales la 1.20, aun podrás usar Docker de la forma tradicional. Solo aparecerá un warning cuando arranque el servicio kubelet en el nodo, si sigues usando Docker como runtime. Este soporte no será retirado realmente hasta después de la liberación de la versión 1.22, lo que significa que, a partir de la 1.23 (planificada para finales de 2021) ya no podrás usar Docker.

¿Qué pasará con minikube o Docker Desktop?

Si usas estos productos para aprender o desarrollar, la buena noticia es que TAMPOCO debes preocuparte, ya que cuando actualices a las futuras versiones, los instaladores ya incluirán el runtime correcto (containerd), así que no te afectará nada.

¿Debo seguir aprendiendo Docker? ¿Qué pasa con las imágenes de Docker?

Hasta el momento, cuando desarrollamos nuestra aplicación, ésta termina convertida en una imagen. Creamos la aplicación, la testeamos, compilamos la imagen de Docker, la subimos al registro y por último la desplegamos en un cluster de Kubernetes.

Entonces, si ahora ya no está Docker, ¿cómo vamos a ser capaces de hacer correr contenedores de Docker? ¿Debemos cambiar el pipeline de desarrollo por completo?

La grandísima noticia es que CUALQUIER IMAGEN de Docker puede correr en CUALQUIER RUNTIME de contenedor (incluido containerd). ¿Cómo es esto posible?

La razón es OCI (Open Container Initiative) de la Fundación Linux, que define unos estándares para que esto pueda ser así, y por supuesto, Docker y containerd cumplen con estos estándares. En definitiva, lo que debes sacar en claro de aquí es que containerd puede ejecutar cualquier imagen de Docker. Gracias a OCI, como desarrollador no deberás cambiar para nada tu forma de trabajar, y la sustitución del runtime debes verla como una mejora en rendimiento para el cluster.

En definitiva, que no cunda el pánico, al menos para los desarrolladores. Para los DEVOPS o administradores del cluster on-prem, debéis empezar a tener en cuenta lo dicho en este artículo y dejar de instalar Docker en poco tiempo. Os recomiendo leer este artículo para mayor información: Don’t Panic: Kubernetes and Docker | Kubernetes