services - Tecnologías de contenedores: docker, rkt, orchestration, kubernetes, GKE y AWS Container Service

eks aws (2)

Estoy tratando de entender bien las tecnologías de contenedores pero estoy algo confundido. Parece que ciertas tecnologías se superponen a diferentes partes de la pila y se pueden usar diferentes piezas de diferentes tecnologías según lo considere adecuado el equipo de DevOps (por ejemplo, puede usar contenedores Docker pero no tiene que usar el motor Docker, podría usar el motor del proveedor de la nube en lugar). Mi confusión radica en comprender qué proporciona cada capa de la "Pila de contenedores" y quiénes son los proveedores clave de cada solución.

Aquí está la comprensión de mi laico; agradecería cualquier corrección y retroalimentación sobre los agujeros en mi entendimiento

Contenedores: paquete independiente que incluye la aplicación, el entorno de ejecución, las bibliotecas del sistema, etc .; como un mini-OS con una aplicación
- Parece que Docker es el estándar de facto. ¿Algún otro que sea notable y ampliamente utilizado?
Clústeres de contenedores: grupos de contenedores que comparten recursos
Motor de contenedores: agrupa contenedores en grupos, gestiona recursos
Orquestador: ¿es esto diferente de un motor de contenedor? ¿Cómo?
- ¿Dónde se encuentran Docker Engine, rkt, Kubernetes, Google Container Engine, AWS Container Service, etc. entre los números 2-4?

@iamnat proporcionó una explicación realmente agradable y concisa. Déjame intentar explicarte un poco más en detalle desde los primeros principios. Esto puede ser un poco largo y presentar una simplificación excesiva, pero debería ser suficiente para transmitir la idea.

Maquinas fisicas

Hace algún tiempo, la mejor manera de implementar aplicaciones simples era simplemente comprar un nuevo servidor web, instalar su sistema operativo favorito y ejecutar las aplicaciones allí.

Los contras de este modelo son:

Los procesos pueden interferir entre sí (porque comparten recursos de la CPU y del sistema de archivos), y uno puede afectar el rendimiento del otro.
También es difícil escalar este sistema hacia arriba / abajo, ya que requiere mucho esfuerzo y tiempo para configurar una nueva máquina física.
Puede haber diferencias en las especificaciones de hardware, las versiones del sistema operativo / kernel y las versiones de paquetes de software de las máquinas físicas, lo que dificulta la gestión de estas instancias de aplicaciones de una manera independiente del hardware.

Las aplicaciones, que se ven afectadas directamente por las especificaciones físicas de la máquina, pueden necesitar ajustes específicos, recompilación, etc., lo que significa que el administrador del clúster debe considerarlas como instancias a nivel de máquina individual. Por lo tanto, este enfoque no se escala. Estas propiedades hacen que sea indeseable para desplegar aplicaciones de producción modernas.

Maquinas virtuales

Las máquinas virtuales resuelven algunos de los problemas de los anteriores:

Proporcionan aislamiento incluso mientras se ejecutan en la misma máquina.
Proporcionan un entorno de ejecución estándar (el sistema operativo invitado) independientemente del hardware subyacente.
Se pueden criar en una máquina diferente (replicar) con bastante rapidez al escalar (en orden de minutos).
Normalmente, las aplicaciones no necesitan ser revisadas para pasar de hardware físico a máquinas virtuales.

Pero introducen algunos problemas propios:

Consumen grandes cantidades de recursos al ejecutar una instancia completa de un sistema operativo.
Es posible que no comiencen / bajen tan rápido como queremos (orden de segundos).
Incluso con la virtualización asistida por hardware, las instancias de la aplicación pueden ver una degradación significativa del rendimiento en una aplicación que se ejecuta directamente en el host. (Esto puede ser un problema solo para ciertos tipos de aplicaciones)
Empaquetar y distribuir imágenes de máquinas virtuales no es tan simple como podría ser. (Esto no es tanto un inconveniente del enfoque, como lo es de las herramientas existentes para la virtualización).

Contenedores

Luego, en algún lugar a lo largo de la línea, se agregaron cgroups (grupos de control) al kernel de Linux. Esta función nos permite aislar procesos en grupos, decidir qué otros procesos y sistema de archivos pueden ver y realizar la contabilidad de recursos a nivel de grupo.

Surgieron varios tiempos de ejecución de contenedores y motores que facilitan el proceso de creación de un "contenedor", un entorno dentro del sistema operativo, como un espacio de nombres que tiene visibilidad limitada, recursos, etc., muy fácil. Ejemplos comunes de estos incluyen docker, rkt, runC, LXC, etc.

Docker, por ejemplo, incluye un demonio que proporciona interacciones como crear una "imagen", una entidad reutilizable que puede lanzarse en un contenedor de manera instantánea. También permite gestionar contenedores individuales de forma intuitiva.

Las ventajas de los contenedores:

