TOC

Mesos vs. Kubernetes

Mesos vs. Kubernetes

1. Visão geral

Neste tutorial, entenderemos a necessidade básica de um sistema de orquestração de contêineres.

Vamos avaliar a característica desejada de tal sistema. A partir daí, tentaremos comparar dois dos mais populares sistemas de orquestração de contêineres em uso hoje,Apache MesoseKubernetes.

2. Orquestração de contêineres

Antes de começarmos a comparar Mesos e Kubernetes, vamos dedicar algum tempo para entender o que são contêineres e por que, afinal, precisamos da orquestração de contêineres.

2.1. Containers

Acontainer is a standardized unit of software that packages code and all its required dependencies.

Portanto, fornece independência de plataforma e simplicidade operacional. O Docker é uma das plataformas de contêiner mais populares em uso.

Docker aproveita o kernel Linuxfeatures like CGroups and namespaces to provide isolation de diferentes processos. Portanto, vários contêineres podem ser executados de forma independente e segura.

É bastante trivial criar imagens docker, tudo o que precisamos é um Dockerfile: 

FROM openjdk:8-jdk-alpine
VOLUME /tmp
COPY target/hello-world-0.0.1-SNAPSHOT.jar app.jar
ENTRYPOINT ["java","-jar","/app.jar"]
EXPOSE 9001

Portanto, essas poucas linhas são boas o suficiente para criar uma imagem do Docker de um aplicativo Spring Boot usando a CLI do Docker: 

docker build -t hello_world .

2.2. Orquestração de contêineres

Então, vimos como os contêineres podem tornar a implantação de aplicativos confiável e repetível. Mas por que precisamos da orquestração de contêineres?

Agora, embora tenhamos alguns contêineres para gerenciar, estamos bem com Docker CLI. Também podemos automatizar algumas tarefas simples. Maswhat happens when we’ve to manage hundreds of containers?

Por exemplo, pense na arquitetura com vários microsserviços, todos com requisitos distintos de escalabilidade e disponibilidade.

Consequentemente, as coisas podem sair rapidamente do controle, e é aí que os benefícios de um sistema de orquestração de contêiner são percebidos. Acontainer orchestration system treats a cluster of machines with a multi-container application as a single deployment entity. Ele fornece automação desde a implantação inicial, agendamento, atualizações para outros recursos, como monitoramento, dimensionamento e failover.

3. Breve Visão Geral do Mesos

Apache Mesos éan open-source cluster manager developed originally at UC Berkeley. Ele fornece aplicativos com APIs para gerenciamento e agendamento de recursos em todo o cluster. O Mesos nos dá a flexibilidade de executar a carga de trabalho em contêiner e não em contêiner de maneira distribuída.

3.1. Arquitetura

A arquitetura do Mesos consiste em Mesos Master, Mesos Agent e Application Frameworks:

image

Vamos entender os componentes da arquitetura aqui:

  • Frameworks: sãothe actual applications that require distributed execution de tarefas ou carga de trabalho. Exemplos típicos são Hadoop ouStorm. As estruturas no Mesos são compostas por dois componentes principais:

    • Scheduler: Este éresponsible for registering with the Master Node para que o mestre possa começar a oferecer recursos

    • Executor: Este éthe process which gets launched on the agent nodes para executar as tarefas do framework

  • Mesos Agents: Sãoresponsible for actually running the tasks. Cada agente publica seus recursos disponíveis, como CPU e memória, no mestre. Ao receber tarefas do mestre, eles alocam os recursos necessários para o executor da estrutura.

  • Mesos Master: éresponsible for scheduling tasks received from the Frameworks em um dos nós de agente disponíveis. O mestre faz ofertas de recursos para estruturas. O planejador do Framework pode escolher executar tarefas nesses recursos disponíveis.

3.2. Maratona

Como acabamos de ver, Mesos é bastante flexível eallows frameworks to schedule and execute tasks por meio de APIs bem definidas. No entanto, não é conveniente implementar essas primitivas diretamente, especialmente quando queremos agendar aplicativos personalizados. Por exemplo, orquestrando aplicativos empacotados como contêineres.

É aqui que uma estrutura comoMarathon pode nos ajudar. Maratonais a container orchestration framework which runs on Mesos. A esse respeito, Marathon atua como uma estrutura para o cluster Mesos. O Marathon oferece vários benefícios que normalmente esperamos de uma plataforma de orquestração como APIs de descoberta de serviços, balanceamento de carga, métricas e gerenciamento de contêineres.

Marathontreats a long-running service as an applicatione uma instância do aplicativo como uma tarefa. Um cenário típico pode ter vários aplicativos com dependências formando o que é chamado deApplication Groups.

3.3. Exemplo

