Get best of the week

Kubernetes: código aberto vs fornecedor

Olá, meu nome é Dmitry Krasnov. Há mais de cinco anos, administro clusters Kubernetes e construo arquiteturas complexas de microsserviços. No início deste ano, lançamos o serviço de gerenciamento de cluster Kubernetes baseado no Containerum. Aproveitando esta oportunidade, vou lhe dizer o que é esse Kubernetes e como a integração com o fornecedor difere do código aberto.

Para começar, o que é Kubernetes. Este é um sistema para gerenciar contêineres em um grande número de hosts. A partir do grego, a propósito, é traduzido como "piloto" ou "timoneiro". Originalmente desenvolvida pelo Google, após a qual a Cloud Native Computing Foundation, uma organização internacional sem fins lucrativos que reúne desenvolvedores globais líderes, usuários finais e fornecedores de tecnologia de contêineres, foi transferida como uma contribuição tecnológica.



Guie um grande número de contêineres


Agora vamos ver que tipo de contêineres são esses. Esta aplicação com todos os seus arredores - principalmente 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, testado e não apenas. Mas há um problema - gerenciar contêineres em um grande número de hosts é muito difícil. Portanto, o Kubernetes foi criado.

Uma imagem de contêiner é um aplicativo mais suas dependências. O aplicativo, suas dependências e a imagem do sistema de arquivos do SO estão localizadas em diferentes partes da imagem, as chamadas camadas. As camadas podem ser reutilizadas para diferentes recipientes. Por exemplo, para todos os aplicativos da empresa, a camada base do Ubuntu pode ser usada. Ao iniciar contêineres, não há necessidade de armazenar várias cópias de uma camada base no host. Isso permite otimizar o armazenamento e a entrega de imagens.

Quando queremos iniciar o aplicativo a partir do contêiner, as camadas necessárias são sobrepostas umas às outras e um sistema de arquivos de sobreposição é formado. Uma camada para gravação é sobreposta na parte superior que, quando o contêiner é parado, é excluída. Isso garante que, ao iniciar o contêiner, o aplicativo sempre tenha o mesmo ambiente, que não pode ser alterado. Isso garante a reprodutibilidade do ambiente em diferentes sistemas operacionais de host. Seja Ubuntu ou CentOS, o ambiente será sempre o mesmo. Além disso, o contêiner é isolado do host usando os mecanismos embutidos no kernel do Linux. Os aplicativos no contêiner não veem arquivos, processos do host e contêineres vizinhos. Esse isolamento de aplicativos do sistema operacional host fornece uma camada adicional de segurança.

Existem muitas ferramentas para gerenciar contêineres no host. O mais popular deles é o Docker. Permite garantir o ciclo de vida completo dos contêineres. No entanto, ele funciona apenas em um host. Se você precisar gerenciar contêineres em vários hosts, o Docker pode transformar a vida dos engenheiros em um inferno. É por isso que o Kubernetes foi criado.

A demanda pelo Kubernetes é justamente devido à capacidade de direcionar grupos de contêineres em vários hosts como algumas entidades únicas. A popularidade do sistema fornece a capacidade de criar DevOps ou Operações de Desenvolvimento, na qual o Kubernetes é usado para iniciar os processos desse próprio DevOps.



Figura 1. Representação esquemática de como o Kubernetes funciona

Automação completa


O DevOps, em princípio, é uma automação do processo de desenvolvimento. Grosso modo, os desenvolvedores escrevem código que é derramado no repositório. Em seguida, esse código pode ser coletado automaticamente imediatamente em um contêiner com todas as bibliotecas, testado e implementado no próximo estágio - armazenamento temporário e, em seguida, imediatamente na produção.

Juntamente com o Kubernetes, o DevOps permite automatizar esse processo para que ele prossiga com pouca ou nenhuma participação dos próprios desenvolvedores. Devido a isso, o assembly é significativamente acelerado, já que o desenvolvedor não precisa fazer isso em seu computador - ele apenas escreve um código, envia o código para o repositório e inicia o pipeline, que pode incluir o processo de montagem, teste e implementação. E isso acontece com todas as confirmações, portanto os testes estão em andamento.

Ao mesmo tempo, o uso do contêiner permite garantir que todo o ambiente deste programa entre em produção exatamente na forma em que foi testado. Ou seja, não haverá problemas da categoria “no teste houve algumas versões, em produção - outras, mas quando configuradas - tudo caiu”. E como hoje temos uma tendência para a arquitetura de microsserviço, quando em vez de um aplicativo enorme existem centenas de aplicativos pequenos, para administrá-los manualmente, você precisa de uma equipe enorme. É por isso que usamos o Kubernetes.

