Gerenciar aplicações no Kubernetes já é complexo por natureza. Quando entram em cena múltiplos ambientes — desenvolvimento, homologação e produção — o problema costuma piorar: arquivos YAML duplicados, pequenas diferenças difíceis de rastrear e risco constante de erro humano. É exatamente esse cenário que o Kustomize resolve.
O que é o Kustomize
O Kustomize é uma ferramenta nativa do Kubernetes voltada para a customização declarativa de manifestos YAML. Em vez de copiar e editar arquivos para cada ambiente, você define uma base comum e aplica variações por meio de sobreposições.
Desde a versão 1.14 do Kubernetes, o Kustomize já vem integrado ao kubectl, o que elimina dependências extras e simplifica a adoção.
Para que serve o Kustomize
Na prática, o Kustomize é usado para:
Gerenciar múltiplos ambientes a partir de uma única base de configuração.
Customizar recursos sem alterar os arquivos originais.
Aplicar mudanças como labels, anotações, imagens e réplicas de forma declarativa.
Reduzir duplicação e aumentar a consistência dos manifestos.
Tudo isso usando apenas YAML, sem templates ou lógica condicional.
Por que o Kustomize é tão atrativo
O Kustomize resolve problemas reais do dia a dia no Kubernetes:
Reutilização: uma base única pode ser reaproveitada em quantos ambientes forem necessários.
Simplicidade: nada de templating complexo, só YAML puro.
Integração nativa: funciona direto com kubectl apply -k.
Flexibilidade: suporte a patches, geração de ConfigMaps, Secrets e troca de imagens.
Ele não tenta ser um gerenciador de pacotes. A proposta é ser previsível, legível e fácil de manter.
O que é o arquivo kustomization.yaml
O coração do Kustomize é o arquivo kustomization.yaml. É nele que você define quais recursos entram na composição final e quais customizações serão aplicadas.
Os campos mais comuns incluem:
resources, que aponta para os manifestos base.
patches, usados para modificar recursos existentes.
images, para substituir versões de imagens de containers.
configMapGeneratoresecretGenerator, para gerar configurações dinamicamente.
O modelo é simples: uma base reutilizável e overlays específicos por ambiente.
Kustomize na prática: base e overlays
Um padrão muito usado é separar os manifestos em base e overlays.
Estrutura típica de diretórios:
A pasta base contém a definição padrão da aplicação. Já os overlays ajustam apenas o que muda entre ambientes, como número de réplicas ou versão da imagem.
Exemplo de patch simples para alterar réplicas:
Aplicando as configurações
Depois de definir base e overlays, aplicar no cluster é direto:
Você pode inclusive combinar isso com namespaces diferentes, mantendo isolamento total entre ambientes sem duplicar YAML.
Patches: o grande diferencial
Os patches são um dos pontos mais fortes do Kustomize. Em vez de redefinir um Deployment inteiro, você altera apenas os campos necessários. Isso reduz ruído, evita divergência e facilita revisões de código.
Existem patches estratégicos e patches JSON, o que dá bastante liberdade para customizações mais avançadas.
Kustomize vs Helm
Essa comparação é inevitável. Helm e Kustomize não competem diretamente — eles se complementam.
O Helm resolve empacotamento, versionamento e distribuição de aplicações.
O Kustomize foca exclusivamente em customização de manifestos.
Muitas equipes usam Helm para instalar aplicações e Kustomize para adaptar essas aplicações à realidade de cada ambiente.
Limitações e cuidados
Apesar de simples, o Kustomize pode virar bagunça se mal organizado. Muitos overlays, patches mal documentados e falta de padrão tornam o setup difícil de manter.
A regra é clara: estrutura bem definida e documentação mínima salvam horas de troubleshooting no futuro.
Conclusão
O Kustomize é uma solução elegante para um problema clássico do Kubernetes: customizar sem duplicar. Ele mantém os manifestos limpos, reduz riscos operacionais e se encaixa perfeitamente em fluxos GitOps e CI/CD.
Se a sua dor é gerenciar múltiplos ambientes com YAML repetido, o Kustomize não é luxo — é ferramenta essencial.
