A partir de la v1.20, Kubernetes descarta Docker como untiempo de ejecución decontenedor.
Pero que no cunda el pánico. No todo es tan malo como parece a primera vista.
TL; DR. Kubernetes está abandonando Docker en favor de los tiempos de ejecución de Container Runtime Interface (CRI) diseñados específicamente para Kubernetes. Las imágenes de Docker seguirán funcionando como de costumbre en todos los tiempos de ejecución.
Para los usuarios finales de Kubernetes, poco cambiará. Todo esto no significa que Docker "morirá" o que debería o no debería utilizarse más para el desarrollo. Docker seguirá siendo una gran herramienta para la creación de contenedores, y las imágenes creadas con él
docker build
seguirán ejecutándose en el clúster K8s.
Si usa servicios administrados de Kubernetes como GKE o EKS, debe asegurarse de que sus trabajadores estén usando una versión compatible del tiempo de ejecución y hacerlo antes de que se elimine la compatibilidad con Docker en una versión futura de K8. Si sus nodos tienen configuraciones específicas, lo más probable es que deba actualizar para cumplir con los requisitos de tiempo de ejecución y entorno adecuados. Le recomendamos que se ponga en contacto con su proveedor de servicios y analice todos los problemas de planificación de la actualización y las pruebas.
Si implementa los clústeres usted mismo, también deberá realizar los cambios adecuados para evitar problemas. Al actualizar a la versión 1.20, recibirá una advertencia de obsolescencia de Docker. Los desarrolladores planean abandonar completamente Docker en la versión 1.23, cuyo lanzamiento está programado para fines de 2021. Con su lanzamiento, tendrá que cambiar a uno de los entornos ejecutables compatibles, por ejemplo, contenedor o CRI-O. Solo asegúrese de que el entorno que elija sea compatible con las configuraciones del demonio de Docker que está utilizando (por ejemplo, registro).
¿De qué se trata toda esta confusión y por qué todos están tan preocupados?
De hecho, estamos hablando de dos entornos completamente diferentes y esto crea confusión. Dentro del clúster de Kubernetes hay un tiempo de ejecución de contenedor , que es responsable de cargar y ejecutar imágenes de contenedor. Y Docker es bastante popular como herramienta para organizar este entorno (containerd y CRI-O también son ampliamente conocidos). Sin embargo, Docker no fue diseñado para integrarse en Kubernetes y esto plantea varios problemas.
"Docker" no es una herramienta separada, sino una pila de tecnología completa, y uno de sus componentes se llama "containerd" (escribimos sobre esto con más detalle aquí - aprox. Transl.)y actúa como un tiempo de ejecución de alto nivel para contenedores. Docker es popular y conveniente debido a la gran cantidad de complementos para los usuarios que simplifican enormemente el proceso de interacción con esta herramienta durante el desarrollo. Sin embargo, Kubernetes no necesita todas estas mejoras de UX porque no es humano.
Debido a este nivel de abstracción fácil de usar, el clúster de Kubernetes se ve obligado a utilizar otra herramienta, Dockershim, para "llegar" a lo que realmente necesita: contenedor. Y esto es malo, ya que esa capa adicional debe ser reparada y también puede "romperse". En realidad, resulta lo siguiente: en Kubernetes v1.23, Dockershim se eliminará de Kubelet; en consecuencia, Docker perderá soporte como tiempo de ejecución del contenedor. Surge la pregunta: si containerd ya está incluido en la pila de Docker, ¿por qué Kubernetes necesita Dockershim?
El caso es que Docker no es compatible con Container Runtime Interface.(CRI). Si fuera compatible, no necesitaríamos una capa extra y todo sería genial. Sin embargo, este no es el fin del mundo y no es motivo de pánico. Simplemente reemplace el tiempo de ejecución de Docker por uno que sea compatible.
Tenga en cuenta que si está utilizando el conector de Docker (
/var/run/docker.sock
) como parte de un flujo de trabajo normal, después de cambiar a otro entorno ya no podrá trabajar con él. Este patrón a menudo se denomina "Docker en Docker". Hay muchas herramientas diferentes para solucionar este problema, incluidas kaniko , img y buildah .
¿Cómo afectará este cambio a los desarrolladores? ¿Seguiremos escribiendo Dockerfiles? ¿Construiremos imágenes usando Docker?
Este controvertido cambio se trata de un entorno completamente diferente al que la mayoría de la gente usa para interactuar con Docker. La instalación de Docker para el desarrollo no tiene nada que ver con el tiempo de ejecución dentro del clúster de Kubernetes. Sí, esto es confuso, lo sé ...
Incluso después de la innovación, Docker seguirá siendo la misma herramienta útil para los desarrolladores. Las imágenes generadas por Docker pueden funcionar con algo más que Docker. Estas son imágenes OCI completas. Cualquier imagen compatible con OCI se verá igual en Kubernetes, independientemente de la herramienta con la que se haya creado. containerd y CRI-O son excelentes para obtener estas imágenes y ejecutarlas. Por eso se creó el estándar de contenedores.
Entonces, vienen cambios. Algunas personas, por supuesto, se encontrarán con ciertos problemas. Pero no hay nada de qué arrepentirse o preocuparse, porque el progreso es algo genial. Dependiendo de cómo use Kubernetes, esto puede significar una inacción total o un esfuerzo mínimo para usted. A largo plazo, esta innovación solo facilitará las cosas.
Si los próximos cambios aún lo confunden, entonces está bien. Hay muchas partes móviles en Kubernetes y nadie es 100% experto en eso. No dude en hacer cualquier pregunta, independientemente del nivel de experiencia o dificultad. Nuestro objetivo es preparar a todos tanto como sea posible para los próximos cambios. <3 ¡Esperamos que esta publicación haya respondido la mayoría de sus preguntas y haya disipado todas las inquietudes y preocupaciones!
¿Necesitas más respuestas? Consulte las preguntas frecuentes sobre la baja de Dockershim .
PD del traductor
También puede encontrar una respuesta detallada de Tim Hockin , uno de los desarrolladores de Kubernetes, en la discusión sobre este tema en Reddit .
Lea también en nuestro blog:
- “Un tiempo de ejecución maduro para contenedores: containerd se graduó en CNCF ;
- « De Red Hat sustituye a Docker en Podman »;
- "La integración de containerd con Kubernetes, en sustitución de Docker, está lista para producción ";
- « CRI-O - Alternativa de Docker para ejecutar en contenedores Kubernetes ».