Kubernetes dejó sin soporte a Docker.

¿Kubernetes rompió con Docker?

A principios de Diciembre de 2020 Kubernetes liberó su versión 1.20 y anunció que va a dejar sin soporte a Docker a partir de su versión 1.23.

¿Qué significa esto?
¿Por qué Kubernetes dejó sin soporte a Docker?
¿En qué afecta esto a los desarrolladores, a los ingenieros devops y a los administradores que trabajan con Docker y Kubernetes?

Como es sabido, Kubernetes soporta múltiple tipos de contenedores. Uno de ellos es Docker.
Docker es el container runtime más popular hasta el momento y que utilizan la mayoría de los proyectos desarrollados como microservicio. Cuando un proyecto es compuesto por muchos contenedores es necesario un orquestador como lo es Kubernetes.

Veamos cómo trabaja kubernetes y el engine docker

Docker engine tiene 3 componentes. Está el Docker Server, la API que básicamente se utiliza para interactuar con el Docker Server y la CLI que permite al usuario poder interactuar con el Docker Server.
El Docker Server tiene sus propios componentes. Tiene el container runtime que administra el ciclo de vida de los contenedores y sus imágenes, tiene los volúmenes para poder dar persistencia a los contenedores y tiene las interfaces de red de los contenedores. También puede realizar la compilaciones de nuevas imágenes de Docker.
De hecho, Kubernetes solamente necesita el container runtime para poder correr contenedores dentro del cluster. Los demás componentes de Docker no son necesarios ya que Kubernetes tiene su propia CLI, administra sus propios volúmenes y tiene su propia interfaz de red. Recordemos que Kubernetes no realiza compilación de imágenes, solamente ejecuta contenedores.
Para que Kubernetes pueda interactuar con el container runtime primero debe comunicarse con Docker. Para establecer esta comunicación, utiliza dockershim. Dockershim implementa el soporte para el CRI (Container Runtime Interface) y es parte del código de Kubernetes que los desarrolladores debieron implementar para poder dialogar con Docker. Este componente de Kubernetes es el que se dejó de incluir en el código de Kubernetes.
Sin este componente, Kubernetes, puede dialogar directamente con el container runtime. Esto disminuye el consumo de recursos de CPU, memoria y es menos pesada la instalación del cluster. También se disminuyen los riesgo en las brechas de seguridad que puedan existir.

Si estás interesado en conocer en profundidad el funcionamiento de Docker puedes leer la serie de tutoriales desarrollada por ApuntesIT.

Alternativas de container runtime

Kubernetes no puede dialogar con el container runtime ya que es parte de Docker, entonces la alternativa es Containerd.
El componente Containerd originalmente formaba parte del código de Docker Daemon.
Docker lo extrajo y lo convirtió en un componente separado por lo que ahora se puede desplegar como un componente por separado dentro del cluster de Kubernetes.
Actualmente Containerd es un proyecto individual que es desarrollado, mantenido y distribuído por la CNCF.
Containerd es el segundo container runtime más popular, luego del runtime container de Docker.
Containerd es utilizado por los principales proveedores de servicios en la nube para sus productos de kubernetes. Amazon EKS, Google Cloud Kubernetes Service y recientemente Azure para su servicio AKS.
Por todo esto es que Containerd se está convirtiendo en el container runtime mas pupolar en cluster de Kubernetes.
Otra alternativa es CRI-O que es utilizado por Openshift.

 

¿Cómo afectan estos cambios a los usuario de Kubernetes?

Como usuarios de Kubernetes tenemos a los desarrolladores de microservicios y a los ingenieros DevOps.
Para desplegar recursos o aplicaciones en un cluster existente, no afecta en absoluto la operatoria. Esto es porque el cluster ya tiene un container runtime desplegado y funcionando dentro del cluster. Por lo que se deben despreocupar por estos cambios.

¿Cómo afectan estos cambios a los Administradores de Kubernetes?

