🥇Kubernetes: open source contra proprietário

Olá, meu nome é Dmitry Krasnov. Há mais de cinco anos, trabalho com a administração de clusters Kubernetes e construção de arquiteturas de microserviços complexas. No início deste ano, lançamos um serviço de gerenciamento de clusters Kubernetes baseado no Containerum. Aproveitando a oportunidade, vou explicar o que é esse Kubernetes e como a integração com provedores difere do open source.

Para começar, o que é Kubernetes. É um sistema para gerenciar contêineres em um grande número de hosts. Em grego, aliás, traduz-se como "condutor" ou "piloto". Originalmente desenvolvido pelo Google, depois foi transferido como uma contribuição tecnológica para a Cloud Native Computing Foundation, uma organização internacional sem fins lucrativos que reúne os principais desenvolvedores do mundo, usuários finais e fornecedores de tecnologias de contêineres.

Gerenciar um grande número de contêineres

Agora, vamos entender o que são esses contêineres. É um aplicativo com todo o seu ambiente — na maioria das vezes, as bibliotecas das quais o programa depende. Tudo isso é empacotado em arquivos e apresentado na forma de uma imagem, que pode ser executada independentemente do sistema operacional, testada e muito mais. Mas há um problema — gerenciar contêineres em um grande número de hosts é muito complicado. Por isso, o Kubernetes foi criado.

A imagem do contêiner consiste em um aplicativo mais suas dependências. O aplicativo, suas dependências e a imagem do sistema de arquivos do SO estão localizados em diferentes partes da imagem, chamados de camadas. As camadas podem ser reutilizadas para diferentes contêineres. Por exemplo, todas as aplicações de uma empresa podem usar uma camada base do Ubuntu. Ao iniciar contêineres, não é necessário armazenar múltiplas cópias de uma única camada base no host. Isso permite otimizar o armazenamento e a entrega de imagens.

Quando queremos executar um aplicativo a partir de um contêiner, as camadas necessárias se sobrepõem e formam um sistema de arquivos sobreposto. Uma camada de escrita é aplicada por cima, a qual é removida quando o contêiner é interrompido. Isso garante que, ao iniciar o contêiner, o aplicativo tenha sempre um ambiente idêntico que não pode ser modificado. Assim, a reprodutibilidade do ambiente em diferentes sistemas operacionais host é garantida. Seja Ubuntu ou CentOS, o ambiente será sempre o mesmo. Além disso, o contêiner é isolado do host por meio de mecanismos integrados no núcleo do Linux. Aplicativos dentro do contêiner não veem arquivos ou processos do host e de outros contêineres. Essa isolação dos aplicativos em relação ao sistema operacional host oferece uma camada adicional de segurança.

Há diversas ferramentas para gerenciar contêineres em um host. A mais popular delas é o Docker. Ele assegura o ciclo de vida completo dos contêineres. No entanto, ele funciona apenas em um único host. Quando é necessário gerenciar contêineres em múltiplos hosts, o Docker pode tornar a vida dos engenheiros um verdadeiro inferno. Por isso, foi criado o Kubernetes.

A demanda pelo Kubernetes é impulsionada pela sua capacidade de gerenciar grupos de contêineres em múltiplos hosts como se fossem entidades únicas. A popularidade do sistema é garantida pela possibilidade de construir DevOps, ou Operations de Desenvolvimento, onde o Kubernetes é usado para executar os processos desse mesmo DevOps.

Figura 1. Representação esquemática do funcionamento do Kubernetes

Automatização completa

DevOps, em essência, representa a automatização do processo de desenvolvimento. De forma simplificada, os desenvolvedores escrevem código, que é enviado para um repositório. Esse código pode então ser automaticamente compilado diretamente em um contêiner com todas as bibliotecas, testado e colocado na próxima fase – Staging, e depois imediatamente em Production.

Juntamente com o Kubernetes, o DevOps permite automatizar esse processo, de modo que ocorra praticamente sem a participação dos próprios desenvolvedores. Isso acelera significativamente a construção, pois o desenvolvedor não precisa se preocupar com isso em seu computador — ele simplesmente escreve um trecho de código, envia o código para o repositório, após o que um pipeline é iniciado, que pode incluir o processo de construção, teste e implementação. E isso acontece com cada commit, portanto, os testes ocorrem continuamente.

Além disso, o uso de contêineres garante que todo o ambiente desse programa será implantado em produção exatamente da forma como foi testado. Ou seja, não surgirão problemas do tipo "na versão de teste havia uma versão, em produção — outra, e ao implantar — tudo falhou". E visto que hoje temos a tendência de arquiteturas de microsserviços, onde em vez de um grande aplicativo há centenas de pequenos, para gerenciá-los manualmente, será necessário um grande número de funcionários. Por isso usamos o Kubernetes.

Vantagens, vantagens, vantagens

Se falarmos sobre as vantagens do Kubernetes como plataforma, ele apresenta benefícios significativos em termos de gerenciamento de arquitetura de microsserviços.

