APRENDER. PRATICAR. EVOLUIR.Readiness muda elegibilidade para tráfego
A API tem endpoints separados para readiness e liveness. Remover o ficheiro /tmp/ready faz a primeira devolver 503, mas mantém o processo e a resposta normal em execução. O Pod continua Running, passa a não pronto e conserva o mesmo UID e contador de reinícios. O EndpointSlice passa a ready=false e o pedido habitual ao Service falha. A chamada direta ao IP do Pod continua a responder. Assim, readiness não funciona como firewall: informa os mecanismos que usam esse estado, enquanto outros caminhos podem continuar acessíveis. Num incidente, interpreta a condição em conjunto com a configuração do Service e o percurso efetivamente utilizado.
Uma exceção de publicação não cura a aplicação
O ensaio ativa temporariamente publishNotReadyAddresses no Service. A condição ready do EndpointSlice passa a true apesar de o Pod continuar não pronto; o pedido normal volta a chegar à API. Isto demonstra por que não basta ler um campo ready sem identificar a sua origem e as opções do Service. A experiência não recomenda esta alteração como mitigação universal. Numa aplicação real, a probe pode indicar incapacidade de servir pedidos com segurança. O guião repõe a opção false, confirma a retirada do destino e só recupera readiness depois de restaurar o marcador. A decisão deve preservar o significado operacional da probe.
Recuperar sem reiniciar
Ao repor /tmp/ready, o guião observa o Pod pronto, o destino elegível e a resposta pelo Service. O contador de reinícios permanece igual. Esta sequência mostra uma recuperação que não precisa de substituir o contentor. Num serviço real, a causa pode exigir corrigir uma dependência ou concluir uma inicialização; o marcador é apenas o mecanismo sintético do exercício. Evita apagar Pods antes de recolher evidência ou quando a ação não trata a causa. Regista a transição e confirma o resultado funcional. Uma probe recuperada com backlog ainda acumulado pode justificar manter o incidente aberto e acompanhar o escoamento do trabalho.
Liveness e identidade do Pod
A remoção de /tmp/live causa falhas suficientes da liveness para reiniciar o contentor. O guião confirma que o UID do Pod se mantém, o contador aumenta e a API volta a ficar pronta. O código de arranque recria os marcadores, razão específica para esta recuperação. Os logs do contentor anterior contêm a mensagem de arranque sintética e podem ser consultados com --previous. Não representam um arquivo completo de todas as instâncias ou de todos os reinícios. Guarda a evidência relevante antes de perder o contexto e distingue reinício do contentor de substituição do Pod pelo controlador.
Falha antes de o processo arrancar
Outro Pod depende obrigatoriamente da chave MODE num ConfigMap ainda inexistente. O estado de espera do contentor indica CreateContainerConfigError e não há arranque da aplicação. Criar o ConfigMap com MODE=batch permite a execução; o processo imprime batch e fica pronto sem um reinício de processo já executado. O problema estava na preparação da configuração, não numa liveness demasiado exigente. Inspeciona a mensagem, a referência e o namespace antes de mudar probes ou aumentar recursos. Num sistema real, confirma ainda quem deve produzir esse objeto e se a ordem de entrega garante a sua disponibilidade no momento necessário.
Configuração declarada e configuração consumida
Depois do arranque, o ConfigMap muda para MODE=online, mas uma leitura do ambiente dentro do contentor continua a devolver batch. O valor foi fornecido como variável de ambiente no arranque; alterar o objeto não reescreve o ambiente do processo existente. Define como renovar o consumidor de forma controlada e valida o valor efetivo depois da mudança. O laboratório não executa esse rollout adicional nem mede propagação de volumes ConfigMap. A evidência cobre a diferença entre objeto e ambiente nesta configuração concreta. O handover deve incluir método de atualização, critérios funcionais, rollback compatível e limitações ainda por validar.
kubectl --context OWNED -n LAB get pod POD -o json
kubectl --context OWNED -n LAB describe pod POD
kubectl --context OWNED -n LAB logs POD -c api --previous
# Inspect Ready, container waiting reason, restartCount and the relevant probe.
# A prior-container log is not a complete historical log archive.Remover o marcador de readiness retirou o destino do tráfego habitual sem reinício; remover o de liveness causou um reinício no mesmo Pod.
Armadilhas comuns
Running como serviço pronto; readiness como isolamento de rede; contornar readiness como recuperação; atualizar ConfigMap como alterar env do processo.
Tópicos relacionados: Tráfego e probes · Operação e recuperação
Liga cada observação à decisão que suporta e confirma a recuperação pelo caminho do consumidor, mantendo os limites do ensaio explícitos.
Referência: Configure probes · Kubernetes v1.37 concepts; current official documentation consulted 2026-09-30; cluster versions and plugin capabilities must be confirmed