APRENDER. PRATICAR. EVOLUIR.Rever o output que corresponde ao destino
Uma base comum reduz repetição, mas os overlays podem alterar nomes, namespace, réplicas, imagens e recursos. O laboratório original gera staging com duas réplicas e production com quatro. Analisa o output final pretendido, conservando a ligação à revisão das entradas e à versão da ferramenta. O nome do diretório não seleciona por si só o contexto de uma futura aplicação. Confirma o âmbito operacional separadamente. Usar o manifesto de staging para aprovar capacidade de production ignora alterações que podem determinar a viabilidade da mudança durante a janela.
Observar a semântica efetiva dos patches
O patch estratégico do exercício acrescenta resources ao contentor api. O resultado mantém metrics e as portas anteriores de api. A lista de contentores tem semântica de merge por nome, mas isso não significa que todas as listas e todos os patches funcionem assim. Outro input tenta remover containers/99 através de JSON patch e a geração falha. Não promove um ficheiro antigo só porque ainda existe na pasta. Liga sucesso da geração, revisão das entradas e identidade do artefacto. Um erro deve interromper a passagem de um output não correspondente à mudança atual.
Seguir o ConfigMap até ao consumidor
Ao mudar MODE=batch para MODE=validated, o generator produz outro nome com hash e atualiza a referência envFrom no Deployment. O laboratório confirma essa correspondência no output. Numa variante com o hash desativado no generator efetivo, os dados mudam mas o template mantém a mesma referência rules. Isto ajuda a explicar por que atualizar um ConfigMap não garante renovação de processos que usam variáveis de ambiente. Revê onde a opção está aplicada e o resultado efetivamente gerado. A aceitação deve confirmar os valores consumidos pela aplicação, respeitando disponibilidade durante qualquer substituição necessária.
Labels e namespaces têm efeitos diferentes
O overlay staging acrescenta environment ao template, preservando o selector app=ledger. Outro overlay inclui environment=blue nos selectors e o output muda. Se o Deployment apps/v1 já existe, essa atualização encontra um campo imutável. Distingue o pedido de identificação do pedido de alterar seleção; a solução pode ser preservar selectors ou planear uma transição deliberada. Definir metadata.namespace também não cria automaticamente o namespace nem as permissões. A geração deve ser seguida por revisão de existência, autorização e estado do destino. Nenhuma destas verificações de servidor foi executada no laboratório local.
Interpretar as nove gerações reais
O laboratório executou kubectl 1.37.1 com Kustomize 5.8.1 sobre onze ficheiros originais de entrada. Nove gerações incluem uma repetição do overlay production e uma rejeição esperada de patch inválido. Os oito grupos de observação registam ambientes, imagens, merge, ConfigMaps, hash desativado, labels, rejeição e repetibilidade. O digest de imagem com letras a é sintético e não foi consultado num registry. Os outputs iguais demonstram repetibilidade neste ensaio, não compatibilidade universal. A execução usou configuração vazia gerada para o exercício, sem consultar credenciais ou clusters reais.
Oficina de evidência entre geração e produção
Prepara uma revisão em três etapas. Primeiro, compara o output com a intenção: recurso, nome, namespace, template, referência de configuração e imagem. Depois, num ambiente autorizado, valida aceitação pelo servidor e políticas aplicáveis. Por fim, observa reconciliação e resultado funcional com os responsáveis do serviço. Nem uma geração local nem uma operação de dry-run no servidor executam por si só o workload e comprovam o seu comportamento. Na passagem em inglês, usa: “The manifests were generated locally; admission and workload behavior remain unverified.” Mantém essa diferença visível na decisão de prontidão.
Observação real: rules-b69md2f576 passa a rules-f8k6bd2264 e envFrom acompanha o nome. Com hash desativado, rules mantém o nome e o template fica igual apesar da mudança de dados.
Armadilhas comuns
Aplicar output antigo após erro; assumir substituição de qualquer lista; alterar selectors sem avaliar estado existente; tomar digest sintético por imagem existente; declarar consumo após gerar configuração.
Tópicos relacionados: Workloads e estado desejado · Recursos e agendamento · Configuração e dados
A configuração final precisa de revisão própria. Conserva identidade e referências, confirma o destino e separa a geração local da aceitação no servidor e do resultado funcional.
Referência: Declarative Management Using Kustomize · Kubernetes v1.37 concepts; current official documentation consulted 2026-09-30; cluster versions and plugin capabilities must be confirmed