Kubernetes depreca el soporte a Docker como container runtime a partir de la versión 1.20 y será eliminado en futuras versiones, en concreto, a partir de la 1.24. En este artículo te contamos la causa y el objetivo de este cambio y por qué no es un gran problema.
A pesar de que esta noticia ha generado mucha preocupación, sobre todo en las aplicaciones empresariales que utilizan imágenes de contenedores basadas en Docker, has de entender por qué Kubernetes ha optado por esto.
¿De qué va esto?
El Container Runtime es el elemento que utiliza Kubernetes para la gestión de los contenedores. Inicialmente el que utilizaba era el de Docker pero más adelante se creó el API “Container Runtime Interface” (CRI) que permitía integrarse con muchos otros container runtimes de forma transparente. De ese modo, Kubernetes comenzó a soportar una gran variedad de container runtimes donde Docker era sólo uno de ellos. El tema es que Docker no es compatible directamente con el CRI, si no que utiliza un componente de Kubernetes llamado dockershim como interlocutor, que ha requerido un mantenimiento especial para que se pueda seguir usando Docker.
Por otro lado, debemos aclarar que Docker no es un container runtime, sino una colección de herramientas que se asienta sobre un container runtime llamado containerd (luego hablaremos sobre este). Realmente, Kubernetes no necesita todo ese abanico de características que ofrece Docker, únicamente su runtime para poder levantar las imágenes. Por ello, lo que hace es eliminar todo lo que no necesita y se queda con el runtime. Sin embargo, esto añade dificultades y problemas de seguridad al añadirse más código innecesario que abre más posibilidades de ataque, además del mantenimiento del interlocutor que también puede romperse.
Lanzo una pregunta:
Kubernetes va a eliminar el componente dockershim y Docker. De esta forma sólamente estarán disponibles los componentes que sean compatibles de forma nativa con el CRI.
Con la intención de ahorrarse estos problemas para conseguir un ecosistema de contenedores más saludable y extensible, va a eliminar el dockershim y Docker. De esta forma sólamente estarán disponibles los componentes que sean compatibles de forma nativa con el CRI.
A pesar de que el Container Runtime más usado en Kubernetes es el de Docker y esto implica que todos los usuarios que lo utilicen tendrán que migrar a una solución que sea compatible con el CRI, Kubernetes ya no necesita este intermediario puesto que existen una gran variedad de opciones compatibles.
Por otro lado, has de saber que Docker estableció la “Open Container Initiative” (OCI) con el objetivo de apoyar estándares de contenedores totalmente interoperables para que cualquier contenedor pudiera funcionar en cualquier entorno. Además, Docker junto con Google e IBM crearon el proyecto de containerd, con el objetivo de proporcionar un runtime más moderno a Kubernetes, por lo que eliminar el dockershim supone un importante paso para esta transición.
En los últimos años, los principales proveedores de servicios de Kubernetes como AWS y Google han migrado a containerd como su runtime de Kubernetes. Más abajo comentaremos más alternativas o sustitutos a Docker.
Si hay algún nombre de los que hemos mencionado que no te ha quedado del todo claro, este artículo descifra muy bien esta jerga que se escucha sobre el mundo de los contenedores y cómo funciona este ecosistema.
¿Significa que hay que dejar de usar Docker?
No, esto no significa que Docker vaya a pasar a mejor vida ni que deba dejar de usarse. Docker sigue siendo una herramienta muy útil para construir imágenes y que puede correr en otro container runtime de Kubernetes.
Las imágenes de Docker son compatibles con OCI, son totalmente compatibles con containerd y seguirán funcionando correctamente en Kubernetes. Lo que no vas a poder hacer es obtener información del contenedor usando los comandos de Docker docker inspect, docker ps, listar contenedores, obtener logs, etc.
Las imágenes producidas a partir del docker build funcionarán con todas las implementaciones del CRI y todas las imágenes seguirán funcionando de la misma manera. Lo único que necesitarías, es otro container runtime si quieres construir estas imágenes en Kubernetes.
¿Podré seguir usando Docker si estoy trabajando con Kubernetes?
Kubernetes va a mantener el soporte de Docker hasta Abril del 2022 con la release 1.24, así que te va a tocar migrar a un runtime diferente.
Si utilizas un cluster de Kubernetes ya existente como GKE, EKS o AKS (utilizan containerd por defecto), no es necesario que hagas nada, ya que estos manejan el runtime del contenedor por ti. Eso sí, tendrás que asegurarte de que el runtime que tienes elegido sea compatible con el CRI.
Kubernetes va a mantener el soporte de Docker hasta Abril del 2022 con la release 1.24, así que te va a tocar migrar a un runtime diferente.
En el caso de que hayas configurado el cluster de Kubernetes desde cero, sí necesitarás tomar acción. Si por algún motivo necesitas seguir usando el runtime de Docker, podrías instalar el dockershim como un runtime externo del contenedor, aunque sólamente deberías si no tienes más remedio.
¿Qué ocurre con Docker in Docker?
Docker-in-Docker deja de funcionar. En este caso, el contenedor Docker se conectaba al Docker daemon del host, pero como ya no va a estar Docker disponible en los nodos de tu cluster de Kubernetes, esto no va a ser posible. Sin embargo, podrás seguir construyendo imágenes Docker en tu cluster de Kubernetes pero utilizando alguna otra herramienta para la construcción de imágenes que no dependan de Docker como son buildah, kaniko, img o buildkit-cli-for-kubectl, entre otras.
¿Qué runtime deberíamos usar?
Los runtimes más utilizados son containerd y CRI-O. Ambos compatibles con la CRI de Kubernetes y tienen por debajo runc. Fueron Docker, Google e IBM quienes crearon containerd con el objetivo de lograr esta transición. Si Docker te ha ido bien anteriormente, pasarte a containerd debería ser un cambio relativamente fácil y tendrá mejor rendimiento y menos sobrecarga. De todas maneras, se deben contemplar las diferentes opciones que hay, un poco más abajo hablamos un poco más sobre ambos.
¿En qué debo fijarme de otras soluciones compatibles con CRI?
Aunque Docker y la mayoría de los CRI funcionan prácticamente igual por debajo pueden ser algo diferentes y a la hora de hacer una migración deberías tener algunas cosas en cuenta como las siguientes:
- La configuración del registro.
- Limitaciones de recursos del runtime.
- Scripts que puedan llamar a Docker a través de su socket de control.
- Herramientas que puedan requerir el acceso directo a Docker.
- GPUs o hardware especial y cómo se integra con su runtime y Kubernetes.
¿Qué alternativas hay a Docker?
Antes de nada, debemos saber distinguir entre los container runtimes y los constructores de imágenes.
Un container runtime se encarga de ejecutar los contenedores y abstrae la administración de estos mientras que un constructor se encarga, principalmente, de generar imágenes. Con Docker podíamos abarcar todo esto al ser una colección de herramientas tan amplia pero con este cambio debemos considerar si necesitamos combinar alguna de estas herramientas.
Container runtimes:
containerd
Containerd es el segundo container runtime más popular. Funciona para Windows y Linux.
Proporciona una funcionalidad similar al runtime de Docker y sirve como punto de integración para los runtimes compatibles con OCI. Facilita la ejecución y supervisión de los contenedores, gestión de transferencia y almacenamiento de imágenes. Sin embargo, containerd no maneja la construcción de imágenes o la creación de volúmenes.
cri-o
CRI-O es un runtime de CRI desarrollado principalmente por Red Hat.
Es una alternativa ligera que soporta imágenes de contenedores OCI y puede extraerlas de cualquier registro de contenedores.
runc
Anteriormente runc era un módulo integrado en la arquitectura de Docker y en 2015 se lanzó como una herramienta independiente.
Desde entonces se ha convertido en un container runtime muy utilizado, estandarizado e interoperable.
Constructores de imágenes:
Buildah
Buildah es una herramienta de construcción de imágenes OCI desarrollada por la Fundación Red Hat.
Proporciona una funcionalidad similar a la de un docker build con Docker. Esta herramienta a menudo se utiliza junto con Podman, de hecho, Podman utiliza un subconjunto de funcionalidad de Buildah por debajo para implementar su proceso de construcción.
Puede construir imágenes a partir de un Dockerfile o Containerfile y produce imágenes que operan de la misma forma que las creadas con Docker, ya que las imágenes son compatibles con OCI. También proporciona la capacidad de construir imágenes desde cero, que no contienen nada, lo que da a los usuarios la libertad de añadir sólo los paquetes necesarios para construir la aplicación. A diferencia de Docker, los usuarios sólo pueden ver los contenedores que construyeron porque es específico del usuario.
Kaniko
Kaniko es una herramienta de construcción de imágenes de Google, puede hacerlo desde un Dockerfile. No tiene un deamon como Buildah pero se centra más en la construcción de imágenes de Kubernetes.
Es muy útil para la integración continua y los delivery pipelines en clusters de Kubernetes, pero no resulta serlo para las instancias en desarrollo local, ya que normalmente se ejecuta como una imagen con un orquestador de contenedores como Kubernetes.
Además, el propio Gitlab ha sido previsor con este cambio y ya tiene documentada su integración con Kaniko evitando los problemas que surgen con Docker-in-Docker.
genuinetools/img
Img es un constructor de imágenes de contenedores independiente, sin demonio y sin privilegios, compatible con Dockerfile y OCI.
Es más eficiente en cuanto a caché que Docker y también puede ejecutar múltiples etapas de construcción simultáneamente, ya que utiliza internamente el solucionador DAG de BuildKit.
Los comandos/UX son los mismos que docker {build,tag,push,pull,login,logout,save} así que todo lo que tienes que hacer es sustituir “docker” por “img” en tus scripts, línea de comandos, y/o vida.
Podman
Podman es un container engine un todo en uno. Puedes ejecutar, construir, modificar y solucionar problemas de contenedores en los clústers de Kubernetes.
Utiliza Buildah por debajo para construir las imágenes y no depende de un daemon para funcionar. En su lugar, inicia los contenedores como procesos hijos. Sin embargo, también resulta muy útil como herramienta para la construcción de imágenes, ya que permite hacerlo a través de Containerfiles o Dockerfiles y especificando un directorio del contexto de construcción.
TL;DR En resumen...
Este cambio no debe darnos miedo ni debemos considerarlo algo negativo.
Básicamente es un gran paso en este proceso de transición a un ecosistema de contenedores más interoperable donde poder usar diferentes plataformas y sistemas operativos sin tener que depender en una única empresa o proyecto.
Además, frente a este cambio no has de preocuparte de tu runtime si tu Kubernetes es de un servicio gestionado, únicamente tendrás que escoger una herramienta diferente para la construcción de imágenes en el caso de que estas se hagan dentro de los propios pods (Docker-in-Docker).
