Los orquestadores de contenedores se presentan

Hola a todos, soy Xianyu

Xianyu presentó el origen de la tecnología de contenedores y el desarrollo del proyecto Docker en " Un artículo lo lleva a comprender el pasado y el presente de la tecnología de contenedores".

Sabemos que Docker y otras tecnologías de contenedores pueden simplificar enormemente la implementación de aplicaciones y lograr "listos para usar"

Como dice el dicho: "todo tiene dos caras". Si bien la tecnología de contenedores nos brinda comodidad, también surgen algunos problemas

Con la expansión continua de la escala empresarial o la escala empresarial, cada vez hay más aplicaciones, y cada aplicación a menudo se compone de varios contenedores.

Por ejemplo, si desea implementar una interfaz web de base de datos simple, es posible que también deba ejecutar contenedores separados para el servidor de la base de datos y la aplicación.

Por lo que la gestión de los contenedores se ha convertido en un problema espinoso. Para solucionar este problema, los ingenieros han desarrollado una serie de contenedores orquestadores (container orquestator), el más famoso de los cuales es kubernetes

El orquestador de contenedores puede administrar un grupo de contenedores como una unidad básica (como un pod en K8), y el orquestador de contenedores puede distribuir automáticamente la carga de trabajo del contenedor entre los clústeres.

Así que hoy, Xianyu le presentará a tres organizadores de contenedores en forma de presentación personal: Docker Compose, Swarm, Kubernetes.

Componer ventana acoplable

Hola a todos, mi nombre es Docker Compose. Mi papá es una empresa llamada Docker

Mi predecesor fue un proyecto llamado Fig. El proyecto Fig tiene muchos antecedentes, porque primero propuso el concepto de disposición de contenedores.

Solo necesita ejecutar un comando fig uppara crear una serie de contenedores en secuencia, y la relación y las dependencias entre los contenedores se resolverán automáticamente.

En ese momento, su popularidad en Github era comparable a la de Docker. Más tarde, mi padre se adhirió al concepto de "únete si no puedes vencerlo" y adquirió el proyecto Fig.

Después de la adquisición cambió el nombre a Compose y nací

Trabajo desde un archivo de configuración en formato yaml, generalmente llamado Docker-compose.yml:

• Primero, leeré este archivo y luego crearé los recursos declarados por este archivo a través de la API de Docker
• También etiqueto estos recursos para poder organizarlos en grupos después de crearlos.

De hecho, no se me puede llamar un orquestador de contenedores, porque en realidad opero un grupo de contenedores a través de la interfaz de línea de comandos de Docker (interfaz de línea de comandos de Docker)

Por ejemplo, digamos que hay tres tipos de recursos en el archivo de configuración:

• servicio: Contiene la declaración del contenedor a iniciar. Cada entrada dentro es equivalente a un Docker runcomando
• redes: contiene las redes que pueden acceder al contenedor. Cada entrada dentro es equivalente a un Docker network createcomando
• volúmenes: contiene volúmenes de contenedor a los que se puede acceder dentro del contenedor (los volúmenes de contenedor son almacenamiento persistente que se puede montar dentro del contenedor). Cada entrada dentro es equivalente a un Docker vloume create comando

Aún así, pude administrar las dependencias entre contenedores bastante bien y pude crear una red y un volumen compartidos para los contenedores para que pudieran comunicarse entre sí y compartir datos.

Pero no puedo lograr una alta disponibilidad del contenedor. Si el contenedor falla, debe recuperarse manualmente

Enjambre

Hola a todos, mi nombre es Swarm

Docker Compose Aunque proporciona una forma conveniente para que todos administren contenedores, al principio solo puede funcionar en un solo host

Es decir, todos los contenedores que creó se ejecutan en la misma máquina. Independientemente del rendimiento, si todas las aplicaciones están en un servidor, si el servidor se cae, las consecuencias serán desastrosas.

