Oi, Habr!
Representamos a equipe da plataforma Exness. Anteriormente, nossos colegas já escreveram um artigo sobre . Hoje queremos compartilhar nossa experiência de migração de serviços para Kubernetes.
Para começar, oferecemos alguns números para uma melhor compreensão do que será discutido:
- Nosso departamento de desenvolvimento consiste em mais de 100 pessoas, incluindo mais de 10 equipes diferentes com processos autossuficientes de QA, DevOps e Scrum. Pilha de desenvolvimento - Python, PHP, C++, Java e Golang.
- O tamanho dos ambientes de teste e produção é de cerca de 2000 contêineres cada. Eles estão executando o Rancher v1.6 em sua própria virtualização e em VMware.
Motivação
Como se costuma dizer, nada dura para sempre, e o Rancher anunciou o fim do suporte para a versão 1.6 há muito tempo. Sim, em mais de três anos aprendemos a prepará-lo e a resolver os 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 de emissão de direitos, onde você pode fazer quase tudo ou nada.
Embora a virtualização proprietária proporcionasse maior controle sobre o armazenamento de dados e sua segurança, impunha custos operacionais difíceis de aceitar dado o crescimento constante da empresa, a quantidade de projetos e as exigências dos mesmos.
Queríamos seguir os padrões IaC e, se necessário, obter capacidade rapidamente, em qualquer localização geográfica e sem bloqueio de fornecedor, e também poder abandoná-la rapidamente.
Primeiros Passos
Em primeiro lugar, queríamos contar com tecnologias e soluções modernas que permitissem às equipas ter um ciclo de desenvolvimento mais rápido e minimizar os custos operacionais de interação com a plataforma que fornece energia.
Claro que a primeira coisa que nos veio à cabeça foi o Kubernetes, mas não nos entusiasmamos e fizemos uma pequena pesquisa para ver se era a escolha certa. Avaliamos apenas soluções de código aberto e, em uma batalha injusta, o Kubernetes venceu incondicionalmente.
Em seguida veio a questão de escolher uma ferramenta para criação de clusters. Comparamos as soluções mais populares: kops, kubespray, kubeadm.
Para começar, o kubeadm nos parecia um caminho muito complicado, como uma espécie de inventor de uma “bicicleta”, e os kops não tinham flexibilidade suficiente.
E o vencedor foi:
Começamos a experimentar nossa própria virtualização e a AWS, tentando recriar algo mais ou menos semelhante ao nosso padrão anterior de gerenciamento de recursos, onde todos compartilhavam o mesmo “cluster”. E agora temos nosso primeiro cluster de 10 pequenas máquinas virtuais, algumas das quais estão localizadas na AWS. Começamos a tentar migrar equipes para lá, tudo parecia “bom”, e a história poderia ser finalizada, mas...
Primeiros problemas
Ansible é o fundamento do kubespray, não é uma ferramenta que permite seguir IaC: ao comissionar/descomissionar nós, algo constantemente dava errado e algum tipo de intervenção era necessária, e ao usar sistemas operacionais diferentes, o playbook se comportava de maneira diferente. . À medida que o número de equipes e nós no cluster crescia, começamos a notar que o playbook estava demorando cada vez mais para ser concluído e, como resultado, nosso recorde foi 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, a tarefa era lançar capacidades apenas na AWS e na virtualização, mas depois, como costuma acontecer, os requisitos mudaram.
À luz disto, ficou claro que o nosso antigo padrão de combinar recursos num sistema de orquestração não era adequado – no caso em que os clusters são muito remotos e geridos por diferentes fornecedores.
Além disso. Quando todas as equipes trabalham no mesmo cluster, vários serviços com NodeSelectors instalados incorretamente podem voar para o host “estrangeiro” de outra equipe e utilizar recursos lá, e se o taint for definido, haverá solicitações constantes de que um ou outro serviço não está funcionando, não distribuído corretamente devido ao fator humano. Outro problema foi calcular o custo, especialmente considerando os problemas na distribuição de serviços entre os nós.
Outra história foi a emissão de direitos aos funcionários: cada equipe queria estar “à frente” do cluster e gerenciá-lo completamente, o que poderia causar um colapso total, já que as equipes são basicamente independentes umas das outras.
O que fazer?
Tendo em conta o exposto e o desejo das equipas de serem mais independentes, chegamos a uma conclusão simples: uma equipa - um cluster.
Então temos um segundo:
E então o terceiro cluster:
Aí começamos a pensar: digamos que em um ano nossos times terão mais de um cluster? Em diferentes áreas geográficas, por exemplo, ou sob o controlo de diferentes fornecedores? E alguns deles desejarão implantar rapidamente um cluster temporário para alguns testes.
Kubernetes completo viria! Acontece que isso é algum tipo de MultiKubernetes.
Ao mesmo tempo, todos precisaremos de alguma forma manter todos esses clusters, ser capazes de gerenciar facilmente o acesso a eles, bem como criar novos e desativar os antigos sem intervenção manual.
Já passou algum tempo desde o início da nossa jornada no mundo do Kubernetes e decidimos reexaminar as soluções disponíveis. Acontece que já existe no mercado - Rancher 2.2.
Na primeira fase de nossa pesquisa, o Rancher Labs já havia feito o primeiro lançamento da versão 2, mas embora pudesse ser aumentado muito rapidamente lançando um contêiner sem dependências externas com alguns parâmetros ou usando o gráfico HELM oficial, parecia grosseiro para nós, e não sabíamos se poderíamos confiar nesta decisão, se ela seria desenvolvida ou rapidamente abandonada. O paradigma cluster = clicks na própria UI também não nos convinha, e não queríamos ficar vinculados ao RKE, uma vez que é uma ferramenta com foco bastante restrito.
A versão Rancher 2.2 já tinha uma aparência mais funcional e, junto com as anteriores, trazia um monte de recursos interessantes prontos para uso, como integração com diversos provedores externos, ponto único de distribuição de direitos e arquivos kubeconfig, lançamento de um kubectl imagem com seus direitos na IU, namespaces aninhados, também conhecidos como projetos.
Também já havia uma comunidade formada em torno do Rancher 2, e um provedor chamado HashiCorp Terraform foi criado para gerenciá-la, o que nos ajudou a montar tudo.
O que aconteceu
Como resultado, acabamos com um pequeno cluster executando o Rancher, acessível a todos os outros clusters, bem como muitos clusters conectados a ele, cujo acesso a qualquer um deles pode ser concedido tão simplesmente quanto adicionar um usuário ao diretório ldap, independentemente de onde está localizado e quais recursos do provedor utiliza.
Usando gitlab-ci e Terraform, foi criado um sistema que permite criar um cluster de qualquer configuração em provedores de nuvem ou em 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. Ao mesmo tempo, a maioria dos módulos são conectados a partir de repositórios externos, de modo que tudo o que resta é passar variáveis ou descrever sua configuração personalizada para instâncias, o que ajuda a reduzir a porcentagem de repetição de código.
Claro, nossa jornada está longe de terminar e ainda temos muitas tarefas interessantes pela frente, como um único ponto de trabalho com logs e métricas de quaisquer clusters, service mesh, gitops para gerenciamento de cargas em um multicluster e muito mais. Esperamos que você ache nossa experiência interessante!
O artigo foi escrito por A. Antipov, A. Ganush, Platform Engineers.
Fonte: habr.com