Pare de Copiar e Colar YAML do Kubernetes: Um Curso Prático de Kustomize

Toda equipe que executa aplicações no Kubernetes eventualmente encontra o mesmo monstro: três cópias quase idênticas dos mesmos arquivos de manifesto, uma para desenvolvimento, uma para staging e uma para produção, todas se desviando silenciosamente uma da outra. Uma porta muda em uma cópia, mas não nas outras. Uma correção de memória chega em staging e nunca alcança a produção. Ninguém consegue dizer qual arquivo é a verdade. Este curso ensina a ferramenta que a comunidade Kubernetes construiu para matar esse monstro de uma vez por todas: Kustomize, a ferramenta de customização oficial e sem templates que agora vem integrada ao próprio kubectl.

O Que é Kustomize, em Termos Simples?

Kustomize é uma ferramenta de linha de comando que customiza a configuração do Kubernetes sem o uso de templates. Em vez de preencher espaços reservados dentro dos seus arquivos YAML, ele mantém seus manifestos como YAML simples e válidos o tempo todo e descreve cada diferença específica de ambiente em um pequeno arquivo de instrução chamado kustomization. Pense nele como um editor cuidadoso que revisa um documento: ele adiciona uma etiqueta aqui, altera um número ali e te entrega o resultado final, enquanto o original permanece intacto no disco.

Algumas palavras de vocabulário te guiarão por toda a ferramenta. Uma kustomization é essa folha de instruções, sempre nomeada como kustomization.yaml, e a pasta que a contém é chamada de sua root. Uma base é qualquer kustomization para a qual outra aponta; um overlay é uma kustomization que adiciona mudanças sobre uma base sem nunca modificar seus arquivos; e o resultado final customizado que você implanta é chamado de variante. Construa um overlay para desenvolvimento e outro para produção, e você terá duas variantes da mesma aplicação, diferenciando-se apenas de formas controladas e revisáveis.

Tudo é conduzido por um comando, kustomize build, que lê uma pasta de destino e imprime o YAML final como texto simples. Ele não altera nada: é uma máquina de visualização. Somente quando você deliberadamente aplica a saída, normalmente com kubectl apply -k, é que algo chega ao cluster. Essa disciplina de build-then-apply é a espinha dorsal do GitOps, a filosofia de trabalho onde um repositório Git é a única fonte de verdade para o que roda no seu cluster, e cada mudança é um commit revisado e auditável.

Fundamentos do Kustomize, Instalação e Primeiro Build

O curso começa com os fundamentos: o que é Kustomize, por que a comunidade escolheu a customização sem templates em vez de templating, e o vocabulário acima. Em seguida, você coloca a mão na massa imediatamente. Você instala a CLI oficial do Kustomize fixada em uma versão específica, prova sua conexão com o cluster e cria sua primeira kustomization a partir de dois manifestos comuns, um Deployment e um Service.

A primeira prática proporciona um momento que todo iniciante lembra: uma linha, kustomize edit set namespace, e a saída do build subitamente coloca cada recurso no namespace que você escolheu, sem um único byte alterado nos arquivos originais. Você implanta esse resultado em um cluster Kubernetes real com kubectl apply -k, verifica se os pods estão rodando e limpa tudo com o comando de delete correspondente. Desde a primeira sessão, você está executando o loop profissional: edit, build, read, apply.

O Arquivo kustomization: Generators e Transformers Comuns

O módulo dois abre o próprio arquivo kustomization. A documentação oficial o descreve como quatro listas processadas em ordem estrita: resources, o que carregar; generators, o que criar; transformers, o que modificar; e validators, o que pode falhar no build. Entender essa ordem é o que torna os builds do Kustomize previsíveis e depuráveis.

Generators são o primeiro superpoder. Em vez de escrever objetos de configuração manualmente, você declara um configMapGenerator ou um secretGenerator alimentado por valores simples ou por arquivos, e o Kustomize produz recursos de ConfigMap e Secret corretos automaticamente. Os nomes gerados carregam um sufixo de hash de conteúdo, e esse hash é um recurso de segurança: altere a configuração, o nome muda, e cada pod que o referencia reinicia de forma limpa com os novos valores. Sem configurações obsoletas, sem reinicializações manuais, sem pods inconsistentes.

