Pacotes, overlays e aceitação da aplicação

Preparar a instalação com o alvo explícito

Para instalar uma release recon ausente ou atualizar a existente, uma intenção possível é helm upgrade --install recon ./chart -n team-a -f values.yaml. A existência do namespace e a identidade com que o comando atua são pré-requisitos a confirmar.

O nome da release não é o nome de todos os objetos produzidos. Inspeciona helm template recon ./chart -n team-a -f values.yaml antes de aplicar: procura imagens, réplicas, ServiceAccounts, recursos e endpoints inesperados. Renderizar sem contactar o cluster verifica outra coisa que a admissão e a disponibilidade.

A saída pode incluir Secrets; não a publiques em logs partilhados. Um resultado aceite precisa de condições dos workloads e de uma observação funcional, além do sucesso do comando.

Uma base e diferenças verificáveis

Num overlay Kustomize, resources pode referir ../../base, images pode substituir uma imagem e replicas pode selecionar pelo nome do workload. kubectl kustomize overlays/test produz o conjunto resultante para inspeção; kubectl apply -k overlays/test aplica-o ao contexto selecionado.

Em contraste, apply -f aponta para manifestos e não exprime essa construção do overlay. Confirma o contexto, namespace, nomes finais e labels no Pod template. Um patch que altera metadata.labels do Deployment não altera necessariamente spec.template.metadata.labels nem os selectors do Service.

A decisão deve comparar os objetos renderizados como um conjunto, incluindo referências a ConfigMaps e Secrets gerados, antes de mudar tráfego.

Criar uma referência de Secret que o consumidor consiga usar

Um Secret Opaque pode receber dados codificados em data ou texto em stringData; a API trata a conversão, mas o manifesto original continua sensível. Um Pod pode selecionar uma chave através de secretKeyRef, ou montar um volume secret. A referência tem de indicar o nome e a chave corretos no namespace do Pod.

Se uma chave obrigatória não existe, mudar readiness não resolve a configuração de arranque. Para uma rotação por ambiente, cria uma nova identidade de Secret, atualiza a referência no Pod template, confirma autenticação por novas instâncias e gere a retirada da credencial antiga.

Se usares um volume, verifica também se a aplicação relê o ficheiro; entrega e adoção são passos diferentes.

Recursos e configuração são parte do artefacto

O excerto abaixo é um fragmento de container, com nomes e valores fictícios; o Secret db-client deve existir previamente com a chave password. requests.cpu: 250m pede um quarto de CPU para scheduling e contabilização de quota. limits.cpu: 500m limita uso segundo o mecanismo do runtime; não reserva meio CPU adicional. requests.memory: 128Mi e limits.memory: 256Mi também têm funções distintas.

Um rollout com surge pode pedir quota adicional enquanto Pods antigos permanecem; calcula o período de coexistência antes da janela. Um Pod admitido ainda pode ficar Pending por falta de um nó elegível, mesmo que a quota do namespace permita a criação.

Seguir o caminho Ingress, Service e processo

Em networking.k8s.io/v1, um caminho Ingress declara path, pathType e backend.service.name/port. Por exemplo, host app.example.test, path /api e pathType Prefix devem conduzir a um Service existente e à porta publicada por esse Service. Se o Service oferece 80 e encaminha para targetPort 8080, o backend Ingress referencia 80, não a porta 8080 apenas por ser a do processo.

A IngressClass precisa de um controlador que a implemente; o comportamento de rewrite não deve ser presumido apenas pelo path. Para HTTPS, relaciona tls.hosts e secretName com um certificado que cubra o hostname. Confirma depois labels, EndpointSlices, prontidão, listener e políticas no percurso real do cliente.

Alterar a API sem perder a intenção

Um manifesto antigo que use backend.serviceName e servicePort não fica válido para networking.k8s.io/v1 só por mudar apiVersion. Reconstrói a estrutura backend.service e fornece pathType, conservando o hostname e a intenção de encaminhamento.

A validação local pode detetar problemas de estrutura; validação no servidor acrescenta regras do cluster, mas não prova o resultado funcional. Regista separadamente renderização, aceitação na API, condições dos Pods e acesso pelo cliente. Se o rollout falha, preserva evidência da geração e da configuração efetivamente consumida antes de fazer outro patch.

Recuperar o template anterior continua sem desfazer uma migração de dados incompatível.

Armadilhas comuns

Aceitar renderização como disponibilidade; confundir namespace da release com todos os objetos; mudar apiVersion sem migrar campos; usar targetPort onde se exige a porta do Service.