cluster computing - tutorial - Flota Docker-Swarm, Kubernetes, Mesos y Core-OS

kubernetes tutorial (4)

Creo que la respuesta más simple es que no hay una respuesta simple. El rápido ascenso al poder de los contenedores, y Docker en particular ha dejado un vacío de poder para la "programación y orquestación de contenedores", sea lo que sea que eso signifique. En realidad, eso significa que tiene una serie de tecnologías que pueden funcionar en armonía en algunos niveles, pero con ciertos aspectos en la competencia. Por ejemplo, Kubernetes se puede usar como una ventanilla única para implementar y administrar contenedores en un clúster de cómputo (como Google lo diseñó originalmente), pero también podría sentarse encima de Fleet, haciendo uso del nivel de resistencia que Fleet proporciona en CoreOS.

Como este video de Google dice que Kubernetes no es una solución completa de escalado de contenedores, es una buena declaración para comenzar. De la misma manera, en algún momento esperaría que Apache Mesos pudiera trabajar con Kubernetes, pero no con Marathon, en la medida en que Marathon parece cumplir el mismo papel que Kubernetes. Creo que en algún lugar he leído que esto podría formar parte del mismo esfuerzo, pero podría estar equivocado al respecto: en realidad se trata de la dirección estratégica de la Mesosfera y la adopción correspondiente de los principios de Kubernetes.

En la nota clave de DockerCon, Solomon Hykes sugirió que Swarm sería un nivel que podría proporcionar una interfaz común en los muchos marcos de orquestación y programación. Por lo que puedo ver, Swarm está diseñado para proporcionar un flujo de trabajo de implementación de Docker sin problemas, trabajando con algunos marcos de flujo de trabajo de contenedores existentes como Deis, pero lo suficientemente flexible como para ceder a la implementación "pesada" y la gestión de recursos como Mesos.

Espero que esto ayude, esta podría ser una publicación enorme. Creo que la clave es que estos son servicios jóvenes y en evolución que probablemente se fusionarán y se volverán interoperables, pero tenemos que salir de los próximos 12 meses para ver cómo se desarrolla. Hay algunas personas muy inteligentes en el problema, por lo que el futuro parece muy brillante.

Soy relativamente nuevo en todo esto, pero tengo problemas para obtener una imagen clara entre las tecnologías enumeradas.

Sin embargo, todos estos intentan resolver diferentes problemas, pero también tienen cosas en común. Me gustaría entender cuáles son las cosas comunes y las diferentes. Es probable que la combinación de pocos encajaría bien, de ser así, ¿cuáles son?

Estoy enumerando algunos de ellos junto con preguntas, pero sería genial si alguien los enumera todos en detalle y responde las preguntas.

Kubernetes vs Mesos:

Este enlace

¿Cuál es la diferencia entre el Mesos de Apache y los Kubernetes de Google?

proporciona una buena idea de las diferencias, pero no puedo entender por qué Kubernetes debería correr sobre Mesos. ¿Tiene más que ver con la unión de dos soluciones de código abierto?
Flota Kubernetes vs Core-OS:

Si uso kubernetes, ¿se requiere flota?
¿Cómo encaja Docker-Swarm en todo lo anterior?

Para cualquiera que venga a esto después de 2017, la flota está en desuso. No lo uses más.

Los documentos de la flota dicen que "la flota ya no es desarrollada o mantenida activamente por CoreOS" y se vinculan a la orquestación de contenedores: pasar de la flota a Kubernetes . La flota se eliminó de Container Linux ( anteriormente conocido como CoreOS Linux ) y se reemplazó con Kubernetes kubelet (agente). Esto coincidió con un pivote corporativo para ofrecer Tectonic (una distribución de Kubernetes) como su producto principal.

Por lo que yo entiendo:

Mesos, Kubernetes y Fleet están tratando de resolver un problema muy similar. La idea es que abstraiga todo su hardware de los desarrolladores y la ''herramienta de administración de clúster'' lo resuelva por usted. Entonces, todo lo que necesita hacer es darle un contenedor al clúster, darle información (mantenerlo ejecutándose permanentemente, escalar si ocurre X, etc.) y el administrador del clúster lo hará posible.

Con Mesos, realiza toda la administración del clúster por usted, pero no incluye el programador. El planificador es el bit que dice, ok, este proceso necesita 2 procesos y 512 MB de RAM, y tengo una máquina allí con eso gratis, así que lo ejecutaré en esa máquina. Hay algunos programadores de complementos disponibles para Mesos: Marathon y Chronos y puede escribir el suyo. Esto le da mucho poder de distribución de recursos y escalamiento de clúster, etc.

Fleet y Kubernetes parecen abstraer ese tipo de detalles (por lo que no tiene que escribir su propio planificador básicamente). Esto significa que debe definir sus tareas y enviarlas en el formato / forma definidos por Fleet o Kubernetes y luego se hacen cargo y programan las tareas (contenedores) por usted.

Entonces, supongo: usar Mesos puede significar un poco más de trabajo para escribir su propio planificador, pero potencialmente proporciona más flexibilidad si es necesario.

Creo que la idea de ejecutar Kubernetes sobre Mesos es que Kubernetes actúa como el programador de Mesos. Personalmente, no estoy seguro de los beneficios que esto conlleva correr uno u otro por sí solo (¡espero que alguien intervenga y explique!)

Como dijo MikeB ... son los primeros días, y todo está en juego (vigile también el ECS de Amazon), ¡así que hay muchos estándares competitivos y mucha superposición!

-editar- No mencioné el enjambre de Docker ya que realmente no tengo mucha experiencia con él.

Divulgación: soy ingeniero principal en Kubernetes

Creo que Mesos y Kubernetes apuntan en gran medida a resolver problemas similares de ejecución de aplicaciones agrupadas, tienen diferentes historias y diferentes enfoques para resolver el problema.

Mesos enfoca su energía en una programación muy genérica y conectando múltiples programadores diferentes. Esto significa que permite que sistemas como Hadoop y Marathon coexistan en el mismo entorno de programación. Mesos está menos enfocado en ejecutar contenedores. Mesos existía antes del interés generalizado en contenedores y se ha refactorizado en partes para soportar contenedores.

En contraste, Kubernetes fue diseñado desde cero para ser un entorno para construir aplicaciones distribuidas a partir de contenedores. Incluye primitivas para la replicación y el descubrimiento de servicios como primitivas básicas, donde, como tales, se agregan a través de marcos en Mesos. El objetivo principal de Kubernetes es un sistema para construir, ejecutar y administrar sistemas distribuidos.

Fleet es un distribuidor de tareas de nivel inferior. Es útil para iniciar un sistema de clúster, por ejemplo, CoreOS lo utiliza para distribuir los agentes y binarios de kubernetes a las máquinas en un clúster para activar un clúster de kubernetes. Realmente no está destinado a resolver los mismos problemas de desarrollo de aplicaciones distribuidas, piense más como systemd / init.d / upstart para su clúster. No es necesario si ejecuta kubernetes, puede usar otras herramientas (por ejemplo, Salt, Puppet, Ansible, Chef, ...) para lograr la misma distribución binaria.

Swarm es un esfuerzo de Docker para ampliar la API de Docker existente para hacer que un grupo de máquinas se vea como una sola API de Docker. Básicamente, nuestra experiencia en Google y en otros lugares indica que la API de nodo es insuficiente para una API de clúster. Puede ver un montón de discusión sobre esto aquí: https://github.com/docker/docker/pull/8859 y aquí: https://github.com/docker/docker/issues/8781

¡Espero que ayude! Únase a nosotros en IRC @ # google-container si desea hablar más.