Então, vamos ver como podemos usar o Marathon para implantar nossa imagem simples do Docker que criamos anteriormente. Observe que a instalação de um cluster Mesos pode ser um pouco complicada e, portanto, podemos usar uma solução mais direta comoMesos Mini. O Mesos Mini permite ativar um cluster local do Mesos em um ambiente Docker. Inclui um Mesos Master, um único Mesos Agent e Marathon.

Assim que tivermos o cluster Mesos com o Marathon instalado e funcionando, podemos implantar nosso contêiner como um serviço de aplicativo de longa duração. Tudo o que precisamos de uma pequena definição de aplicativo JSON: 

#hello-marathon.json
{
  "id": "marathon-demo-application",
  "cpus": 1,
  "mem": 128,
  "disk": 0,
  "instances": 1,
  "container": {
    "type": "DOCKER",
    "docker": {
      "image": "hello_world:latest",
      "portMappings": [
        { "containerPort": 9001, "hostPort": 0 }
      ]
    }
  },
  "networks": [
    {
      "mode": "host"
    }
  ]
}

Vamos entender o que exatamente está acontecendo aqui:

  • Fornecemos um ID para nossa aplicação

  • Em seguida, definimos os requisitos de recursos para nosso aplicativo

  • Também definimos quantas instâncias gostaríamos de executar

  • Em seguida, fornecemos os detalhes do contêiner para iniciar um aplicativo a partir de

  • Por fim, definimos o modo de rede para que possamos acessar o aplicativo

Podemos iniciar esse aplicativo usando as APIs REST fornecidas pela Marathon: 

curl -X POST \
  http://localhost:8080/v2/apps \
  -d @hello-marathon.json \
  -H "Content-type: application/json"

4. Breve visão geral do Kubernetes

Kubernetes éan open-source container orchestration system initially developed by Google. Agora faz parte deCloud Native Computing Foundation (CNCF). Ele fornece uma plataforma para automatizar a implantação, dimensionamento e operações do contêiner de aplicativos em um cluster de hosts.

4.1. Arquitetura

A arquitetura Kubernetes consiste em um Kubernetes Master e nós Kubernetes:

image

Vamos examinar as principais partes dessa arquitetura de alto nível:

  • Kubernetes Master: Omaster is responsible for maintaining the desired state of the cluster. Ele gerencia todos os nós no cluster. Como podemos ver, o mestre é uma coleção de três processos:

    • kube-apiserver: éthe service that manages the entire cluster, incluindo o processamento de operações REST, validação e atualização de objetos Kubernetes, realização de autenticação e autorização

    • kube-controller-manager: trata-se dethe daemon that embeds the core control loop enviado com o Kubernetes, fazendo as alterações necessárias para corresponder o estado atual ao estado desejado do cluster

    • kube-scheduler: este serviçowatches for unscheduled pods and binds them to nodes dependendo dos recursos solicitados e outras restrições

  • Kubernetes Nodes: os nós em um cluster Kubernetes são as máquinas que executam nossos contêineres. Cada nó contém os serviços necessários para executar os contêineres:

    • kubelet: éthe primary node agent, o que garante que os contêineres descritos em PodSpecs fornecidos porkube-apiserver estejam em execução e íntegros

    • kube-proxy: Este éthe network proxy running on each nodee executa TCP, UDP, encaminhamento de fluxo SCTP simples ou encaminhamento round-robin em um conjunto de back-ends

    • container runtime: éthe runtime where container inside the pods are run, há vários tempos de execução de contêiner possíveis para Kubernetes, incluindo o mais usado, o tempo de execução do Docker

4.2. Objetos Kubernetes

Na última seção, vimos vários objetos Kubernetes que são entidades persistentes no sistema Kubernetes. Eles refletem o estado do cluster a qualquer momento.

Vamos discutir alguns dos objetos Kubernetes comumente usados:

  • Pods: o pod éa basic unit of execution in Kubernetese pode consistir em um ou mais contêineres, os contêineres dentro de um pod são implantados no mesmo host

  • Implantação: a implantação éthe recommended way to deploy pods in Kubernetes, fornece recursos como reconciliar continuamente o estado atual dos pods com o estado desejado

  • Serviços: serviços em Kubernetesprovide an abstract way to expose a group of pods, em que o agrupamento é baseado em seletores que segmentam rótulos de pod

Existem vários outros objetos Kubernetes que servem ao propósito de executar contêineres de maneira distribuída de forma eficaz.

4.3. Exemplo

Portanto, agora podemos tentar iniciar nosso contêiner Docker no cluster Kubernetes. O Kubernetes forneceMinikube, uma ferramenta que executa o cluster do Kubernetes de nó único em uma máquina virtual. Também precisaríamos dekubectl, a interface de linha de comando do Kubernetes para trabalhar com o cluster do Kubernetes.