Gerenciamento de múltiplas réplicas. O mais importante é o gerenciamento de contêineres em múltiplos hosts. E mais importante ainda, — o gerenciamento de múltiplas réplicas de aplicativos em contêineres como uma entidade única. Graças a isso, os engenheiros não precisam se preocupar com cada contêiner individual. Se um dos contêineres falhar, o Kubernetes detectará isso e o reiniciará.
Rede de cluster. Além disso, o Kubernetes possui o que se chama rede de cluster com seu próprio espaço de endereçamento. Isso garante que cada pod tenha seu próprio endereço. Um pod é a menor unidade estrutural do cluster, onde os contêineres são executados diretamente. Além disso, o Kubernetes possui funcionalidades que combinam um balanceador de carga e descoberta de serviços. Isso elimina a necessidade de gerenciamento manual de endereços IP, transferindo essa tarefa para o Kubernetes. E os health checks automáticos ajudam a detectar problemas e redirecionar o tráfego para os pods em funcionamento.
Gerenciamento de configurações. Gerenciar uma grande quantidade de aplicativos torna a configuração deles complexa. Para isso, o Kubernetes possui recursos especiais chamados ConfigMap. Eles permitem armazenar centralizadamente as configurações e inseri-las nos pods ao iniciar os aplicativos. Esse mecanismo garante a consistência da configuração, seja em dez ou em cem réplicas de aplicativos.
Volumes Persistentes. Os contêineres são, por natureza, imutáveis, e ao interromper um contêiner, todos os dados gravados no sistema de arquivos serão destruídos. No entanto, alguns aplicativos armazenam dados diretamente no disco. Para resolver esse problema, o Kubernetes possui recursos de gerenciamento de armazenamento chamado Volumes Persistentes. Este mecanismo utiliza armazenamento externo para dados e pode fornecer armazenamento persistente, seja em bloco ou arquivo, para os contêineres. Essa solução permite armazenar dados separadamente dos workers, o que os protege em caso de falhas desses workers.
Balanceador de Carga. Apesar de no Kubernetes gerenciarmos entidades abstratas como Deployments, StatefulSets etc., no final das contas, os contêineres são executados em servidores comuns máquinas virtuais ou físicos. Eles não são perfeitos e podem falhar a qualquer momento. O Kubernetes detectará isso e redirecionará o tráfego interno para outras réplicas. Mas o que fazer com o tráfego que vem de fora? Se simplesmente direcionarmos o tráfego para um dos workers, o serviço ficará indisponível em caso de falha. Para resolver esse problema, o Kubernetes possui serviços do tipo Load Balancer. Eles são destinados a configurar automaticamente um balanceador de carga externo em todos os workers no cluster. Esse balanceador externo direciona o tráfego que vem de fora para os workers e monitora seu status. Se um ou mais workers ficarem indisponíveis, o tráfego é redirecionado para outros. Isso permite criar serviços de alta disponibilidade usando Kubernetes.

O Kubernetes se destaca principalmente na execução de arquiteturas de microsserviços. Implementar o sistema em uma arquitetura clássica é possível, mas sem sentido. Se um aplicativo não pode funcionar em várias réplicas, qual é o propósito de usá-lo no Kubernetes?

Kubernetes de código aberto

Kubernetes de código aberto – uma excelente solução: você instala e ele funciona. Pode ser implantado em seus próprios servidores, em sua infraestrutura, configurar um master e workers, onde todas as aplicações serão executadas. E o melhor – tudo isso é gratuito. No entanto, existem nuances.

A primeira – a exigência de conhecimento e experiência dos administradores e engenheiros que vão implantar e dar suporte a tudo isso. Como o cliente obtém total liberdade de ação no cluster, a responsabilidade pela operação do cluster recai sobre ele. E é muito fácil quebrar tudo aqui.
A segunda – a falta de integrações. Ao executar o Kubernetes sem uma plataforma de virtualização popular, você não aproveitará todas as vantagens do programa. Como o uso de Persistent Volumes e serviços de Load balancer.

Figura 2. Arquitetura do k8s

Kubernetes do fornecedor

A integração com o provedor de nuvem oferece duas possibilidades:

Primeiro, a pessoa pode simplesmente clicar no botão ‘criar cluster’ e obter um cluster já configurado e pronto para uso.
Em segundo lugar, o fornecedor mesmo instala o cluster e configura a integração com a nuvem.

Como isso acontece conosco. O engenheiro que inicia o cluster especifica quantos workers precisa e com quais parâmetros (por exemplo, 5 workers, cada um com 10 CPUs, 16 GB de RAM e, digamos, 100 GB de disco). Após isso, ele obtém acesso ao cluster já formado. Nesse caso, os workers, onde a carga é executada, são completamente entregues ao cliente, mas todo o plano de gerenciamento permanece sob a responsabilidade do fornecedor (caso o serviço seja fornecido na modalidade de serviço gerenciado).

No entanto, esse esquema tem suas desvantagens. Devido ao fato de que o plano de gerenciamento permanece com o fornecedor, este não oferece acesso completo ao cliente, o que reduz a flexibilidade ao trabalhar com o Kubernetes. Às vezes, o cliente quer adicionar algum recurso específico ao Kubernetes, por exemplo, autenticação via LDAP, mas a configuração do plano de gerenciamento não permite isso.

Figura 3. Exemplo de cluster Kubernetes de um provedor de nuvem

O que escolher: open source ou de fornecedor

Então, Kubernetes open source ou proprietário? Se você optar pelo Kubernetes open source, o usuário faz o que quiser. Mas existe uma grande chance de se prejudicar. Com o modelo proprietário, isso é mais difícil, pois a empresa planejou e configurou tudo. A maior desvantagem do Kubernetes open source é a necessidade de especialistas. Com o modelo proprietário, a empresa é liberada dessa dor de cabeça, mas terá que decidir: pagar seus especialistas ou ao fornecedor.

Bem, os prós são óbvios, e os contras também são conhecidos. Uma coisa é certa: o Kubernetes resolve uma série de problemas, automatizando a gestão de múltiplos contêineres. E qual escolher, open source ou proprietário, é uma decisão que cada um deve tomar.