APRENDER. PRATICAR. EVOLUIR.Objeto pretendido e configuração efetiva
Configuração tem um caminho desde a definição até ao uso pelo processo. Em Kubernetes, uma variável de ambiente criada a partir de ConfigMap não muda automaticamente no container existente, e uma montagem subPath não recebe atualizações do objeto. Mesmo num volume normal já atualizado, a aplicação pode ler o ficheiro apenas no arranque. Num exercício, duas réplicas mantêm timeout antigo por mecanismos diferentes. Regista forma de consumo e valor efetivo, planeia ativação suportada e verifica cada réplica. ResourceVersion e checksum são evidência útil de etapas específicas, mas não substituem observar o comportamento ativo.
Probes com ações adequadas
Readiness responde à aptidão para receber tráfego; liveness pode desencadear restart quando a falha cumpre os critérios definidos. Uma dependência lenta não significa necessariamente que reiniciar a aplicação ajuda. Num cenário, todas as réplicas reiniciam quando a base de dados abranda, perdem caches e aumentam reconexões, ampliando a falha. Revê sinal, limiar e ação em conjunto e testa o modo de falha. Mantém uma distinção entre processo incapaz de recuperar e serviço temporariamente indisponível para tráfego. O resultado de uma probe também não comprova conclusão de operações de negócio já iniciadas.
Drain dentro do orçamento de terminação
O período de terminação precisa de cobrir o hook e o trabalho que resta ao processo. Com orçamento normal de sessenta segundos e preStop de quinze, não assumes outros sessenta depois do hook. Se o trabalho precisa de cinquenta e dois, a margem restante é insuficiente sem rever o plano. Retirar admissão de tráfego ou cancelar subscrição ajuda a limitar novas operações, mas não termina as existentes. Mede ligações, handlers e resultados pendentes; prepara conclusão ou recuperação com identidade preservada. Valida o comportamento sob carga representativa e não dependas de extensões incidentais como mecanismo de segurança.
Reload e coexistência de workers
Um serviço a responder pode continuar com configuração anterior. No NGINX, o master verifica e tenta aplicar a configuração no reload; se falhar, continua com a anterior. Quando resulta, novos workers podem coexistir com antigos que acabam de servir clientes existentes. Num exercício, observa erros de aplicação da configuração, revisão ativa e ligações antigas antes de declarar a mudança concluída. Não termines workers só por existirem duas gerações; avalia o trabalho pendente e o orçamento de drain. O procedimento deve distinguir disponibilidade, adoção e saída graciosa, com critérios mensuráveis para cada etapa.
Certificado local e caminho TLS real
Inspecionar o certificado renovado é apenas uma parte da validação. Em OpenSSL 3.5, checkend verifica expiração dentro da janela indicada; não comprova qual certificado o endpoint ativo apresenta nem a confiança do cliente. Num cenário, o ficheiro passa essa verificação, mas uma réplica ainda serve a cadeia antiga. Testa o caminho real com nome, cadeia e trust store adequados, identificando cada ponto de terminação TLS. Mantém a validação aberta até corrigir divergências ou aceitar explicitamente um estado temporário controlado. Não removas verificação de identidade para transformar uma falha em sucesso aparente.
Coexistência, gates e autonomia do RUN
Uma release deve funcionar nos estados intermédios do rollout. Se consumidores antigos rejeitam o formato novo, prepara leitura compatível antes de ativar a emissão desse formato e valida todas as combinações relevantes. Define ainda o fluxo que demonstra aceitação: consultas sem erro não substituem um gate de fecho diário. No handover, entrega revisão e valores efetivos, réplicas excluídas, medidas temporárias, owners, prazos e critérios de reversão. Num exercício, o deploy terminou mas há timeouts alterados e uma réplica fora de serviço. O RUN precisa desse estado real para manter operação e remover exceções com segurança.
O ConfigMap mostra timeout=10, mas o processo continua com 30. A aceitação exige observar configuração efetiva e resultado, além do objeto alterado na API.
Armadilhas comuns
Objeto alterado como configuração adotada; readiness como restart; grace duplicado; ficheiro de certificado como endpoint validado.
Tópicos relacionados: Operar TLS, certificados e configuração · Gerir filas, confirmações e repetição · Lançar, observar e recuperar middleware
Distingue entrega, adoção e aceitação, mantendo critérios para os estados intermédios da mudança.
Referência: ConfigMaps · DR Middleware 2026.4; HotSpot JDK 25; JDBC 25; PostgreSQL 18; RabbitMQ 4.3; OpenSSL 3.5; explicitly scoped runtime references