¿Por qué K8s abandona Docker?
Recientemente, en el proceso de aprendizaje de la tecnología de contenedores, vi algo acerca de que Kubernetes "abandonó Docker", y me preocupaba si aprender Docker todavía es valioso ahora y si debería cambiar a contenedores u otros tiempos de ejecución ahora.
Con una comprensión más profunda, estas dudas tienen algo de verdad. Hace tres años, cuando Kubernetes lanzó la noticia de "abandonar Docker", realmente causó un "alboroto" en la comunidad de Kubernetes, y el impacto incluso se extendió fuera de la comunidad, lo que también provocó que Kubernetes escribiera varios blogs para repetir Explica por qué lo hiciste. él. Han pasado tres años, y aunque Kubernetes 1.24 ha logrado el objetivo de "desaprobación", todavía no hay una comprensión clara de este asunto, así que registre toda la historia de este incidente.
Antecedentes: la evolución de Kubernetes
Para entender por qué K8s "abandonó Docker", tenemos que revisar la historia del desarrollo de K8s.
Kubernetes es un marco de orquestación de infraestructura de contenedores de código abierto lanzado por Google en 2014. Esta tecnología tiene una base teórica, a saber: Borg. Borg es parte de todo el sistema de infraestructura de Google. Borg es parte de todo el sistema de infraestructura de Google. Google también ha publicado una serie de artículos sobre Borg como apoyo teórico. Lleva muchas tecnologías líderes en la industria, como MapReduce y BigTable. Por lo tanto, el sistema Borg siempre ha sido aclamado como el "arma secreta" más poderosa dentro de Google, y también es el proyecto de código abierto menos probable de Google, y Kubernetes se desarrolla sobre esta base teórica. La siguiente figura es la pila de infraestructura pública de Google descrita en el artículo de Google Omega.
La arquitectura del proyecto Kubernetes (como se muestra en la figura a continuación) es muy similar a su proyecto prototipo Borg, que consta de dos nodos, Maestro y Nodo, que corresponden a nodos de control y nodos informáticos respectivamente.
-
El nodo Master es también el nodo de control, es el centro de todo el clúster y es Stateful, es responsable de mantener el estado de todo el clúster de Kubernetes. Consta de tres componentes independientes: kube-apiserver para servicios API, kube-scheduler para programación y kube-controller-manager para orquestación de contenedores. Kube-api-server procesa los datos persistentes de todo el clúster y los almacena en Etcd. Para garantizar una responsabilidad única, el nodo maestro generalmente no implementa contenedores.
La guía de Borg para Kubernetes se refleja en el nodo maestro. Aunque los detalles de implementación de los nodos maestros de Borg y Kubernetes pueden ser diferentes, su punto de partida es el mismo, es decir, cómo organizar, administrar y programar los trabajos enviados por los usuarios.
-
El nodo Node también es el nodo informático, que es donde realmente se ejecuta el contenedor implementado. El núcleo es el componente kubelet (también habrá un componente kubelet en el nodo maestro). Kubelet es el principal responsable de manejar el tiempo de ejecución del contenedor (como el proyecto Docker) y utiliza la interfaz de llamada remota de CRI (Container interfaz de tiempo de ejecución). Esta interfaz define las operaciones principales del tiempo de ejecución del contenedor, como todos los parámetros necesarios para iniciar un contenedor. Esta es la razón por la que al proyecto de Kubernetes no le importa qué tiempo de ejecución de contenedor esté utilizando. Siempre que el tiempo de ejecución de contenedor pueda ejecutar imágenes de contenedor estándar, se puede conectar al proyecto de Kubernetes mediante la implementación de CRI.
Los tiempos de ejecución de contenedores específicos, como el proyecto Docker, generalmente interactúan con el sistema operativo Linux subyacente a través de la especificación de tiempo de ejecución del contenedor OCI, es decir, traducen las solicitudes CRI en llamadas al sistema operativo Linux, como llamar a Namespace y Cgroups.
Además, kubelet también interactúa con Device Plugin a través del protocolo gRPC. Este complemento es el componente principal utilizado por Kubernetes para administrar dispositivos host físicos como GPU. También es una función a la que se debe prestar atención para la capacitación y el aprendizaje automático. soporte de trabajo de alto rendimiento basado en proyectos de Kubernetes.
Kubelet también puede llamar complementos de red y complementos de almacenamiento para configurar la red y el almacenamiento persistente para contenedores a través de las interfaces CNI (Container Networking Interface) y CSI (Container Storage Interface), respectivamente.
El nombre kubelet proviene del componente afín Borglet en el proyecto Borg. Sin embargo, el proyecto Borg no es compatible con la tecnología de contenedores, sino que simplemente utiliza Cgroups de Linux para limitar el proceso. Esto significa que las "imágenes de contenedor" como Docker no existen en Borg, por lo que no es necesario administrar las imágenes de contenedor, pero Google usa internamente una herramienta de administración de paquetes llamada Midas Package Manager (MPM), que puede reemplazar parcialmente el rol del Imagen acoplable. Además, los componentes de Borglet no necesitan considerar cómo interactuar con Docker, ni necesitan admitir muchas interfaces de tecnología de contenedores, como CRI, CNI y CSI. Se puede decir que kubelet es un componente reimplementado para realizar las capacidades de administración de contenedores de Kubernetes y no tiene una relación de herencia directa con Borg.
El proyecto Kubernetes no usó Docker como el núcleo de toda la arquitectura como varios proyectos de "nube de contenedores" al mismo tiempo, sino que solo lo implementó como el tiempo de ejecución de contenedores de nivel más bajo. Es equivalente a ver a Docker como un nuevo método de empaquetado de aplicaciones, por lo que la experiencia anterior de Borg en la gestión y orquestación de trabajos a gran escala se puede aplicar directamente al proyecto Kubernetes.
IRC
Y en 2014, Docker estaba en su apogeo, K8s acababa de nacer y, aunque contaba con el apoyo de Google y Borg, todavía era relativamente nuevo.
Por lo tanto, K8s primero eligió admitir Docker.
Avance rápido hasta 2016, un año después de que se estableciera CNCF, y K8s también lanzó la versión 1.0, que se puede usar oficialmente en entornos de producción. Todo esto muestra que K8s ha crecido.
Así que anunció unirse a CNCF y se convirtió en el primer proyecto de hospedaje de CNCF. Quiere usar el poder de la fundación para unirse con otros fabricantes para "derrotar" a Docker.
En la versión 1.5 a finales de 2016, K8s introdujo un nuevo estándar de interfaz: CRI: interfaz de tiempo de ejecución del contenedor interfaz de tiempo de ejecución del contenedor.
CRI usa ProtoBuffer y gPRC para especificar cómo kubelet debe llamar al tiempo de ejecución del contenedor para administrar contenedores e imágenes, pero este es un nuevo conjunto de interfaces que son completamente incompatibles con las llamadas anteriores de Docker.
Obviamente, ya no quiere estar vinculado a Docker y permite el acceso a otras tecnologías de contenedores (como rkt, kata, etc.) en la capa inferior y puede "iniciar" Docker en cualquier momento.
Pero en este momento Docker está muy maduro y la inercia del mercado también es muy fuerte. Es imposible que los principales proveedores de la nube reemplacen a Docker de una sola vez.
Por lo tanto, K8s solo puede proporcionar una solución de "compromiso" al mismo tiempo, agregando un "adaptador" entre kubelet y Docker para convertir la interfaz de Docker en una interfaz compatible con CRI:
Debido a que este "adaptador" está intercalado entre kubeletDocker y Docker, se le llama acertadamente "shim", que significa "shim".
Con CRI y shim, aunque K8s todavía usa Docker como tiempo de ejecución subyacente, también tiene las condiciones para desacoplarse de Docker, abriendo así el telón del "abandono de Docker".
Contenedor
Enfrentando el desafío, Docker adoptó la estrategia de "sobrevivir con un brazo roto" para promover su propia reconstrucción, dividiendo el Docker Engine de arquitectura única original en múltiples módulos, de los cuales la parte del demonio Docker fue donada a CNCF, y se formó containerd.
Como proyecto alojado en CNCF, containerd debe cumplir con CRI. Sin embargo, debido a muchas razones, Docker solo es llamado por containerd en Docker Engine, y la interfaz externa permanece sin cambios, es decir, no es compatible con CRI.
Debido a la "terquedad" de Docker, hay dos cadenas de llamadas en K8 en este momento:
- Use la interfaz CRI para llamar a dockershim, luego dockershim llama a Docker y Docker va a containerd
para operar el contenedor. - Use la interfaz CRI para llamar directamente a containerd para operar el contenedor.
Obviamente, debido a que containerd se usa para administrar contenedores, el efecto final de las dos cadenas de llamadas es exactamente el mismo, pero el segundo método elimina los dos enlaces de dockershim y Docker Engine, que es más conciso y claro, y tiene un mejor rendimiento.
Cuando se lanzó Kubernetes 1.10 en 2018, containerd también se actualizó a la versión 1.1, se integró oficialmente con Kubernetes y se publicó una [entrada de blog](https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration -gos-ga / "publicación de blog") para mostrar algunos datos de prueba de rendimiento:
A partir de estos datos, se puede ver que, en comparación con Docker 18.03 en ese momento, el retraso de inicio de containerd1.1Pod se redujo en aproximadamente un 20 %, el uso de la CPU se redujo en un 68 % y el uso de la memoria se redujo en un 12 %. % Una mejora de rendimiento tan considerable es beneficiosa para los proveedores de la nube Es muy tentador decirlo.
Docker obsoleto
En 2020, K8s 1.20 finalmente "declara la guerra" oficialmente a Docker: kubelet dejará de ser compatible con Docker y se eliminará por completo en futuras versiones.
Pero dado que Docker se ha convertido casi en sinónimo de tecnología de contenedores, y K8s ha estado usando Docker durante años, el anuncio "olía" rápidamente a medida que se difundía, con "kubelet desaprobará el soporte de Docker" reducido a algo más llamativo "K8s desaprobará" Estibador".
Esto naturalmente causó pánico en la industria de TI, y "las personas que no sabían la verdad" expresaron su sorpresa:
Docker, que se ha utilizado durante tanto tiempo, de repente no se puede utilizar.
¿Por qué K8s trata así a Docker?
¿Se reducirá a cero la inversión anterior en Docker? ¿Qué pasa con la gran cantidad de imágenes existentes?
De hecho, si comprende los dos proyectos CRI y containerd mencionados anteriormente, sabrá que este movimiento de K8s no es sorprendente, todo es "natural": de hecho, es solo "abandonar a dockershim", es decir, dockershim Mudarse de kubelet no es un producto de software que "abandone a Docker".
Por lo tanto, "abandonar Docker" tiene poco impacto en K8 y Docker, porque han cambiado la capa inferior a un contenedor de código abierto, y las imágenes y los contenedores originales de Docker aún pueden ejecutarse normalmente. El único cambio es que K8s pasa por alto Docker y llama directamente al contenedor dentro de Docker.
Sin embargo, todavía habrá algún impacto. Si K8s usa containerd directamente para operar contenedores, entonces es un entorno de trabajo independiente de Docker, y ninguno puede acceder a los contenedores e imágenes administrados por el otro. En otras palabras, usar el comando docker ps no verá los contenedores ejecutándose en K8s.
Algunas personas pueden tardar un poco en acostumbrarse y usar la nueva herramienta crictl, pero los subcomandos para ver contenedores e imágenes siguen siendo los mismos, como ps, imágenes, etc., y no es difícil de adaptar (si tiene estado usando kubectl Manage K8s, esto no tiene ningún efecto).
K8 originalmente planeó completar el trabajo de "desaprobación de Docker" en un año, pero realmente subestimó la base de Docker. La versión 1.23 aún no pudo eliminar dockershim, por lo que tuvo que posponerse por medio año. Finalmente, la versión 1.24 eliminó el código dockershim del kubelet.
Desde entonces, Kubernetes y Docker se han "separado" por completo.
Conclusión: el futuro de Docker
Entonces, ¿qué le depara el futuro a Docker? ¿No hay lugar para ello en la era nativa de la nube? La respuesta a esta pregunta es obviamente no.
Como fundador de la tecnología de contenedores, nadie puede cuestionar el estatus histórico de Docker. Aunque K8s ya no está vinculado a Docker de forma predeterminada, Docker aún puede coexistir en otras formas de K8s.
En primer lugar, dado que el formato de la imagen del contenedor se ha estandarizado (especificación OCI, Iniciativa de contenedor abierto), la imagen de Docker todavía se puede usar normalmente en K8 y no hay necesidad de cambiar la prueba de desarrollo original y el proceso de CI/CD. Todavía podemos extraer Docker Hub o escribir un Dockerfile para empaquetar la aplicación.
En segundo lugar, Docker es una línea completa de productos de software, no solo en contenedores, sino que también incluye muchos servicios, como creación de imágenes, distribución, pruebas e incluso K8s está integrado en Docker Desktop.
En cuanto a la conveniencia del desarrollo de contenedores, Docker aún es difícil de reemplazar por el momento. La mayoría de los desarrolladores nativos de la nube pueden continuar trabajando en este entorno familiar, utilizando Docker para desarrollar aplicaciones que se ejecutan en K8.
Además, aunque K8s ya no incluye dockershim, Docker se ha hecho cargo de esta parte del código y construyó un proyecto llamado cri-dockerd, que también funciona, adaptando el Docker Engine a la interfaz CRI para que el kubelet pueda pasarlo nuevamente. Operar Docker como si nunca sucedió.
En general, aunque Docker fue derrotado en la guerra de orquestación de contenedores y K8 lo acorraló, todavía tiene una gran vitalidad. Muchos usuarios leales y una gran cantidad de imágenes de aplicaciones acumuladas a lo largo de los años son su mayor capital y respaldo. Lo suficiente como para apoyarlo en otro camino que no vaya de la mano con los K8.
Para los principiantes, Docker es fácil de usar, tiene una cadena de herramientas completa y una interfaz amigable.Es difícil encontrar un software comparable en el mercado. Se debe decir que es la "mejor opción" para la tecnología de contenedores de aprendizaje de nivel de entrada y nativa de la nube.
referencia
[¿Por qué K8s abandona Docker? 】https://mp.weixin.qq.com/s/qEKyEseD370xWI-2yIyUzg
【La queja entre Docker y k8s】https://www.cnblogs.com/powertoolsteam/p/14980851.html
【Por qué k8s abandona Docker】 https://boilingfrog.github.io/2023/01/07/por qué k8s abandona docker/
Este es el final del intercambio de hoy.
