Flota Docker-Swarm, Kubernetes, Mesos y Core-OS

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?

Enumero algunas de ellas junto con preguntas, pero sería genial si alguien las enumera todas en detalle y responde las preguntas.

1. 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?

2. Flota Kubernetes vs Core-OS:

   Si uso kubernetes, ¿se requiere flota?

3. ¿Cómo encaja Docker-Swarm en todo lo anterior?

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 en enchufar 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 centrales, 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 usa 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 parezca una sola API de Docker. Fundamentalmente, 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.

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 resiliencia 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. Del mismo modo, 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 de "peso pesado" 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.

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 funcionando permanentemente, escalar si sucede 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 programador 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 planificador 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 ... es temprano, 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.

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.