Observação. trad.: A adoção do Kubernetes no GitLab é considerada um dos dois principais fatores que contribuem para o crescimento da empresa. Porém, até recentemente, a infraestrutura do serviço online GitLab.com era construída em máquinas virtuais, e há apenas cerca de um ano começou sua migração para K8s, que ainda não está concluída. Temos o prazer de apresentar a tradução de um artigo recente de um engenheiro SRE do GitLab sobre como isso acontece e quais conclusões os engenheiros participantes do projeto tiram.
Há cerca de um ano, nossa divisão de infraestrutura vem migrando todos os serviços executados no GitLab.com para o Kubernetes. Durante esse período, encontramos problemas relacionados não apenas à migração de serviços para o Kubernetes, mas também ao gerenciamento da implantação híbrida durante a transição. As valiosas lições que aprendemos serão discutidas neste artigo.
Desde o início do GitLab.com, seus servidores rodavam na nuvem em máquinas virtuais. Essas máquinas virtuais são gerenciadas pelo Chef e instaladas usando nosso . caso a aplicação precise ser atualizada, consiste em simplesmente atualizar a frota de servidores de forma coordenada e sequencial por meio de um pipeline de CI. Este método - embora lento e um pouco - garante que o GitLab.com use as mesmas práticas de instalação e configuração dos usuários offline (autogerenciado) Instalações do GitLab usando nossos pacotes Linux para isso.
Usamos esse método porque é extremamente importante vivenciar todas as tristezas e alegrias que os membros comuns da comunidade vivenciam ao instalar e configurar suas cópias do GitLab. Essa abordagem funcionou bem por algum tempo, mas quando o número de projetos no GitLab ultrapassou 10 milhões, percebemos que ela não atendia mais às nossas necessidades de escalonamento e implantação.
Primeiros passos para o Kubernetes e o GitLab nativo da nuvem
O projeto foi criado em 2017 para preparar o GitLab para implantação na nuvem e para permitir que os usuários instalem o GitLab em clusters Kubernetes. Sabíamos então que migrar o GitLab para o Kubernetes aumentaria a escalabilidade da plataforma SaaS, simplificaria as implantações e melhoraria a eficiência dos recursos computacionais. Ao mesmo tempo, muitas das funções do nosso aplicativo dependiam de partições NFS montadas, o que retardava a transição das máquinas virtuais.
O impulso para o nativo da nuvem e o Kubernetes permitiu que nossos engenheiros planejassem uma transição gradual, durante a qual abandonamos algumas das dependências do aplicativo no armazenamento de rede enquanto continuamos a desenvolver novos recursos. Desde que começamos a planejar a migração no verão de 2019, muitas dessas limitações foram resolvidas, e o processo de migração do GitLab.com para o Kubernetes já está bem encaminhado!
Recursos do GitLab.com no Kubernetes
Para GitLab.com, usamos um único cluster regional do GKE que gerencia todo o tráfego de aplicativos. Para minimizar a complexidade da migração (já complicada), nos concentramos em serviços que não dependem de armazenamento local ou NFS. GitLab.com usa uma base de código Rails predominantemente monolítica e roteamos o tráfego com base nas características da carga de trabalho para diferentes endpoints que são isolados em seus próprios pools de nós.
No caso do frontend, esses tipos são divididos em requisições para web, API, Git SSH/HTTPS e Registry. No caso do backend, dividimos os trabalhos na fila de acordo com diversas características dependendo , o que nos permite definir objetivos de nível de serviço (SLOs) para diversas cargas de trabalho.
Todos esses serviços GitLab.com são configurados usando um gráfico GitLab Helm não modificado. A configuração é realizada em subgráficos, que podem ser habilitados seletivamente à medida que migramos gradativamente os serviços para o cluster. Embora tenhamos decidido não incluir alguns de nossos serviços com estado na migração, como Redis, Postgres, GitLab Pages e Gitaly, o uso do Kubernetes nos permite reduzir radicalmente o número de VMs que o Chef gerencia atualmente.
Visibilidade e gerenciamento de configuração do Kubernetes
Todas as configurações são gerenciadas pelo próprio GitLab. Para isso, são utilizados três projetos de configuração baseados em Terraform e Helm. Tentamos usar o próprio GitLab sempre que possível para executar o GitLab, mas para tarefas operacionais temos uma instalação separada do GitLab. Isso é necessário para garantir que você não dependa da disponibilidade do GitLab.com ao executar implantações e atualizações do GitLab.com.
Embora nossos pipelines para o cluster Kubernetes sejam executados em uma instalação separada do GitLab, existem espelhos dos repositórios de código que estão disponíveis publicamente nos seguintes endereços:
- — Estrutura de configuração GitLab.com para o gráfico GitLab Helm;
- - Contém configurações para serviços que não estão diretamente associados ao aplicativo GitLab. Isso inclui configurações para registro e monitoramento de cluster, bem como ferramentas integradas como PlantUML;
- — Configuração do Terraform para Kubernetes e infraestrutura de VM legada. Aqui você configura todos os recursos necessários para executar o cluster, incluindo o próprio cluster, pools de nós, contas de serviço e reservas de endereços IP.
A visualização pública é mostrada quando alterações são feitas. com um link para a comparação detalhada que o SRE analisa antes de fazer alterações no cluster.
Para SRE, o link leva a uma comparação detalhada na instalação do GitLab, que é usada para produção e cujo acesso é limitado. Isso permite que os funcionários e a comunidade, sem acesso ao projeto operacional (que é aberto apenas aos SREs), visualizem as alterações propostas na configuração. Ao combinar uma instância pública do GitLab para código com uma instância privada para pipelines de CI, mantemos um fluxo de trabalho único e, ao mesmo tempo, garantimos independência do GitLab.com para atualizações de configuração.
O que descobrimos durante a migração
Durante a mudança, foi adquirida experiência que aplicamos em novas migrações e implantações no Kubernetes.
1. Aumento de custos devido ao tráfego entre zonas de disponibilidade
Estatísticas de saída diária (bytes por dia) para a frota de repositórios Git em GitLab.com
O Google divide sua rede em regiões. Estas, por sua vez, estão divididas em zonas de acessibilidade (AZ). A hospedagem Git está associada a grandes quantidades de dados, por isso é importante controlarmos a saída da rede. Para o tráfego interno, a saída só é gratuita se permanecer na mesma zona de disponibilidade. No momento em que este livro foi escrito, atendemos aproximadamente 100 TB de dados em um dia de trabalho típico (e isso é apenas para repositórios Git). Os serviços que residiam nas mesmas máquinas virtuais em nossa antiga topologia baseada em VM agora são executados em diferentes pods do Kubernetes. Isto significa que algum tráfego que anteriormente era local para a VM poderia potencialmente viajar para fora das zonas de disponibilidade.
Os clusters regionais do GKE permitem abranger várias zonas de disponibilidade para redundância. Estamos considerando a possibilidade para serviços que geram grandes volumes de tráfego. Isto reduzirá os custos de saída, mantendo ao mesmo tempo a redundância no nível do cluster.
2. Limites, solicitações de recursos e escalabilidade
O número de réplicas que processam o tráfego de produção em Registry.gitlab.com. O tráfego atinge o pico às 15:00 UTC.
Nossa história de migração começou em agosto de 2019, quando migramos nosso primeiro serviço, o GitLab Container Registry, para o Kubernetes. Este serviço de missão crítica e de alto tráfego foi uma boa escolha para a primeira migração porque é um aplicativo sem estado com poucas dependências externas. O primeiro problema que encontramos foi um grande número de pods despejados devido à falta de memória nos nós. Por conta disso, tivemos que alterar solicitações e limites.
Foi descoberto que no caso de uma aplicação onde o consumo de memória aumenta com o tempo, valores baixos para solicitações (reserva de memória para cada pod) aliados a um limite rígido “generoso” de uso levavam à saturação (saturação) nós e um alto nível de despejos. Para lidar com esse problema, foi . Isso tirou a pressão dos nós e garantiu que os pods tivessem um ciclo de vida que não colocasse muita pressão no nó. Agora iniciamos as migrações com solicitações e valores de limite generosos (e quase idênticos), ajustando-os conforme necessário.
3. Métricas e registros
A divisão de infraestrutura concentra-se na latência, taxas de erro e saturação com (SLO) vinculado a .
Durante o ano passado, um dos principais acontecimentos na divisão de infraestruturas foram as melhorias na monitorização e no trabalho com os SLO. Os SLOs permitiram-nos definir metas para serviços individuais que monitorizámos de perto durante a migração. Mas mesmo com esta observabilidade melhorada, nem sempre é possível ver imediatamente os problemas utilizando métricas e alertas. Por exemplo, ao nos concentrarmos na latência e nas taxas de erro, não cobrimos totalmente todos os casos de uso de um serviço em migração.
Esse problema foi descoberto quase imediatamente após a migração de algumas cargas de trabalho para o cluster. Tornou-se especialmente grave quando tivemos que verificar funções para as quais o número de solicitações era pequeno, mas que tinham dependências de configuração muito específicas. Uma das principais lições da migração foi a necessidade de levar em conta não apenas as métricas no monitoramento, mas também os logs e a “cauda longa”. (isso é sobre no gráfico - aprox. trad.) erros. Agora, para cada migração, incluímos uma lista detalhada de consultas de log (registrar consultas) e planeje procedimentos de reversão claros que possam ser transferidos de um turno para outro se surgirem problemas.
Atender as mesmas solicitações em paralelo na antiga infraestrutura de VM e na nova infraestrutura baseada em Kubernetes apresentou um desafio único. Ao contrário da migração lift-and-shift (transferência rápida de aplicativos “como estão” para uma nova infraestrutura; mais detalhes podem ser lidos, por exemplo, - Aproximadamente. trad.), o trabalho paralelo em VMs “antigas” e Kubernetes exige que as ferramentas de monitoramento sejam compatíveis com ambos os ambientes e sejam capazes de combinar métricas em uma única visualização. É importante usarmos os mesmos painéis e consultas de log para obter observabilidade consistente durante o período de transição.
4. Mudando o tráfego para um novo cluster
Para GitLab.com, parte dos servidores é dedicada a . O Canary Park atende nossos projetos internos e também pode . Mas ele foi projetado principalmente para testar alterações feitas na infraestrutura e no aplicativo. O primeiro serviço migrado começou aceitando uma quantidade limitada de tráfego interno, e continuamos a usar esse método para garantir que os SLOs sejam atendidos antes de enviar todo o tráfego para o cluster.
No caso de migração, isso significa que as solicitações para projetos internos são enviadas primeiro para o Kubernetes e, em seguida, transferimos gradualmente o restante do tráfego para o cluster, alterando o peso do back-end por meio do HAProxy. Durante a migração da VM para o Kubernetes, ficou claro que era muito benéfico ter uma maneira fácil de redirecionar o tráfego entre a infraestrutura antiga e a nova e, consequentemente, manter a infraestrutura antiga pronta para reversão nos primeiros dias após a migração.
5. Capacidades de reserva dos pods e sua utilização
Quase imediatamente, o seguinte problema foi identificado: os pods para o serviço Registry foram iniciados rapidamente, mas o lançamento dos pods para o Sidekiq demorou até . O longo tempo de inicialização dos pods Sidekiq se tornou um problema quando começamos a migrar cargas de trabalho para o Kubernetes para trabalhadores que precisavam processar trabalhos e escalar rapidamente.
Nesse caso, a lição foi que, embora o Horizontal Pod Autoscaler (HPA) do Kubernetes lide bem com o crescimento do tráfego, é importante considerar as características das cargas de trabalho e alocar capacidade ociosa para os pods (especialmente quando a demanda é distribuída de forma desigual). No nosso caso, houve um aumento repentino nos trabalhos, levando a um rápido escalonamento, o que levou à saturação dos recursos da CPU antes que tivéssemos tempo de escalar o pool de nós.
Há sempre a tentação de extrair o máximo possível de um cluster, no entanto, tendo inicialmente encontrado problemas de desempenho, estamos agora começando com um orçamento de pod generoso e reduzindo-o mais tarde, mantendo um olhar atento aos SLOs. O lançamento de pods para o serviço Sidekiq acelerou significativamente e agora leva cerca de 40 segundos em média. ganhou tanto o GitLab.com quanto nossos usuários de instalações autogerenciadas trabalhando com o gráfico oficial do GitLab Helm.
Conclusão
Depois de migrar cada serviço, ficamos felizes com os benefícios de usar o Kubernetes na produção: implantação de aplicativos mais rápida e segura, escalonamento e alocação de recursos mais eficiente. Além disso, as vantagens da migração vão além do serviço GitLab.com. Cada melhoria no gráfico oficial do Helm beneficia seus usuários.
Espero que você tenha gostado da história de nossas aventuras de migração para Kubernetes. Continuamos a migrar todos os novos serviços para o cluster. Informações adicionais podem ser encontradas nas seguintes publicações:
- «";
- «";
- .
PS do tradutor
Leia também em nosso blog:
- «";
- «";
- «";
- «".
Fonte: habr.com