Sou relativamente novo em tudo isso, mas estou tendo problemas para obter uma imagem clara entre as tecnologias listadas.
No entanto, todos eles tentam resolver problemas diferentes, mas também têm coisas em comum. Eu gostaria de entender o que são comuns e o que é diferente. É provável que a combinação de poucos seria ótima, se sim, quais são?
Estou listando algumas delas junto com perguntas, mas seria ótimo se alguém listasse todas elas em detalhes e respondesse às perguntas.
Kubernetes vs Mesos:
Esse link
Qual é a diferença entre o Mesos do Apache e o Kubernetes do Google
fornece uma boa visão sobre as diferenças, mas eu sou incapaz de compreender por que motivo Kubernetes deve ser executado em cima de mesos. Tem mais a ver com a união de duas soluções de código-fonte aberto?
Frota Kubernetes vs Core-OS:
Se eu usar o kubernetes, a frota é necessária?
Como o Docker-Swarm se encaixa em todos os itens acima?
Respostas:
Divulgação: Eu sou um engenheiro de liderança no Kubernetes
Penso que o Mesos e o Kubernetes têm como objetivo principal resolver problemas semelhantes de execução de aplicativos em cluster, eles têm históricos diferentes e abordagens diferentes para resolver o problema.
O Mesos concentra sua energia no agendamento muito genérico e na conexão de vários agendadores diferentes. Isso significa que ele permite que sistemas como Hadoop e Marathon coexistam no mesmo ambiente de agendamento. O Mesos está menos focado na movimentação de contêineres. Mesos existia antes do interesse generalizado em contêineres e foi re-fatorado em peças para suportar contêineres.
Por outro lado, o Kubernetes foi projetado desde o início para ser um ambiente para a criação de aplicativos distribuídos a partir de contêineres. Inclui primitivas para replicação e descoberta de serviços como primitivas principais, onde essas coisas são adicionadas por meio de estruturas no Mesos. O objetivo principal do Kubernetes é um sistema para criar, executar e gerenciar sistemas distribuídos.
A frota é um distribuidor de tarefas de nível inferior. É útil para inicializar um sistema de cluster, por exemplo, o CoreOS o usa para distribuir os agentes e binários do kubernetes para as máquinas em um cluster, a fim de ativar um cluster do kubernetes. Não se destina realmente a resolver os mesmos problemas de desenvolvimento de aplicativos distribuídos, pense mais como systemd / init.d / upstart para seu cluster. Não é necessário se você executar o kubernetes, poderá usar outras ferramentas (por exemplo, Salt, Puppet, Ansible, Chef, ...) para realizar a mesma distribuição binária.
O Swarm é um esforço do Docker para estender a API do Docker existente para fazer com que um cluster de máquinas pareça uma única API do Docker. Fundamentalmente, nossa experiência no Google e em outros lugares indica que a API do nó é insuficiente para uma API de cluster. Você pode ver várias discussões sobre isso aqui: https://github.com/docker/docker/pull/8859 e aqui: https://github.com/docker/docker/issues/8781
Espero que ajude! Junte-se a nós no IRC @ # google-containers se quiser conversar mais.
fonte
Eu acho que a resposta mais simples é que não existe uma resposta simples. A rápida ascensão ao poder dos contêineres, e o Docker em particular deixou um vácuo de poder para "agendamento e orquestração de contêineres", o que quer que isso possa significar. Na realidade, isso significa que você tem várias tecnologias que podem funcionar em harmonia em alguns níveis, mas com certos aspectos da concorrência. Por exemplo, o Kubernetes pode ser usado como um balcão único para implantar e gerenciar contêineres em um cluster de computação (como o Google o projetou originalmente), mas também pode ficar no topo do Fleet, usando o nível de resiliência que o Fleet fornece no CoreOS.
Como este vid do Google afirma, o Kubernetes não é uma solução completa de dimensionamento de contêiner pronto para uso, mas é uma boa declaração para começar. Da mesma forma, você esperaria que, em algum momento, o Apache Mesos fosse capaz de trabalhar com o Kubernetes, mas não com o Marathon, na medida em que o Marathon parece desempenhar o mesmo papel que o Kubernetes. Em algum lugar que acho que li isso pode se tornar parte do mesmo esforço, mas posso estar errado sobre isso - é realmente sobre a direção estratégica da Mesosfera e a adoção correspondente dos princípios de Kubernetes.
Na palestra do DockerCon, Solomon Hykes sugeriu que o Swarm seria uma camada que poderia fornecer uma interface comum para as muitas estruturas de orquestração e agendamento. Pelo que pude ver, o Swarm foi projetado para fornecer um fluxo de trabalho de implantação suave do Docker, trabalhando com algumas estruturas de fluxo de trabalho de contêiner existentes, como a Deis, mas flexível o suficiente para renderizar a implantação "pesada" e o gerenciamento de recursos, como o Mesos.
Espero que isso ajude - esse pode ser um post enorme. Eu acho que a chave é que esses são serviços jovens e em evolução que provavelmente se fundirão e se tornarão interoperáveis, mas precisamos seguir os próximos 12 meses para ver como ele funciona. Há pessoas muito inteligentes no problema, então o futuro parece muito brilhante.
fonte
Tanto quanto eu entendo:
Mesos, Kubernetes e Fleet estão tentando resolver um problema muito semelhante. A idéia é que você abstraia todo o seu hardware dos desenvolvedores e a 'ferramenta de gerenciamento de cluster' resolva tudo para você. Então, tudo que você precisa fazer é fornecer um contêiner para o cluster, fornecer algumas informações (mantê-lo em execução permanentemente, aumentar a escala se X acontecer, etc.) e o gerenciador de cluster fará com que isso aconteça.
Com o Mesos, ele faz todo o gerenciamento de cluster para você, mas não inclui o planejador. O agendador é o que diz: ok, esse processo precisa de 2 procs e 512 MB de RAM, e eu tenho uma máquina com esse free, então eu vou executá-la nessa máquina. Existem alguns agendadores de plugins disponíveis para o Mesos: Marathon e Chronos e você pode escrever o seu. Isso lhe dá muita capacidade de distribuição de recursos e dimensionamento de cluster, etc.
Fleet e Kubernetes parecem abstrair esses tipos de detalhes (para que você não precise escrever seu próprio agendador basicamente). Isso significa que você precisa definir suas tarefas e enviá-las no formato / maneira definida pela Fleet ou Kubernetes e, em seguida, elas assumem e agendam as tarefas (contêineres) para você.
Então eu acho: usar o Mesos pode significar um pouco mais de trabalho para escrever seu próprio agendador, mas potencialmente fornece mais flexibilidade, se necessário.
Penso que a ideia de rodar o Kubernetes no topo do Mesos é que o Kubernetes age como o agendador do Mesos. Pessoalmente, não tenho certeza de quais benefícios isso traz sobre a execução de um ou outro por conta própria (espero que alguém entre e explique!)
Como MikeB disse ... são os primeiros dias, e está tudo em disputa (fique de olho também no ECS da Amazon), por isso há muitos padrões concorrentes e muita sobreposição!
-Editar- Eu não mencionei o enxame do Docker porque não tenho muita experiência com ele.
fonte
Para quem vem depois de 2017, a frota está obsoleta. Não use mais.
Os documentos da frota dizem que "a frota não é mais desenvolvida ou mantida ativamente pelo CoreOS" e vincula-se à orquestração de contêiner: movendo-se da frota para o Kubernetes . A frota foi removida do Container Linux ( anteriormente conhecido como CoreOS Linux ) e substituída pelo Kubernetes kubelet (agente). Isso coincidiu com um pivô corporativo para oferecer a Tectonic (uma distribuição Kubernetes) como seu produto principal.
fonte