Depois de instalar o kubectl e o Minikube, podemos implantar nosso contêiner no cluster Kubernetes de nó único dentro do Minikube. Precisamos definir os objetos básicos do Kubernetes em um arquivo YAML: 

# hello-kubernetes.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-world
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: hello-world
    spec:
      containers:
      - name: hello-world
        image: hello-world:latest
        ports:
        - containerPort: 9001
---
apiVersion: v1
kind: Service
metadata:
  name: hello-world-service
spec:
  selector:
    app: hello-world
  type: LoadBalancer
  ports:
  - port: 9001
    targetPort: 9001

Uma análise detalhada deste arquivo de definição não é possível aqui, mas vamos ver os destaques:

  • Definimos umDeployment com rótulos no seletor

  • Definimos o número de réplicas necessárias para esta implantação

  • Além disso, fornecemos os detalhes da imagem do contêiner como um modelo para a implantação

  • Também definimos umService com o seletor apropriado

  • Definimos a natureza do serviço comoLoadBalancer

Finalmente, podemos implantar o contêiner e criar todos os objetos definidos do Kubernetes através do kubectl: 

kubectl apply -f yaml/hello-kubernetes.yaml

5. Mesos vs. Kubernetes

Agora, passamos por contexto suficiente e também realizamos a implantação básica no Marathon e no Kubernetes. Podemos tentar entender onde eles estão comparados.

Só uma advertência, énot entirely fair to compare Kubernetes with Mesos directly. A maioria dos recursos de orquestração de contêineres que buscamos são fornecidos por uma das estruturas do Mesos, como o Marathon. Portanto, para manter as coisas na perspectiva certa,we’ll attempt to compare Kubernetes with Marathone não diretamente Mesos.

Vamos comparar esses sistemas de orquestração com base em algumas das propriedades desejadas de tal sistema.

5.1. Cargas de trabalho suportadas

Mesos é projetado parahandle diverse types of workloads, que podem ser em contêineres ou mesmo não em contêineres. Depende da estrutura que usamos. Como vimos, é muito fácil oferecer suporte a cargas de trabalho em contêineres no Mesos usando uma estrutura como o Marathon.

Kubernetes, por outro lado,works exclusively with the containerized workload. De maneira mais ampla, o usamos com contêineres do Docker, mas ele suporta outros tempos de execução de contêineres, como o Rkt. No futuro, o Kubernetes poderá suportar mais tipos de cargas de trabalho.

5.2. Suporte para escalabilidade

Marathon supports scaling through the application definition or the user interface. O escalonamento automático também é suportado no Marathon. Também podemos dimensionar grupos de aplicativos, que dimensionam automaticamente todas as dependências.

Como vimos anteriormente, o Pod é a unidade fundamental de execução no Kubernetes. Pods can be scaled when managed by Deployment, esse é o motivo pelo qual os pods são invariavelmente definidos como uma implantação. A escala pode ser manual ou automatizada.

5.3. Manipulando Alta Disponibilidade

As instâncias do aplicativo no Marathon sãodistributed across Mesos agents providing high availability. Normalmente, um cluster do Mesos consiste em vários agentes. Além disso, o ZooKeeper fornece alta disponibilidade ao cluster Mesos por meio de eleição de quorum e líder.

Da mesma forma, os pods no Kubernetes sãoreplicated across multiple nodes providing high availability. Normalmente, um cluster Kubernetes consiste em vários nós de trabalho. Além disso, o cluster também pode ter vários mestres. Portanto, o cluster Kubernetes é capaz de fornecer alta disponibilidade aos contêineres.

5.4. Descoberta de serviços e balanceamento de carga

Mesos-DNS can provide service discovery and a basic load balancing para aplicativos. O Mesos-DNS gera um registro SRV para cada tarefa do Mesos e os converte no endereço IP e na porta da máquina que está executando a tarefa. Para aplicativos Marathon, também podemos usar Marathon-lb para fornecer descoberta baseada em porta usando HAProxy.

A implantação no Kubernetes cria e destrói pods dinamicamente. Portanto, geralmente expomos pods no Kubernetes por meio deService, which provides service discovery. O serviço no Kubernetes atua como despachante para os pods e, portanto, também fornece balanceamento de carga.

5.5 Performing Upgrades and Rollback

Alterações nas definições de aplicativos no Marathon são tratadas como implantação. Implantaçãosupports start, stop, upgrade, or scale of applications. Marathonalso supports rolling starts para implantar versões mais recentes dos aplicativos. No entanto, a reversão é tão direta e normalmente requer a implantação de uma definição atualizada.

