Docker Swarm, Kubernetes e Mesos são as estruturas de orquestração de contêineres mais populares. Em sua palestra, Arun Gupta compara os seguintes aspectos do Docker, Swarm e Kubernetes:
- Desenvolvimento local.
- Funções de implantação.
- Aplicativos multicontêineres.
- Descoberta de serviço.
- Dimensionando o serviço.
- Tarefas executadas uma vez.
- Integração com Maven.
- Atualização "rolante".
- Criando um cluster de banco de dados Couchbase.
Como resultado, você obterá uma compreensão clara do que cada ferramenta de orquestração tem a oferecer e aprenderá como usar essas plataformas de maneira eficaz.
Arun Gupta é o tecnólogo-chefe de produtos de código aberto da Amazon Web Services, que desenvolve as comunidades de desenvolvedores Sun, Oracle, Red Hat e Couchbase há mais de 10 anos. Possui vasta experiência trabalhando na liderança de equipes multifuncionais, desenvolvendo e implementando estratégias para campanhas e programas de marketing. Ele liderou equipes de engenheiros da Sun, é um dos fundadores da equipe Java EE e criador da filial americana da Devoxx4Kids. Arun Gupta é autor de mais de 2 mil posts em blogs de TI e já deu palestras em mais de 40 países.
A linha 55 contém um COUCHBASE_URI apontando para este serviço de banco de dados, que também foi criado usando o arquivo de configuração do Kubernetes. Se você olhar a linha 2, poderá ver kind: Service é o serviço que estou criando chamado couchbase-service, e o mesmo nome está listado na linha 4. Abaixo estão algumas portas.
As linhas principais são 6 e 7. No serviço eu digo: “Ei, esses são os rótulos que estou procurando!”, e esses rótulos nada mais são do que nomes de pares de variáveis, e a linha 7 aponta para meu couchbase-rs-pod aplicativo. A seguir estão as portas que fornecem acesso a esses mesmos rótulos.
Na linha 19 eu crio um novo tipo ReplicaSet, a linha 31 contém o nome da imagem e as linhas 24-27 apontam para os metadados associados ao meu pod. É exatamente isso que o serviço procura e onde a conexão deve ser feita. No final do arquivo há algum tipo de conexão entre as linhas 55-56 e 4, dizendo: “use este serviço!”
Portanto, inicio meu serviço quando há um conjunto de réplicas, e como cada conjunto de réplicas possui sua própria porta com o rótulo correspondente, ele está incluído no serviço. Do ponto de vista do desenvolvedor, basta chamar o serviço, que então usa o conjunto de réplicas necessário.
Como resultado, tenho um pod WildFly que se comunica com o back-end do banco de dados por meio do Couchbase Service. Posso usar o front-end com vários pods WildFly, que também se comunicam com o back-end do couchbase por meio do serviço couchbase.
Posteriormente veremos como um serviço localizado fora do cluster se comunica através de seu endereço IP com elementos que estão localizados dentro do cluster e possuem um endereço IP interno.
Portanto, contêineres sem estado são ótimos, mas quão bom é usar contêineres com estado? Vejamos as configurações do sistema para contêineres com estado ou persistentes. No Docker, existem 4 abordagens diferentes para o layout de armazenamento de dados às quais você deve prestar atenção. O primeiro é Implicit Per-Container, o que significa que ao usar contêineres satateful couchbase, MySQL ou MyDB, todos eles começam com o Sandbox padrão. Ou seja, tudo que está armazenado no banco de dados fica armazenado no próprio container. Se o contêiner desaparecer, os dados desaparecerão junto com ele.
O segundo é Explicit Per-Container, quando você cria um armazenamento específico com o comando docker volume create e armazena dados nele. A terceira abordagem Per-Host está associada ao mapeamento de armazenamento, quando tudo armazenado no contêiner é duplicado simultaneamente no host. Se o contêiner falhar, os dados permanecerão no host. Este último é a utilização de vários hosts Multi-Host, o que é aconselhável na fase de produção de diversas soluções. Digamos que seus contêineres com seus aplicativos estejam rodando no host, mas você deseja armazenar seus dados em algum lugar da Internet e, para isso, utiliza o mapeamento automático para sistemas distribuídos.
Cada um desses métodos usa um local de armazenamento específico. Dados implícitos e explícitos por contêiner armazenam dados no host em /var/lib/docker/volumes. Ao usar o método Per-Host, o armazenamento é montado dentro do contêiner e o próprio contêiner é montado no host. Para multihosts, soluções como Ceph, ClusterFS, NFS, etc.
Se um contêiner persistente falhar, o diretório de armazenamento se tornará inacessível nos dois primeiros casos, mas nos dois últimos casos o acesso será mantido. Porém, no primeiro caso, você pode acessar o repositório por meio de um host Docker rodando em uma máquina virtual. No segundo caso, os dados também não serão perdidos, pois você criou um armazenamento Explícito.
Se o host falhar, o diretório de armazenamento fica indisponível nos três primeiros casos; no último caso, a conexão com o armazenamento não é interrompida. Por fim, a função compartilhada está completamente excluída para armazenamento no primeiro caso e é possível nos demais. No segundo caso, você pode compartilhar o armazenamento dependendo se o seu banco de dados suporta armazenamento distribuído ou não. No caso de Per-Host, a distribuição de dados só é possível em um determinado host, e para um multihost é fornecida pela expansão do cluster.
Isso deve ser levado em consideração ao criar contêineres com estado. Outra ferramenta útil do Docker é o plugin Volume, que funciona segundo o princípio de “baterias presentes, mas devem ser substituídas”. Quando você inicia um contêiner Docker, ele diz: “Ei, depois de iniciar um contêiner com um banco de dados, você pode armazenar seus dados neste contêiner!” Este é o recurso padrão, mas você pode alterá-lo. Este plugin permite que você use uma unidade de rede ou algo semelhante em vez de um banco de dados contêiner. Inclui um driver padrão para armazenamento baseado em host e permite a integração de contêineres com sistemas de armazenamento externos, como Amazon EBS, Azure Storage e discos persistentes GCE.
O próximo slide mostra a arquitetura do plugin Docker Volume.
A cor azul representa o cliente Docker associado ao host Docker azul, que possui um mecanismo de armazenamento local que fornece contêineres para armazenamento de dados. Verde indica o Plugin Client e o Plugin Daemon, que também estão conectados ao host. Eles oferecem a oportunidade de armazenar dados em armazenamento de rede do tipo de back-end de armazenamento que você precisa.
O plugin Docker Volume pode ser usado com armazenamento Portworx. O módulo PX-Dev é na verdade um contêiner executado que se conecta ao host Docker e permite armazenar dados facilmente no Amazon EBS.
O cliente Portworx permite monitorar o status de vários contêineres de armazenamento conectados ao seu host. Se você visitar meu blog, poderá ler como aproveitar ao máximo o Portworx com Docker.
O conceito de armazenamento no Kubernetes é semelhante ao Docker e é representado por diretórios acessíveis ao seu contêiner em um pod. Eles são independentes da vida útil de qualquer contêiner. Os tipos de armazenamento mais comuns disponíveis são hostPath, nfs, awsElasticBlockStore e gsePersistentDisk. Vamos dar uma olhada em como essas lojas funcionam no Kubernetes. Normalmente, o processo de conectá-los consiste em 3 etapas.
A primeira é que alguém do lado da rede, geralmente um administrador, fornece armazenamento persistente. Existe um arquivo de configuração PersistentVolume correspondente para isso. Em seguida, o desenvolvedor do aplicativo escreve um arquivo de configuração chamado PersistentVolumeClaim, ou uma solicitação de armazenamento PVC, que diz: “Tenho 50 GB de armazenamento distribuído provisionado, mas para que outras pessoas também utilizem sua capacidade, estou dizendo a este PVC que atualmente precisa de apenas 10 GB". Por fim, a terceira etapa é que sua solicitação seja montada como armazenamento e a aplicação que possui o pod, ou conjunto de réplicas, ou algo semelhante, comece a utilizá-la. É importante lembrar que este processo consiste nas 3 etapas citadas e é escalonável.
O próximo slide mostra o Kubernetes Persistence Container da arquitetura AWS.
Dentro do retângulo marrom que representa o cluster Kubernetes, há um nó mestre e dois nós trabalhadores, indicados em amarelo. Um dos nós de trabalho contém um pod laranja, armazenamento, um controlador de réplica e um contêiner Docker Couchbase verde. Dentro do cluster, acima dos nós, um retângulo roxo indica o Serviço acessível externamente. Esta arquitetura é recomendada para armazenar dados no próprio dispositivo. Se necessário, posso armazenar meus dados no EBS fora do cluster, conforme mostrado no próximo slide. Este é um modelo típico de escalabilidade, mas há um aspecto financeiro a ser considerado ao usá-lo – armazenar dados em algum lugar da rede pode ser mais caro do que em um host. Ao escolher soluções de conteinerização, este é um dos argumentos de peso.
Assim como no Docker, você pode usar contêineres Kubernetes persistentes com Portworx.
Isso é o que na terminologia atual do Kubernetes 1.6 é chamado de “StatefulSet” - uma maneira de trabalhar com aplicativos com estado que processa eventos sobre a interrupção do pod e a execução do Graceful Shutdown. No nosso caso, tais aplicações são bancos de dados. No meu blog você pode ler como criar um StatefulSet no Kubernetes usando Portworx.
Vamos falar sobre o aspecto do desenvolvimento. Como eu disse, o Docker possui 2 versões - CE e EE, no primeiro caso estamos falando de uma versão estável da Community Edition, que é atualizada uma vez a cada 3 meses, ao contrário da versão atualizada mensalmente do EE. Você pode baixar o Docker para Mac, Linux ou Windows. Depois de instalado, o Docker será atualizado automaticamente e é muito fácil começar.
Para Kubernetes, prefiro a versão Minikube – é uma boa maneira de começar a usar a plataforma criando um cluster em um único nó. Para criar clusters de vários nós, a escolha de versões é mais ampla: são kops, kube-aws (CoreOS+AWS), kube-up (desatualizado). Se você deseja usar o Kubernetes baseado em AWS, recomendo ingressar no AWS SIG, que se reúne on-line todas as sextas-feiras e publica uma variedade de materiais interessantes sobre como trabalhar com o AWS Kubernetes.
Vejamos como a atualização contínua é executada nessas plataformas. Se houver um cluster de vários nós, ele usará uma versão específica da imagem, por exemplo, WildFly:1. Uma atualização contínua significa que a versão da imagem é substituída sequencialmente por uma nova em cada nó, um após o outro.
Para fazer isso, utilizo o comando docker service update (nome do serviço), no qual especifico a nova versão da imagem WildFly:2 e o método de atualização update-parallelism 2. O número 2 significa que o sistema atualizará 2 imagens do aplicativo simultaneamente, em seguida, um atraso de atualização de 10 segundos em 10s, após o qual as próximas 2 imagens serão atualizadas em mais 2 nós, etc. Este mecanismo simples de atualização contínua é fornecido como parte do Docker.
No Kubernetes, uma atualização contínua funciona assim. O controlador de replicação rc cria um conjunto de réplicas da mesma versão, e cada pod neste webapp-rc é fornecido com um rótulo localizado em etcd. Quando preciso de um pod, uso o Application Service para acessar o repositório etcd, que me fornece o pod usando o rótulo especificado.
Neste caso, temos 3 pods no controlador de replicação executando o aplicativo WildFly versão 1. Ao atualizar em segundo plano, outro controlador de replicação é criado com o mesmo nome e índice no final - - xxxxx, onde x são números aleatórios, e com os mesmos rótulos. Agora o Application Service possui três pods com a versão antiga do aplicativo e três pods com a nova versão no novo controlador de replicação. Depois disso, os pods antigos são excluídos, o controlador de replicação com os novos pods é renomeado e colocado em operação.
Vamos passar ao monitoramento. Docker possui muitos comandos de monitoramento integrados. Por exemplo, a interface de linha de comando docker container stats permite exibir informações sobre o estado dos contêineres no console a cada segundo - uso do processador, uso do disco, carga da rede. A ferramenta Docker Remote API fornece dados sobre como o cliente se comunica com o servidor. Ele usa comandos simples, mas é baseado na API REST do Docker. Neste caso, as palavras REST, Flash, Remote significam a mesma coisa. Quando você se comunica com o host, é uma API REST. A API Docker Remote permite obter mais informações sobre a execução de contêineres. Meu blog descreve os detalhes do uso desse monitoramento com o Windows Server.
O monitoramento de eventos do sistema docker ao executar um cluster multi-host torna possível obter dados sobre uma falha de host ou de contêiner em um host específico, dimensionamento de serviços e assim por diante. A partir do Docker 1.20, ele inclui o Prometheus, que incorpora endpoints em aplicativos existentes. Isso permite receber métricas via HTTP e exibi-las em painéis.
Outro recurso de monitoramento é o cAdvisor (abreviação de Container Advisor). Ele analisa e fornece dados de uso de recursos e desempenho de contêineres em execução, fornecendo métricas do Prometheus prontas para uso. A particularidade desta ferramenta é que ela fornece dados apenas dos últimos 60 segundos. Portanto, você precisa ser capaz de coletar esses dados e colocá-los em um banco de dados para poder monitorar um processo de longo prazo. Ele também pode ser usado para exibir métricas do painel graficamente usando Grafana ou Kibana. Meu blog tem uma descrição detalhada de como usar o cAdvisor para monitorar contêineres usando o painel do Kibana.
O próximo slide mostra a aparência da saída do endpoint do Prometheus e as métricas disponíveis para exibição.
No canto inferior esquerdo você vê métricas para solicitações HTTP, respostas, etc., à direita está sua exibição gráfica.
O Kubernetes também inclui ferramentas de monitoramento integradas. Este slide mostra um cluster típico contendo um nó mestre e três nós de trabalho.
Cada um dos nós de trabalho contém um cAdvisor iniciado automaticamente. Além disso, existe o Heapster, um sistema de monitoramento de desempenho e coleta de métricas compatível com Kubernetes versão 1.0.6 e superior. O Heapster permite coletar não apenas métricas de desempenho de cargas de trabalho, pods e contêineres, mas também eventos e outros sinais gerados por todo o cluster. Para coletar dados, ele se comunica com o Kubelet de cada pod, armazena automaticamente as informações no banco de dados InfluxDB e as envia como métricas para o painel Grafana. No entanto, lembre-se de que se você estiver usando o miniKube, esse recurso não está disponível por padrão, portanto você terá que usar complementos para monitoramento. Portanto, tudo depende de onde você executa os contêineres e quais ferramentas de monitoramento você pode usar por padrão e quais precisa instalar como complementos separados.
O próximo slide mostra os painéis do Grafana que mostram o status de execução dos meus contêineres. Há muitos dados interessantes aqui. Claro, existem muitas ferramentas comerciais de monitoramento de processos Docker e Kubernetes, como SysDig, DataDog, NewRelic. Alguns deles têm um período de teste gratuito de 30 anos, então você pode tentar encontrar o que melhor se adapta a você. Pessoalmente, prefiro usar SysDig e NewRelic, que se integram bem ao Kubernetes. Existem ferramentas que se integram igualmente bem às plataformas Docker e Kubernetes.
Alguns anúncios 🙂
Obrigado por ficar com a gente. Gostou dos nossos artigos? Quer ver mais conteúdos interessantes? Apoie-nos fazendo um pedido ou recomendando a amigos, , um análogo exclusivo de servidores básicos, que foi inventado por nós para você: (disponível com RAID1 e RAID10, até 24 núcleos e até 40 GB DDR4).
Dell R730xd 2x mais barato no data center Equinix Tier IV em Amsterdã? Só aqui na Holanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US$ 99! Ler sobre
Fonte: habr.com