ATENCIÓN: este contenido tiene más de 2 años de antigüedad y, debido a su temática, podría contener información desactualizada o inexacta en la actualidad.
Todo empezó hace unos días. Enterrado entre las notas de la próxima versión 1.20 de Kubernetes, sus desarrolladores anunciaban que el orquestador de contenedores que todo el mundo utiliza, iba a "declarar Docker como obsoleto en su plataforma, para eliminarlo en una versión posterior".
Los gritos se escucharon por toda Internet: ¿Qué pasa con este anuncio? ¿Está Docker obsoleto? ¿Deberíamos dejar de usarlo? ¿Qué le pasa a toda la inversión que he hecho en Docker y Kubernetes? ¡Socorro! 😱
Relájate. El impacto de este anuncio es mínimo y seguramente ni siquiera te va a impactar. Te lo explicamos a continuación.
Lo primero: distinguir entre qué es Docker, qué hace y qué tiene por debajo
El primer personaje relevante en empezar a poner las cosas claras fue Kelsey Hightower, el conocido evangelista y profesor de la plataforma cloud de Google con un tuit en el que recordaba una cosa importante:
Docker != Contenedores
Existen las imágenes de contenedores. Docker las puede crear.
Existen registros de imágenes. Docker puede hacer push y pull hacia estos.
Existen los procesos de contenedores. Docker los puede crear pero Linux es el que manda.
Hasta la propia Kubernetes lanzó un post en su blog titulado "Don't Panic: Kubernetes and Docker", para llamar a la calma. En él explican lo que ocurre realmente: de momento marcan como obsoleto el kubelet en el módulo Dockershim, que implementa el soporte para Docker como runtime de contenedores, para posteriormente eliminarlo.
Pero como trataba de explicar el tuit mencionado antes, esto no significa gran cosa. Veamos por qué.
Docker es muchas cosas: una pila tecnológica completa para manejar contenedores e imágenes, con multitud de herramientas y utilidades, sobre todo pensadas para desarrolladores. Pero Kubernetes no necesita la mayor parte de lo que ofrece Docker. Sólo una pequeña fracción: el runtime, es decir, el que es capaz de "levantar" las imágenes y ponerlas en marcha. Lo que hace Dockershim es realmente quitar de Docker todo lo que Kubernetes no necesita y quedarse con el runtime, porque añade dificultades, mantenimiento y posibles problemas de seguridad.
Y si Kubernetes solo necesita un runtime y Docker no le vale de entrada. ¿Cuál sería el runtime que deberíamos utilizar?
Bueno, pues en la actualidad los dos principales runtimes, los que más se utilizan, son containerd y CRI-O, ambos compatibles con la interfaz de tiempo de ejecución de contenedores (CRI) de Kubernetes. Docker en sí no soportaba la CRI de Kubernetes, de ahí el problema y la necesidad del shim, pero su runtime ligero de código abierto, runc, es lo que tienen por debajo tanto containerd como CRI-O. Es más, Docker junto a Google y a IBM, crearon el proyecto containerd usando runc en 2016, precisamente con el objetivo de lograr esta transición que llegará el año que viene, como explican en su propio artículo oficialmente.
Entonces, ¿qué es lo que ocurre finalmente y cómo me afecta?
Pues lo que ocurre es que en la versión 1.20 de Kubernetes verás un aviso en el kubelet si usas Docker como runtime. Nada más. Todo seguirá igual.
Pero para Kubernetes 1.23, que saldrá a finales de 2021, Docker no se soportará como runtime directo. En lo único que te afectará es que tendrás que elegir entre containerd y CRI-O como runtime (entre otros) para ejecutar tus contenedores en Kubernetes. Ambos usan por debajo runc, el runtime de Docker, por lo que todo funcionará sin problema y podrás seguir utilizando Docker como hasta ahora para desarrollar y probar fuera de Kubernetes. Las imágenes que crees con Docker seguirán funcionando en tu clúster de Kubernetes, propio o en la nube, de la misma manera que hasta ahora, solo que sin la sobrecarga de tener que quitar "lo que sobra" de Docker.
Hay todo un FAQ sobre esto de todos modos.
Si trabajas con Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS) o Amazon Elastic Kubernetes Service (EKS), simplemente tendrás que asegurarte de que, antes de la versión 1.23, tienes elegido como runtime uno de los compatibles.
Quizá si haces cosas muy avanzadas que dependen mucho de Docker puedas tener algún problema y tendrás que trabajarlo, pero entonces no te preocupará este anuncio porque entiendes perfectamente las implicaciones. Para los demás, el impacto es mínimo y de hecho incluso beneficioso.
En resumen: relájate. Docker no se ha vuelto algo inútil de repente ni vas a tener que aprender nada nuevo.
Fecha de publicación: