Olá Leitores,
O atual crescimento da popularidade e uso de containers faz com que a necessidade de orquestração também acompanhe e assim a utilização de funcionalidades específicas começam a se tornar cada vez mais necessárias como por exemplo: failover, balanceamento de carga e, em geral, clusterização de serviços.
Teremos 03 artigos abordando exatamente a evolução divididos em conceitos, comparativos e ferramentas de automação.
Exclusivamente neste artigo, teremos as principais soluções de orquestração de container, como elas se comparam e uma sugestão de ambiente para usar cada opção.
Docker Swarm é uma solução de orquestração in-house do Docker. Sendo projetado pela própria Docker a qual incluí os principais recursos do Docker onde claramente podemos argumentar que o Swarm é a maneira mais compatível e natural de orquestrar infraestruturas de containers.
Como muitas outras soluções de orquestração (por exemplo: OpenStack), o Swarm inclui uma camada de controle chamada “Managers e uma camada de trabalho chamada “Workers”. Todos os serviços executados em ambas as camadas são executados dentro de containers.
Também incluída como uma parte muito importante de toda a solução de orquestração é a camada de “Discovery Layer”, com base em container também e executando uma solução de valor-chave como “etcd”. Esta camada de “Discovery Layer” é a parte do registro da solução (podemos compará-la ao OpenStack Keystone ou AWS IAM), esta camada sabe onde os serviços baseados em contêiner estão sendo executados.
Basicamente, estas são suas referências na infra-estrutura de orquestração, fornecendo estado e descoberta para o seu cluster.
Finalmente, você tem “Services e “Tasks”. Os serviços são conjuntos de Docker containers que funcionam em toda a sua infra-estrutura Swarm. Esses serviços são compostos por tarefas, os quais são seus containers Docker podem receber comandos individuais e também comandos específicos para todos os contêineres.
Resumo:
Managers: Camada de controle. Essa camada deve ser redundante em sua arquitetura. Normalmente, cada gerente é implantado em um nó independente.
Discovery: Camada de descoberta de estado e serviço. Você pode configurar seus serviços de descoberta nos mesmos nós gerenciadores ou em um conjunto independente de nós. Sempre faça-os redundantes.
Worker: Camada de trabalho (operacional). Todos os seus serviços finais serão executados ao longo de seus nós de trabalho. Esta camada deverá ter quantos workers você precisar. Pensar em crescimento horizontal aqui é uma ótima alternativa.
Services: Serviço implantado final composto por tarefas.
Tasks: Comandos dentro de um serviço.
Observação.: Caso queira, você pode começar o uso do Swarm com uma configuração “all-in-one setup”, executando tudo em um único servidor e depois crescer.
Kubernetes é um gerenciador open-source o qual tem como objectivo automatizar implantar, dimensionar e gerenciar containers.
O primeiro componente de uma configuração Kubernetes é o MASTER. O MASTER é a camada de controle, que executa uma “API” a qual controla todo o orquestrador.
Enquanto um único MASTER pode controlar a configuração completa, em ambientes de produção, vários MASTER são recomendados. O MASTER executa muitos serviços dentro de containers, cada um com uma função muito específica. Em soluções grandes uma solução de balanceador de carga é necessária na frente dos MASTER, a fim de ter alta disponibilidade e balanceamento de carga nos servidores.
Novamente, uma camada de descoberta é necessária sendo “etc.d” este responsável. A camada etcd deve ser executada dentro de seus próprios nós, com pelo menos dois servidores em um cluster etcd para fornecer redundância ou você pode executar etcd dentro dos contêineres, ou ainda diretamente no sistema operacional do host.
Soluções Linux como o CoreOS já incluem o formato etcd em seus principais pacotes. Como no Swarm, etcd manterá um registro do que está sendo executado e onde está sendo executado em toda a infraestrutura Kubernetes.
O próximo componente é o “NODE”. Os NODES ou, conhecidos também como nós e antigamente conhecidos como “minions”, executam todos os nossos serviços finais, sob a forma de “pods” (outro conceito de Kubernetes). Para quem conhece você pode comparar os NODES com um Computer Node do OpenStack.
Um POD é um conjunto de contêineres (ou um único) que é encapsulado com seus próprios recursos de armazenamento e endereço IP. Se você quiser um exemplo disso, pense em um serviço LAMP, ou neste caso, um pod LAMP que é executado dentro do pod, um contêiner com Apache e PHP, e outro com o banco de dados MySQL / MariaDB.
Labels, é outro conceito muito importante em Kubernetes. As etiquetas são pares de valores-chave (bem como tags AWS) que você pode anexar a qualquer objeto em sua infra-estrutura baseada em Kubernets. Um exemplo clássico é definir etiquetas para seus Pods para organizá-los, por exemplo, ambientes (produção, desenvolvimento), camadas de aplicativos (frontend, backend) e outros usos semelhantes ao que você faz normalmente com tags em Cloud.
Selectors: os seletores são usados para pesquisar um grupo de objetos que compartilham etiquetas específicas.
Replication Controllers: É a base dos recursos de alta redundância oferecidos pelo Kubernetes. Os controladores de replicação garantem que um número específico de instâncias do pod (ou réplicas do pod) esteja sendo executado em um determinado momento. Se um nó que contenha alguns dos seus pods diminua, os controladores de replicação garantirão que novos pods sejam iniciados ou mais precisamente agendados em qualquer um dos nós sobreviventes.
Services: Os serviços são o frontend (e camada de balanceamento de carga) para nossos pods, especialmente aqueles que são replicados. Normalmente, você precisa acessar seus pods através de um único ponto final, especialmente quando você possui vários pods executando o mesmo conjunto de aplicativos.
Resumo
MASTER: Base do seu orquestrador. O MASTER (ou Mestre) executa e expõe a API Kubernetes. Todas as funções de gerenciamento passam por esta API.
Discovery Layer: Sua central de chaves / valor baseada em etcd, onde todos os seus componentes se registrarão.
NODES: Onde a carga de trabalho. Todos os seus serviços e pods finais serão executados dentro de seus muitos nós.
Labels and Selectors: Organizador para seus objetos e a forma como os controladores de replicação e os conjuntos de réplicas sabem qual conjunto específico de pods para gerenciar.
Replication controllers / replica sets: Base de sua alta redundância e remodelação de vagens quando ocorrem falhas.
Services: Ponto de extremidade de serviço e camada de balanceamento de carga.
Observação.: Nota: Kubernetes foi projetado para implantações de médio a grande. No mínimo, você precisará de um servidor para o MESTRE e outro para o NODE. Se você quer uma configuração altamente disponível, você precisará pelo menos duas vezes os servidores (dois Masters e dois Nodes).
Apache Mesos é uma plataforma que gerencia clusters de servidores usando o Cgroups de Linux para fornecer recursos de CPU, I/O, sistema de arquivos e memória. O Mesos é descrito como um kernel de sistemas distribuídos, ou em termos mais simples, uma plataforma de cluster que fornece recursos de computação para frameworks.
Já o Marathon é uma estrutura que usa Mesos para orquestrar contêineres Docker. Conceitos básicos para o combinado Marathon / Mesos:
MASTERS: Camada de controle que inclui zookeeper para controlar o estado. Em um ambiente altamente disponível em cluster, no mínimo três servidores é a norma para a camada de serviço dos masters. A alta disponibilidade é baseada em quórum nos masters. Um “líder” é eleito para garantir 100% de tempo de atividade.
SLAVES: A carga de trabalho está aqui. Os SLAVES executam todas as suas tarefas, passaram e controlam a camada de estrutura.
Descoberta do serviço: Marathon usa o serviço Mesos-DNS para todas as funções relacionadas com a descoberta de serviços. Com o uso inteligente de registros DNS SRV, Mesos registra todas as tarefas e instâncias de aplicativos no banco de dados de registro DNS.
Load Balacing: o balanceador de carga Marathon fornece serviços de porta via HAproxy. O Marathon-lb é baseado no docker e também pode fornecer a camada de descoberta do serviço se não quisermos usar o Mesos-DNS.
Resumo
MASTER: Nossa camada de controle.
SLAVES: Carga de trabalho. Todos os serviços (e pods) são implantados aqui.
Descoberta de serviço: usando Mesos-DNS ou Marathon-lb.
Balanceamento de carga: balanceador de carga baseado em Marathon-lb.
Restrições: uma maneira de controlar a maneira como os aplicativos são implantados. Métricas: monitorando informações disponíveis através da API REST para componentes de terceiros.
No próximo post faremos uma comparação 1:1 de cada ítem dos 3 orquestradores.
Obrigado e abraços,
Thiago Viola
Head of Watson and Cloud Digital Sales Brazil
SoftLayer Subject Matter Expert
E-mail: thiagoviola@yahoo.com.br
LinkedIn: br.linkedin.com/in/thiagoviola
Blog: https://thiagoviola.wordpress.com/
Twitter: @ThiViola
YouTube Channel: https://www.youtube.com/user/tviola87
Slide Share: http://www.slideshare.net/ThiagoViola
Uma resposta