Prós, Prós, Prós


Se falarmos das vantagens do Kubernetes como plataforma, ele possui vantagens significativas em termos de gerenciamento da arquitetura de microsserviço.

  • . — . , — . . , Kubernetes .
  • . Kubernetes . . , . Kubernetes , Service Discovery. IP- Kubernetes. health check` .
  • . . Kubernetes ConfigMap`. . , .
  • Persistent Volumes. , , . . Kubernetes — Persistent Volumes. , , . , .
  • Load Balancer. , Kubernetes Deployment, StatefulSet .., . . Kubernetes . , ? , . Kubernetes Load Balancer. . . , . Kubernetes.

O Kubernetes é melhor no lançamento de arquiteturas de microsserviços. A implementação de um sistema na arquitetura clássica é possível, mas sem sentido. Se o aplicativo não puder funcionar em várias réplicas, qual é a diferença - no Kubernetes ou não?

Kubernetes de código aberto


O Kubernetes de código aberto é uma grande coisa: ele instalou e funciona. Você pode implantar em seus servidores de ferro, em sua infraestrutura, colocar assistentes e trabalhadores nos quais todos os aplicativos serão executados. E o mais importante - tudo isso é grátis. No entanto, existem nuances.

  • O primeiro é a exatidão do conhecimento e da experiência de administradores e engenheiros que irão implantar e acompanhar tudo isso. Como o cliente recebe total liberdade de ação no cluster, ele assume a responsabilidade pela operacionalidade do cluster. E quebrar tudo aqui é muito simples.
  • O segundo é a falta de integração. Se você executar o Kubernetes sem uma plataforma de virtualização popular, não obterá todos os benefícios do programa. Como usar os serviços Persistent Volumes e Load Balancer.



Figura 2. A arquitetura do k8s

Kubernetes do fornecedor


A integração com um provedor de nuvem fornece duas opções:

  • Primeiro, uma pessoa pode simplesmente clicar no botão "criar um cluster" e obter um cluster que já esteja configurado e pronto para o trabalho.
  • Em segundo lugar, o próprio fornecedor configura um cluster e configura a integração com a nuvem.

Como isso está acontecendo conosco? O engenheiro que inicia o cluster indica quantos trabalhadores ele precisa e com quais parâmetros (por exemplo, 5 trabalhadores, cada um com 10 CPUs, 16 GB de RAM e, digamos, 100 GB de disco). Em seguida, obtém acesso ao cluster já formado. Ao mesmo tempo, os trabalhadores nos quais a carga é lançada são completamente entregues ao cliente, mas todo o plano de gerenciamento permanece na área de responsabilidade do fornecedor (caso o serviço seja fornecido de acordo com o modelo de serviço gerenciado).

No entanto, esse esquema tem suas desvantagens. Devido ao fato de o plano de gerenciamento permanecer com o fornecedor, o fornecedor não fornece acesso total ao cliente e isso reduz a flexibilidade no trabalho com o Kubernetes. Às vezes, o cliente deseja vincular alguma funcionalidade específica ao Kubernetes, por exemplo, autenticação via LDAP, e a configuração do plano de gerenciamento não permite isso.



Figura 3. Um exemplo de cluster Kubernetes de um provedor de nuvem

O que escolher: código aberto ou fornecedor


Então, Kubernetes de código aberto ou fornecedor? Se usarmos o Kubernetes de código aberto, o usuário desejará fazer o que ele faz. Mas uma ótima chance de dar um tiro na perna. Com os fornecedores, isso é mais complicado, porque tudo é pensado e configurado para a empresa. A maior desvantagem do Kubernetes de código aberto é a exigência de especialistas. Com um fornecedor, a empresa é poupada dessa dor de cabeça, mas terá que decidir se deve pagar seus especialistas ou o fornecedor.





Bem, os profissionais são óbvios, os contras também são conhecidos. Invariavelmente uma coisa: o Kubernetes resolve muitos problemas automatizando o gerenciamento de vários contêineres. E qual escolher, código aberto ou fornecedor - todo mundo decide por si mesmo.

O artigo foi preparado por Dmitry Krasnov, arquiteto principal do serviço Containerum do provedor #CloudMTS

More articles:


All Articles