Implantação emKubernetes supports upgrade as well as rollback. Podemos fornecer a estratégia de implantação da Implantação, ao substituir os pods antigos por novos. strategies are Recreate or Rolling Update típico. O histórico de implementação da implantação é mantido por padrão no Kubernetes, o que torna trivial reverter para uma revisão anterior.

5.6. Registro e Monitoramento

Mesos tem umdiagnostic utility which scans all the cluster componentse disponibiliza dados relacionados à saúde e outras métricas. Os dados podem ser consultados e agregados por meio de APIs disponíveis. Muitos desses dados podem ser coletados usando uma ferramenta externa como o Prometheus.

Kubernetespublish detailed information related to different objects como métricas de recursos ou pipelines de métricas completos. A prática típica é implantar uma ferramenta externa como ELK ou Prometheus + Grafana no cluster Kubernetes. Essas ferramentas podem ingerir métricas de cluster e apresentá-las de uma maneira muito fácil de usar.

5.7. Armazenamento

Mesos tempersistent local volumes for stateful applications. Só podemos criar volumes persistentes a partir dos recursos reservados. Também pode suportar armazenamento externo com algumas limitações. Mesos tem suporte experimental paraContainer Storage Interface (CSI), um conjunto comum de APIs entre fornecedores de armazenamento e plataforma de orquestração de contêiner.

O Kubernetes oferecemultiple types of persistent volume for stateful containers. Isso inclui armazenamento como iSCSI, NFS. Além disso, ele suporta armazenamento externo como AWS, GCP também. O objeto Volume no Kubernetes suporta esse conceito e vem em vários tipos, incluindo CSI.

5.8. Trabalho em rede

O tempo de execução do contêiner no Mesos oferecetwo types of networking support, IP-per-container, and network-port-mapping. Mesos define uma interface comum para especificar e recuperar informações de rede para um contêiner. Os aplicativos Marathon podem definir uma rede no modo host ou modo bridge.

Rede no Kubernetesassigns a unique IP to each pod. Isso nega a necessidade de mapear as portas do contêiner para a porta do host. Além disso, define como esses pods podem se comunicar entre nós. Isso é implementado no Kubernetes por plugins de rede como Cilium, Contiv.

6. Quando usar o quê?

Finalmente, em comparação, geralmente esperamos um veredicto claro! No entanto, não é totalmente justo declarar uma tecnologia melhor do que outra, independentemente. Como vimos,both Kubernetes and Mesos are powerful systemse oferece recursos bastante concorrentes.

O desempenho, no entanto, é um aspecto crucial. Um cluster Kubernetes pode escalar para 5000 nós, enquanto o cluster Marathon on Mesos é conhecido por suportar até 10.000 agentes. Na maioria dos casos práticos, não lidaremos com clusters tão grandes.

Por fim, tudo se resume à flexibilidade e aos tipos de cargas de trabalho que temos. Se estivermos começando do zero ewe only plan to use containerized workloads, Kubernetes can offer a quicker solution. No entanto, se tivermos cargas de trabalho existentes, que são uma mistura de contêineres e não contêineres, Mesos com Marathon pode ser uma escolha melhor.

7. Outras alternativas

Kubernetes e Apache Mesos são bastante poderosos, mas não são os únicos sistemas nesse espaço. Existem várias alternativas promissoras disponíveis para nós. Embora não entremos em detalhes, vamos listar rapidamente alguns deles:

  • Docker Swarm: Docker Swarm éan open-source clustering and scheduling tool for Docker containers. Ele vem com um utilitário de linha de comando para gerenciar um cluster de hosts do Docker. É restrito a contêineres do Docker, ao contrário do Kubernetes e do Mesos.

  • Nomad: Nomad éa flexible workload orchestrator from HashiCorp para gerenciar qualquer aplicativo em contêineres ou não. O Nomad habilita a infraestrutura declarativa como código para implantar aplicativos como o contêiner Docker.

  • OpenShift: o OpenShift éa container platform from Red Hat, orquestrado e gerenciado pelo Kubernetes por baixo. O OpenShift oferece muitos recursos além do que o Kubernetes fornece, como registro de imagem integrado, uma compilação fonte a imagem, uma solução de rede nativa, entre outros.

8. Conclusão

Para resumir, neste tutorial, discutimos contêineres e sistemas de orquestração de contêineres. Passamos brevemente por dois dos sistemas de orquestração de contêineres mais usados, o Kubernetes e o Apache Mesos. Também comparamos esses sistemas com base em vários recursos. Por fim, vimos algumas das outras alternativas nesse espaço.

Antes de fechar, devemos entender que o objetivo dessa comparação é fornecer dados e fatos. Isso não é de forma alguma declarar um melhor que outros, e isso normalmente depende do caso de uso. Portanto, devemos aplicar o contexto do nosso problema na determinação da melhor solução para nós.

Related