Para resolver este problema, ya en 2014, mi hermano Classic Swarm (https://github.com/Docker-archive/classicswarm) comenzó a proporcionar una solución para ejecutar contenedores en hosts, pero a mi padre no le importaba. sobre eso poco después Ya no se mantiene en la comunidad.

Llegó el momento de 2016, nací

En comparación con mi hermano mayor, Classic Swarm, estoy integrado directamente en Docker

No solo eso, puedo proporcionar funciones más potentes y un mejor rendimiento, descubrimiento de servicios de soporte, equilibrio de carga, actualización continua y otras funciones.

Al crear un clúster, solo necesito ejecutar Docker swarm initel comando y luego ejecutar Docker swarm joinel comando en cada otro nodo para agregarlo al clúster.

¿Qué tal, no es muy conveniente?

Los amigos pueden estar más preocupados por cómo administro el clúster. Primero, dividiré los nodos del clúster en dos categorías:

• Nodos de administrador

El nodo de gestión proporciona una API a través de la cual se puede iniciar el contenedor.

Además, los nodos de gestión utilizan el protocolo basado en el algoritmo de consenso de Raft para comunicarse entre sí , lo cual es conveniente para sincronizar el estado del clúster y lograr una alta disponibilidad y consistencia de datos.

• Nodos trabajadores

El nodo de trabajo, como su nombre lo indica, es el nodo responsable del trabajo. Son responsables de realizar el trabajo real del contenedor.

Y mi papá me dijo que los nodos de administración solo se pueden configurar hasta siete, pero la cantidad de nodos de trabajo no está limitada

Aunque soy tan capaz, en realidad tengo algunas deficiencias.Después de todo, no existe una herramienta perfecta.

Desventaja 1: el almacenamiento compartido entre nodos no se puede realizar en el clúster

Aunque admito la comunicación de red entre nodos en el clúster (mediante el método de puente), no puedo admitir el almacenamiento compartido entre nodos. Tengo que confiar en complementos de volumen de terceros para lograr

Desventaja 2: es difícil distinguir entre un archivo de pila y un archivo de composición

Desde que me integré en Docker Engine, descubrí que puedo implementar servicios a través de archivos de composición (implementar servicios, volúmenes y otros recursos)

Y como todos saben, el archivo de composición fue utilizado originalmente por Docker Compose

Echemos un vistazo a la comparación, podemos ver que el uso es muy similar.

Docker-compose -f Docker-compose up

Docker stack deploy -c Docker-compose.yml somestackname

Pero, de hecho, utilizo el archivo de pila para la implementación del clúster. El archivo de pila también es un archivo en formato YML, que es muy similar al archivo de composición.

Esto hará que algunos principiantes no sepan si usar el archivo de pila o el archivo de composición al aprender, puede ver el siguiente problema

https://stackoverflow.com/questions/43099408/cuál es-la-diferencia-entre-un-archivo-de-pila-y-un-archivo-compuesto

PD: en términos generales, la sintaxis y las funciones de Stack file y Compose file son muy similares, y ambos se pueden usar para definir e implementar múltiples servicios o contenedores.

Sin embargo, los archivos Stack son más adecuados para administrar servicios en entornos de producción, mientras que los archivos Compose son más adecuados para administrar contenedores en entornos de desarrollo y prueba.

Además, el archivo Stack también admite algunas funciones que el archivo Compose no admite, como el descubrimiento de servicios, el equilibrio de carga, la actualización continua, etc.

Mi vida orgánica no es todo fácil, solía ser la columna vertebral de Docker Cloud, pero Docker Cloud se cerró en 2018

No solo eso, sino que mi posición se ve constantemente amenazada a medida que se desarrolla el competidor Kubernetes. Hasta 2019, mi padre anunció que detendría mi desarrollo y mantenimiento y se centraría en Kubernetes.

Se puede decir: "Si subes, no podrás subir, y si pierdes fuerza, caerás mil pies y serás fuerte".

Kubernetes

Hola a todos, mi nombre es Kubernetes. Para mayor comodidad, puedes llamarme K8s

Estoy seguro de que todos han oído hablar de mí como, con mucho, el orquestador de contenedores más popular, capaz de administrar y distribuir recursos en clústeres de hasta miles de nodos.

Permítanme estar orgulloso. Mi posición en el orquestador de contenedores es equivalente a la posición de Google en el motor de búsqueda. Se puede decir que domino la orquestación de contenedores.

Pero puedo estar donde estoy hoy, en parte gracias a que mi padre es Google y en parte gracias al apoyo de Cloud Native Computing Foundation (CNCF)

De 2014 a 2015, toda la comunidad de contenedores estuvo muy animada. Pero detrás de la bulliciosa escena están las preocupaciones y el descontento de muchas personas.

En ese momento, el proyecto Docker se había convertido en un producto comercial de la empresa Docker. En ese momento, mi padre encontró la empresa Docker y esperaba cooperar con Docker, pero el duro Docker sintió que esto debilitaría su posición y rechazó la solicitud.

Además, Docker siempre ha mantenido una autoridad y una voz absolutas en el desarrollo del proyecto de código abierto de Docker, y ha desafiado los intereses vitales de otros jugadores (como CoreOS, RedHat e incluso mi padre y Microsoft) con acciones prácticas en muchas ocasiones.

Así que estos gigantes en el campo de la infraestructura de código abierto y mi padre lanzaron una fundación llamada CNCF (Cloud Native Computing Foundation)

El propósito de esta fundación es construir una comunidad a nivel de plataforma liderada por proveedores en el campo de la infraestructura de código abierto y operada como una fundación independiente basada en el proyecto Kubernetes, para luchar contra el ecosistema empresarial de contenedores centrado en Docker.

Así que en ese momento nací yo. Mi antecesor fue Borg (una herramienta interna de Google)

Si ha visto los primeros problemas y funciones de GitHub del proyecto Kubernetes, descubrirá que la mayoría de ellos provienen de las funciones internas de los sistemas Borg y Omega. Estas funciones pertenecen al proyecto Kubernetes, es decir, Pod, Sidecar y otras. funciones y patrones de diseño

Cuando recién nací, mucha gente se quejó porque la operación era demasiado complicada.

Si desea configurar el clúster, además de mí, también debe seleccionar y configurar algunos componentes de terceros. Esto es lo mismo que el kernel de Linux necesita combinarse con GNU para formar un sistema operativo completo.Solo soy un orquestador y necesito combinarme con otro software para formar un clúster completo.

Todavía recuerdo la fundación CNCF mencionada anteriormente. No, RedHat también está en ella. Me movió su conjunto de juego.

Al igual que una distribución de Linux, agrego instaladores y otros componentes de terceros cuidadosamente seleccionados en una distribución de K8s

Con la distribución de K8, tienes muchas menos quejas sobre mí.

No solo eso, mi padre comenzó a promover enérgicamente el cambio de "democratización" en la comunidad K8, es decir, en cada capa, desde la API hasta el tiempo de ejecución del contenedor, el proyecto Kubernetes expone un mecanismo de complemento extensible para desarrolladores, alentando a los usuarios a código de acceso Maneras de involucrarse en cada etapa del proyecto Kubernetes

El efecto de este cambio de democratización es enorme y generó rápidamente una gran cantidad de innovaciones secundarias basadas en la API de Kubernetes y las interfaces de extensión en toda la comunidad de contenedores.

A medida que sigo creciendo y expandiéndome, la empresa Docker tiene que enfrentarse a la realidad de que está a punto de fracasar. A partir de 2017, la empresa Docker donó por primera vez Containerd, la parte del tiempo de ejecución de contenedores del proyecto Docker, a la comunidad CNCF.

Luego, en octubre, la compañía Docker anunció inesperadamente que I se integraría en su producto estrella Docker Enterprise Edition, lo que marcó el final de esta vigorosa "guerra de arreglos".

Si Docker hubiera elegido cooperar con mi padre, ¿cómo sería el ecosistema de contenedores actual?

Enlace de referencia para este artículo: https://lwn.net/Articles/905164/#t