A segunda metade do módulo cobre os transformers comuns, os campos de uma linha que as equipes usam diariamente: namePrefix e nameSuffix para renomeação segura, namespace para posicionar um build inteiro, labels e commonAnnotations para metadados de propriedade, images para fixar versões e replicas para escalonamento. Cada um é um único comando de edição, cada um é visível na saída do build antes de qualquer coisa tocar o cluster e, juntos, eles remodelam uma aplicação inteira sem tocar em um manifesto.

Patching Recursos: Strategic Merge, JSON 6902 e Replacements

Algumas mudanças são específicas demais para campos de uma linha: o limite de memória de um container, uma única variável de ambiente, uma operação profunda dentro de uma lista. O módulo três ensina as duas técnicas oficiais de patch. Strategic merge patches parecem YAML parcial: eles nomeiam o recurso de destino e alteram apenas os campos que você menciona, deixando todo o resto intacto. JSON patches vêm de um padrão da internet, RFC 6902, e expressam mudanças como operações compactas com caminhos precisos dentro do documento, o que os torna perfeitos para edições cirúrgicas em listas, como remover uma variável de ambiente sem reescrever a lista.

Ambas as técnicas vivem no mesmo campo de patches modernos, cada uma pareada com um seletor de destino que pode corresponder a recursos por kind, por nome ou por labels, para que um pequeno patch possa alcançar vários recursos de uma só vez. O módulo fecha com replacements, que conectam valores entre recursos automaticamente: um Deployment aprende o nome do Service à sua frente no momento do build, para que renomear o Service atualize o Deployment no próximo build, sem cópias obsoletas em lugar nenhum.

Overlays, Variantes e Integração com Helm

O módulo final monta o fluxo de trabalho completo. Você constrói a árvore padrão da indústria, uma base neutra mais overlays de dev, staging e produção, produz cada variante independentemente e faz o diff de duas variantes para mostrar exatamente onde elas divergem: três mudanças controladas, linha por linha, a evidência que um gerente de release deseja ver. Você também conhece os components, os pacotes opcionais que ambientes individuais podem ligar ou desligar, como feature flags expressas na estrutura de pastas.

Depois vem a ponte para o Helm, o gerenciador de pacotes do mundo Kubernetes. Os charts da comunidade são templates, que é precisamente o que o Kustomize evita, então o curso ensina a combinação pragmática que as equipes reais utilizam: inflar um chart com o suporte nativo do Kustomize para Helm, sobrescrever seus valores inline e fazer o post-render de suas próprias convenções, seu namespace, seus labels, seus patches, sobre os recursos simples que saem, tudo sem fazer o fork do chart. O curso termina executando o loop completo de GitOps de ponta a ponta: arquivos em um repositório, build e diff como visualização, apply como entrega, revert como rollback.

O Que Você Será Capaz de Fazer

Após quatro módulos e oito práticas práticas contra um cluster real, você poderá instalar e operar a CLI do Kustomize, gerar ConfigMaps e Secrets com segurança com rollouts automáticos, remodelar recursos com os seis transformers comuns, aplicar patch em qualquer coisa com qualquer uma das notações oficiais, conectar valores entre recursos para que nunca se desviem, gerenciar árvores de variantes de dev/staging/prod e adotar charts do Helm fazendo o post-render para os padrões da sua equipe.

Primeiros Passos

Cada módulo combina um conjunto teórico com uma prática gravada, passo a passo, executada contra um cluster Kubernetes real, seguida por uma verificação de conhecimento de dez perguntas. As práticas se baseiam umas nas outras: a primeira deixa sua estação de trabalho com o Course Baseline instalado, e cada sessão posterior começa a partir de lá. Se você está pronto para parar de copiar e colar YAML e começar a customizar configurações da maneira declarativa, comece pelo Módulo 1 e construa sua primeira kustomization hoje.