Gitaly GA no Kubernetes: o fim do modelo híbrido no GitLab

Até ontem, gerenciar GitLab em Kubernetes significava manter duas realidades paralelas: um cluster para a aplicação e um exército de VMs só para o Gitaly. Esse modelo híbrido, repleto de complexidade operacional e custos extras, acaba de se tornar obsoleto.

O fim do modelo híbrido no GitLab

Por anos, o Gitaly — serviço de repositório Git do GitLab — foi oficialmente suportado apenas em máquinas virtuais ou bare‑metal. Rodá-lo em Kubernetes era uma gambiarra: workarounds manuais, falhas imprevisíveis e uma manutenção heróica que consumia tempo e recursos das equipes DevOps.

Com o GitLab 18.11, essa era termina. O Gitaly agora está disponível em disponibilidade geral (GA) para execução nativa em Kubernetes. Isso significa que times podem consolidar toda a stack GitLab em um único cluster K8s, com desempenho validado por benchmarks e uma arquitetura projetada para ambientes cloud‑native.

O impacto é direto: redução de custos de infraestrutura, simplificação de monitoramento e eliminação da necessidade de gerenciar duas plataformas distintas — VMs e Kubernetes.

O que mudou — e por que isso importa

Até a versão 18.10, a equipe do GitLab Engineering resolveu os dois maiores gargalos técnicos que impediam a execução nativa em K8s.

Isolamento de processos Git via cgroups

O containerd não expõe o sistema de cgroups de forma completa para containers comuns. Para que o Gitaly gerencie corretamente o isolamento de processos Git — fundamental para segurança e performance — um init container monta /sys/fs/cgroup com as opções corretas antes do Gitaly iniciar.

Mecanismo de retry inteligente no cliente Rails

Quando um Pod do Gitaly é reiniciado (upgrade, eviction, etc.), o cliente Rails automaticamente retenta a operação. Isso garante zero downtime em operações como clone, fetch e push, desde que o número de réplicas seja maior que 1.

“Nenhuma requisição é perdida — graças à lógica de retry embutida no Rails.”

O resultado? Uma operação transparente que elimina a necessidade de gerenciar um parque separado de VMs.

Benchmarks que falam por si

Para validar a abordagem, a equipe do GitLab executou testes controlados de upgrade do cluster K8s, comparando as taxas de sucesso com um ambiente de VMs tradicional.

Os números mostram equivalência prática entre os dois ambientes, mesmo durante o momento mais crítico — a atualização dos Pods. A pequena degradação no git pull (99,16%) é atribuída à latência adicional dos retries do cliente, um custo aceitável para ganhar resiliência em malhas dinâmicas.

Nota técnica: Durante upgrades, o Gitaly em K8s pode apresentar latência ligeiramente maior nas primeiras requisições após a substituição de Pods, mas nenhuma requisição é perdida.

Implicações técnicas: como funciona por baixo dos panos

1. Cgroups e o init container

O init container monta /sys/fs/cgroup com as opções corretas, contornando as limitações do containerd. Isso garante isolamento adequado dos processos Git, essencial para segurança e performance.

2. Retry do cliente

Quando um Pod do Gitaly é reiniciado, o cliente Rails automaticamente retenta a operação. Isso garante zero downtime em operações como clone, fetch e push, desde que o número de réplicas seja maior que 1.

3. Ausência de suporte para Gitaly Cluster (HA)

O componente de alta disponibilidade do Gitaly Cluster — o Praefect — ainda não é suportado em Kubernetes. Para cenários que exigem replicação síncrona e failover automático, a recomendação oficial permanece usar VMs.

✅ Perfeito para: ambientes com single-node Gitaly ou replicação assíncrona.

❌ Não indicado para: workloads que exigem HA com zero perda de dados (enquanto o suporte ao Praefect não chega).

O que isso significa para o mercado de DevOps

Consolidação total da stack

Equipes que já operam GitLab em Kubernetes podem remover completamente as VMs dedicadas ao Gitaly. Isso reduz custos de infraestrutura, simplifica o monitoramento (um único cluster, um único pipeline de upgrade) e elimina a complexidade de manter duas plataformas distintas.

Atração de novos usuários cloud‑native

A barreira para adotar GitLab em ambientes Kubernetes acaba de cair. Startups e empresas que já investem em K8s como padrão agora podem ter um GitLab totalmente nativo, sem precisar de conhecimento especializado em VMs.

Aceleração da adoção de GitLab

Com a promessa de desempenho equivalente e operação simplificada, o GitLab se torna ainda mais atraente para times que priorizam infraestrutura como código e GitOps.

Limitações e riscos a considerar

• Gitaly Cluster (Praefect) ainda não suportado. Se sua arquitetura exige alta disponibilidade com replicação síncrona, aguarde.
• Latência adicional durante upgrades. Os retries adicionam alguns milissegundos; em workloads extremamente sensíveis, pode ser perceptível.
• Configuração correta de cgroups. A montagem via init container precisa ser feita exatamente como documentado; erros podem causar falhas de isolamento.

Recomendação: Para ambientes de produção que não exigem HA síncrona, a migração pode começar agora. Para cenários com Praefect, aguarde a próxima release.

Visão Metatron

O GA do Gitaly no Kubernetes representa um marco na democratização da infraestrutura Git em ambientes cloud‑native. Não se trata apenas de mover um workload para containers — é a eliminação de uma ponte híbrida que forçava times a dominar duas plataformas.

Acreditamos que, nos próximos seis meses, veremos:

• O surgimento de Helm charts otimizados para Gitaly, com tuning automático de cgroups.
• A rápida adoção por plataformas de DevOps que já usam GitLab e K8s como padrão.
• A chegada do suporte ao Gitaly Cluster em K8s, fechando o ciclo para HA.

Resumo prático: Para equipes que buscam simplicidade operacional sem abrir mão de performance, este é o momento de migrar. O futuro do GitLab em Kubernetes é sólido — e já chegou.

Quer testar na prática? Acesse a documentação oficial do GitLab 18.11 e configure seu primeiro Gitaly nativo em K8s hoje mesmo.