Get best of the week

Viagem multicluster K8S

Olá Habr!

Representamos a equipe da plataforma Exness. Anteriormente, nossos colegas já escreveram um artigo sobre imagens prontas para produção para k8s . Hoje, queremos compartilhar a experiência da migração de serviços no Kubernetes.



Para começar, oferecemos alguns números para uma melhor compreensão do que será discutido:

  • 100+ , 10 QA, DevOps Scrum. — Python, PHP, C++, Java Golang. 
  • — 2000 . Rancher v1.6 VMware. 


Como se costuma dizer, nada dura para sempre, e o Rancher anunciou há muito tempo o término do suporte para a versão 1.6. Sim, por mais de três anos aprendemos a cozinhá-lo e a resolver problemas que surgem, mas cada vez mais nos deparamos com problemas que nunca serão corrigidos. O Rancher 1.6 também possui um sistema ossificado para emissão de direitos, onde você pode fazer quase tudo ou nada.

Virtualização própria, embora proporcionasse maior controle sobre armazenamento e segurança de dados, mas impusesse custos operacionais, difíceis de suportar com o constante crescimento da empresa, o número de projetos e requisitos para eles.

Queríamos seguir os padrões IaC e, se necessário, obter energia rapidamente, em qualquer localização geográfica e sem bloqueio de fornecedor, além de poder abandoná-los rapidamente.

Primeiros passos


Antes de tudo, queríamos contar com tecnologias e soluções modernas que permitissem às equipes ter um ciclo de desenvolvimento mais rápido e minimizar os custos operacionais de interação com uma plataforma que fornece energia. 
 
Obviamente, a primeira coisa que veio à nossa mente foi o Kubernetes, mas não ficamos empolgados e fizemos uma pequena pesquisa sobre o assunto da escolha certa. Avaliamos apenas soluções de código aberto e o Kubernetes derrotou incondicionalmente em uma batalha injusta.  

Em seguida, surgiu a questão de escolher uma ferramenta para criar clusters. Comparamos as soluções mais populares: kops, kubespray, kubeadm.

Para começar, o kubeadm nos parecia uma maneira muito complicada, antes, uma espécie de inventor da "bicicleta", e os kops não tinham flexibilidade.

E o vencedor saiu:



Começamos a experimentar nossa própria virtualização e a AWS, tentando recriar uma semelhança aproximada de nosso padrão anterior de gerenciamento de recursos, onde todos usam o mesmo "cluster". E agora temos o primeiro cluster de 10 pequenas máquinas virtuais, algumas das quais estão na AWS. Começamos a tentar migrar equipes para lá, tudo parecia estar "bom" e a história poderia estar concluída, mas ...

Primeiros problemas


É possível construir o kubespray, não é a ferramenta que permite que o IaC seja seguido: quando entrei / descomissionei os nós, algo constantemente dava errado e qualquer intervenção era necessária, e ao usar sistemas operacionais diferentes, o manual se comportava. De maneiras diferentes. Com o crescente número de comandos e nós no cluster, começamos a perceber que o manual demorava mais e mais, no final, nosso registro era de 3,5 horas e o seu? :)

E parece que o kubespray é apenas Ansible, e tudo fica claro à primeira vista, mas:



No início da jornada, havia uma tarefa para executar capacidades apenas na AWS e na virtualização, mas, como acontece com frequência, os requisitos foram alterados.
 


À luz disso, ficou claro que nosso antigo padrão de combinar recursos em um sistema de orquestração não era adequado - no caso em que os clusters estão muito distantes e são gerenciados por diferentes fornecedores. 

Além disso. Quando todas as equipes trabalham dentro do mesmo cluster, vários serviços com o NodeSelector instalado incorretamente podem voar para o host "alienígena" de outra equipe e utilizar recursos lá; e, no caso de definir contaminação, havia chamadas constantes de que este ou aquele serviço não estava funcionando, não distribuído corretamente devido ao fator humano. Outro problema foi o cálculo do custo, principalmente devido aos problemas na distribuição de serviços por nós.

Uma história separada era a questão dos direitos dos funcionários: cada equipe queria estar "à frente" do cluster e gerenciá-lo completamente, o que poderia causar um colapso completo, uma vez que as equipes são praticamente independentes umas das outras.

Como ser


Dado o exposto e os desejos das equipes de serem mais independentes, fizemos uma conclusão simples: uma equipe - um cluster. 

Então, temos um segundo:



e então um terceiro cluster: 



então começamos a pensar: digamos, em um ano, nossas equipes terão mais de um cluster? Em diferentes áreas geográficas, por exemplo, ou sob o controle de diferentes fornecedores? E alguns deles desejam implantar rapidamente um cluster temporário para qualquer teste. 



Viria Kubernetes completo! Isso é algum tipo de MultiKubernetes. 

Ao mesmo tempo, todos precisaremos, de alguma forma, oferecer suporte a todos esses clusters, poder controlar facilmente o acesso a eles, criar novos e descomissionar antigos sem intervenção manual.

Desde o início de nossa jornada no mundo de Kubernetes, já passou algum tempo, e decidimos reexaminar as soluções disponíveis. Acontece que ele já existe no mercado - Rancher 2.2.



No primeiro estágio de nossa pesquisa, o Rancher Labs já fez o primeiro lançamento da versão 2, mas, embora possa ser aumentado muito rapidamente lançando o contêiner sem dependências externas com alguns parâmetros ou usando o HELM Chart oficial, parecia-nos grosseiro e não sabíamos se confie nessa decisão, seja ela desenvolvida ou abandonada rapidamente. O próprio paradigma cluster = clicks na interface do usuário também não nos convinha e não queríamos nos conectar ao RKE, pois essa é uma ferramenta bastante limitada. 

A versão Rancher 2.2 já tinha uma aparência mais eficiente e, junto com as anteriores, tinha vários recursos interessantes prontos para uso, como integração com muitos provedores externos, um único ponto de distribuição de direitos e arquivos kubeconfig, iniciando uma imagem kubectl com seus direitos na interface do usuário, espaços de nomes aninhados, também conhecidos como projetos. 

Uma comunidade já se formou em torno do Rancher 2 e o provedor HashiCorp Terraform foi criado para gerenciá-lo, o que nos ajudou a reunir tudo.

O que aconteceu


Como resultado, temos um pequeno cluster no qual o Rancher é iniciado, acessível a todos os outros clusters, bem como a muitos clusters associados a ele, o acesso a qualquer um dos quais pode ser emitido simplesmente como adicionar um usuário ao diretório ldap, independentemente de onde ele esteja. está localizado e os recursos de que o provedor usa.

Usando o gitlab-ci e o Terraform, foi criado um sistema que permite criar um cluster de qualquer configuração em provedores de nuvem ou nossa própria infraestrutura e conectá-los ao Rancher. Tudo isso é feito no estilo IaC, onde cada cluster é descrito por um repositório e seu estado é versionado. Nesse caso, a maioria dos módulos é conectada a partir de repositórios externos, de modo que resta apenas transferir variáveis ​​ou descrever sua configuração personalizada para instâncias, o que ajuda a reduzir a porcentagem de repetibilidade de código.



Obviamente, nossa jornada está longe de terminar e ainda há muitas tarefas interessantes à frente, como um único ponto de trabalho com os logs e métricas de qualquer cluster, malha de serviço, gitops para gerenciamento de cargas em um cluster múltiplo e muito mais. Esperamos que você esteja interessado em nossa experiência! 

O artigo foi escrito por A. Antipov, A. Ganush, Platform Engineers. 

More articles:


All Articles