Los administradores de Kubernetes son responsables de instalar, actualizar y configurar las redes, los volúmenes y demás componentes que conforman el cluster. Según el nivel de responsabilidades definidas dentro de la organización es posible que en este perfil se puedan incluir a los ingenieros DevOps.

Kubernetes en la nube

Si el cluster se encuentra en un proveedor en la nube como AWS, Google Cloud, Azure o cualquier otro, Usted no instaló binarios en los master y en los nodos worker. Tampoco instaló el container runtime. Por estas razones, usted no debe hacer nada en absoluto y despreocuparse de estos cambios ya que es responsabilidad del proveedor del servicio realizar las tareas necesarias para que todo siga funcionando sin problemas.

Kubernetes personalizado

El único caso que requiere una acción es si utiliza su propio cluster de Kubernetes, como es el caso de instalaciones baremetal o maquinas virtuales. Es estos casos usted debe instalar todos los binarios, los procesos de kubernetes, el container runtime, las interfaces de red, etc. en todos los servidores que conforman el cluster.
Si su cluster utilizaba Docker como container runtime tiene 2 opciones para poder tener su Kubernetes actualizado.

  1. Reemplazar el container runtime de Docker por Containerd, CRI-O o cualquier otro.
  2. Si por alguna razón decide seguir utilizando el container runtime de Docker es necesario que instale Dockershim.

Esto último es posible ya que Mirantis y Docker anunciaron que van a mantener a Dockershim como un componente separado de Kubernetes. Es por este proyecto que va a poder tener dentro del cluster de Kubernetes el container runtime de Docker.

 

¿Cuándo necesita realizar estas acciones?

Debe hacerlas inmediatamente para evitar inconvenientes. Como lo indica Kubernetes en su anuncio a partir de la versión 1.20 se mostrará una advertencia, pero a partir de la versión 1.23 el cambio se hará efectivo y ya no será soportado el container runtime de Docker.

¿Cómo afectan estos cambios en instalaciones locales como Minikube o Docker Desktop?

Esto no afecta en nada ya que estas herramientas ya incluyen los cambios necesarios en su container runtime. Por lo que como usario no debemos preocuparnos y seguir utilizando sin problemas nuestro Minikube o Docker Descktop.

¿Que ocurre con los pipelines de CI/CD que utilizan imágenes Docker?

Para los pipelines de CI/CD que realizan la creación de nuevas imágenes docker es necesario realizar la tarea de Build, recordemos que Kubernetes no realiza la creación de imágenes por lo que se debe seguir utilizando Docker para esta tarea.
Ahora bien, qué sucede en los siguientes pasos del pipeline de CI/CD? Bueno, para realizar el test de código de la imagen y el push de la imagen al cluster no se necesita el container runtime. Luego para poder desplegar la imagen Docker en el cluster Kubernetes sin el soporte de Dockershim tampoco debemos tener problema. La razón es porque cada imagen Docker puede ser ejecutada en cualquier container runtime. Así que, si por ejemplo, el cluster destino tiene instalado el containrd como container runtime la imagen Docker va a ser desplegada y ejecutada correctamente.

¿Pero cómo es posible que una imagen Docker pueda correr en cualquier container runtime?

La razón de esta compatibilidad es que todas la herramientas de contenedores utilizan el estándar definido por la Iniciativa Contenedores Abiertos – OCI por sus siglas en inglés. Estos estándares indican el modo en el que deben trabajar los contenedores y como deben implementarse. Es por esto que Docker, containerd y CRI-O son compatibles uno con otro y pueden correr imágenes de Docker en CRI-O o en containerd sin problemas.

Puedes aprender más acerca de la creación de imágenes Docker en nuestro tutorial.

En resúmen, en la mayoría de los casos no hay que realizar acciones frente a estos cambios. El único escenario es cuando usted es administrador de un cluster personalizado o instalado por su cuenta en bar metal o maquinas virtuales.

Comparto el video creado con respecto a este tema publicado en el canal de ApuntesIT en Youtube.

YouTube player

 

 

Publicaciones Similares

Deja un comentario