APRENDER. PRATICAR. EVOLUIR.1. Começar pelo contrato de execução
Uma equipa fictícia de fundos prepara uma API e um batch de reconciliação. A API presta serviço continuado; o batch termina depois de produzir resultados. Num Job com seis conclusões pretendidas e paralelismo de dois, não se prometem seis execuções simultâneas nem ausência de retries. Escreve a condição de sucesso da aplicação e a forma de reconhecer trabalho já realizado. Para preparação finita, um init container normal deve concluir. Um watcher infinito colocado nesse init impede o arranque da aplicação. Identifica esta condição antes de aumentar réplicas ou investigar probes de um processo que ainda não começou.
2. Ligar o ficheiro ao consumidor
O init escreve settings.json em /out, montado no volume prepared. A aplicação lê /config/settings.json. O mesmo volume precisa de ser montado em /config no container consumidor; partilhar um Pod não partilha todos os diretórios das imagens. No exercício, desenha volume, mountPath do produtor e mountPath do consumidor antes de corrigir o manifest. Escolhe também a durabilidade: emptyDir é adequado para dados temporários do Pod. Com medium: Memory, os ficheiros tmpfs acrescentam consumo de memória ao container que escreve. Uma cache grande pode competir com a memória do processo, pelo que observar apenas heap é insuficiente.
3. Distinguir distribuição e adoção de configuração
Um objeto novo não significa que os consumidores já o usam. Com configMapKeyRef, o processo recebe o valor ao arrancar; alterar o ConfigMap não reescreve o ambiente existente. Um volume normal pode receber projeções posteriores, enquanto subPath não acompanha automaticamente as atualizações. Mesmo um ficheiro atualizado precisa de ser lido pela aplicação. Para um ConfigMap imutável rules-v1, prepara rules-v2, atualiza a referência no template e valida o comportamento dos novos Pods. Mantém a versão anterior enquanto for necessária à recuperação. No exercício de mesa, assinala separadamente objeto criado, referência alterada, Pod substituído e função comprovada.
4. Localizar o template e interpretar o rollout
Labels no objeto Deployment e labels em spec.template.metadata pertencem a níveis diferentes. O Service seleciona Pods; um label externo não os altera automaticamente. Escalar replicas também não cria por si só uma revisão de template. Para três réplicas e limites de 25%, maxSurge arredonda para um e maxUnavailable para zero. Esta é uma regra de estratégia, não garantia de capacidade ou de tempos de recuperação. Se aparece ProgressDeadlineExceeded, a falta de progresso foi sinalizada; sem automatismo adicional não se pode declarar rollback concluído. Conserva eventos anteriores, pois podem mostrar a primeira causa de bloqueio.
5. Calcular quota e rever identidade
Com quota requests.memory de 3Gi, uso contabilizado de 2560Mi e pedido novo de 768Mi, o total é 3328Mi. Como 3Gi são 3072Mi, faltam 256Mi de capacidade contabilizada. Não confundas rejeição de admissão com falta de memória física num nó. Noutra falha, /shared pertence a UID 0 e grupo 2000 com modo 0770; um processo UID 10001 apenas no grupo 3000 não tem permissão nesse modelo. Revê identidade, grupos, modo e suporte do volume antes de remover controlos. fsGroup depende do tipo de volume e do driver; não o trates como correção universal. Em v1.37, emptyDir.mode é uma funcionalidade alpha, desativada por omissão e dependente de EmptyDirVolumeMode. Estes exercícios não a usam: raciocina com o proprietário, grupos e permissões observados e confirma o suporte do volume antes de propor fsGroup.
6. Entregar um plano verificável a RUN
Conclui a oficina com um manifest revisto, hipóteses e critérios de aceitação. A equipa deve saber que configuração cada consumidor usa, que recursos precisa durante o surge e o que acontece se o novo Pod não ficar pronto. Um ficheiro válido sintaticamente não comprova admissão, scheduling ou sucesso de negócio. Os exemplos desta aula foram comparados com a documentação v1.37, mantendo as condições explícitas de cada exercício. Os comandos de inspeção servem como roteiro para um laboratório autorizado e não foram executados num cluster nesta revisão. Regista essas fronteiras no handover.
# Fragment: Deployment spec.template.spec.containers[0]
env:
- name: RULESET
valueFrom:
configMapKeyRef:
name: rules-v2
key: ruleset
# Read-only inspection plan for an authorized lab
kubectl get deployment reconcile-api -n funds -o yaml
kubectl describe deployment reconcile-api -n funds
kubectl get resourcequota -n fundsNo caso de 4Gi, 3584Mi + 768Mi = 4352Mi excede 4096Mi por 256Mi. O prazo de progresso não cria essa margem.
Armadilhas comuns
ConfigMap criado como consumido; label externo como template; timeout como rollback; quota como uso instantâneo; permissões como problema de memória.
Tópicos relacionados: Deployments e recuperação · Serviços e políticas de rede
Liga ciclo de vida, configuração, identidade e capacidade antes de declarar o rollout concluído.
Referência: Deployments · CKAD Kubernetes v1.37