Son ligeros y se ejecutan con muy poca sobrecarga, ya que no tienen su propia instancia del kernel / OS y se ejecutan sobre un solo sistema operativo host.
Ofrecen cierto grado de aislamiento entre los distintos contenedores y la capacidad de imponer límites a los diversos recursos que consumen (utilizando el mecanismo cgroup).
La herramienta a su alrededor ha evolucionado rápidamente para permitir la construcción fácil de unidades reutilizables (imágenes), repositorios para almacenar revisiones de imágenes (registros de contenedores), etc., en gran parte debido a la ventana acoplable.
Se recomienda que un solo contenedor ejecute un solo proceso de solicitud para mantenerlo y distribuirlo de manera independiente. La naturaleza liviana de un contenedor lo hace preferible, y lleva a un desarrollo más rápido debido al desacoplamiento.

También hay algunos inconvenientes:

El nivel de aislamiento proporcionado es inferior al de las máquinas virtuales.
Son más fáciles de usar con las aplicaciones de 12-factor sin estado 12-factor se crean de nuevo y una pequeña dificultad si se intenta implementar aplicaciones heredadas, bases de datos distribuidas en clústeres, etc.
Necesitan la orquestación y primitivos de nivel superior para ser utilizados con eficacia y en escala.

Orquestación de contenedores

Cuando se ejecutan aplicaciones en producción, a medida que aumenta la complejidad, tiende a tener muchos componentes diferentes, algunos de los cuales aumentan o disminuyen la escala según sea necesario, o pueden ser escalados. Los contenedores en sí mismos no resuelven todos nuestros problemas. Necesitamos un sistema que resuelva los problemas asociados con aplicaciones reales a gran escala, tales como:

Redes entre contenedores
Balanceo de carga
Gestionar el almacenamiento adjunto a estos contenedores.
Actualizar contenedores, escalarlos, distribuirlos a través de nodos en un clúster de múltiples nodos, etc.

Cuando queremos administrar un grupo de contenedores, usamos un motor de orquestación de contenedores. Ejemplos de estos son Kubernetes, Mesos, Docker Swarm, etc. Proporcionan una gran cantidad de funciones además de las enumeradas anteriormente y el objetivo es reducir el esfuerzo involucrado en los dev-ops.

GKE (Google Container Engine) está alojado Kubernetes en Google Cloud Platform. Permite que un usuario simplemente especifique que necesita un clúster kubernetes de n nodos y expone el clúster como una instancia administrada. Kubernetes es de código abierto y, si uno quisiera, también podría configurarlo en Google Compute Engine, un proveedor de nube diferente o sus propias máquinas en su propio centro de datos.

ECS es un sistema patentado de administración / orquestación de contenedores creado y operado por Amazon y disponible como parte de la suite AWS.

Para responder a sus preguntas específicamente:

Motor Docker: una herramienta para administrar el ciclo de vida de un contenedor y las imágenes de la ventana acoplable. Crear, reiniciar, eliminar contenedores docker. Crea, renombra, borra imágenes docker.
rkt: análogo al motor de la ventana acoplable, pero implementación diferente
Kubernetes: una colección de herramientas para administrar el ciclo de vida de una aplicación distribuida que usa contenedores. Contiene herramientas para administrar contenedores, grupos de contenedores, configuración de contenedores, orquestación de contenedores, programación en instancias reales, herramientas para ayudar a los desarrolladores a escribir y mantener otros servicios / herramientas para tratar con contenedores.
Google Container Engine: en lugar de obtener máquinas virtuales, instale el "docker-engine" en ellas, instale kubernetes en ellas y haga que todo funcione con los permisos adecuados para su infraestructura, etc. Imagine si todo se unió para que pueda elegir. los tipos de máquinas y el tamaño de su clúster que tiene todo esto simplemente funcionando. Cosas como extraer imágenes del repositorio de la ventana acoplable específica del proyecto (registro de contenedor de Google) o reclamar volúmenes persistentes, o aprovisionar balanceadores de carga solo funcionan sin preocuparse por las cuentas de servicio y los permisos, y qué no.
ECS: Análogo a GKE (4) pero sin Kubernetes.

Para abordar los puntos en su comprensión: tiene poca razón sobre las cosas (excepto el motor del contenedor, creo). Es importante comprender que lo único importante que hay que entender es qué es un contenedor. El resto es solo marketing / nombres de productos. También es importante entender que la comprensión actual de los contenedores está muy distorsionada por lo que son los contenedores Docker y muchas de las opiniones aplicadas por Docker y las herramientas en torno a Docker. Los contenedores han existido durante mucho tiempo.

Entonces, una vez que entienda qué es un contenedor (acoplable), un motor de contenedor es solo una herramienta para administrarlos, un grupo de contenedores es solo un grupo de contenedores, un orquestador es solo una herramienta para administrar dónde se ejecutan los contenedores según algunos parámetros. En mi humilde opinión, realmente no necesita preocuparse demasiado por lo que el resto de las herramientas es una vez que comprende y construye un modelo mental sólido alrededor de los contenedores. El resto se ajustará automáticamente.

¿La mejor manera de entender todo esto? Cree e implemente una aplicación bastante compleja con Docker (datos persistentes / use una base de datos en su aplicación) y todo tendrá sentido.