Sondas do Kubernetes: quando esperar, encaminhar tráfego ou reiniciar

Um processo de API hipotético está em execução, mas a inicialização ainda não terminou. Mais tarde, a sua base de dados fica indisponível. Noutro dia, um bloqueio mútuo local impede a conclusão dos pedidos. Cada uma destas situações pode causar uma falha numa verificação de saúde. Não devem provocar automaticamente a mesma resposta.

Decida o que ajudaria. Dar mais tempo para a inicialização? Retirar esta instância do tráfego? Reiniciar o seu contentor? O Kubernetes atribui uma semântica de sondas diferente a cada uma destas opções, como explica a documentação oficial sobre sondas.

Um bom desenho de sondas começa por uma justificação da recuperação. Este guia aborda uma aplicação HTTP convencional num Deployment, atrás de um Service normal. O acesso direto a Pods, os processos de trabalho, as configurações especializadas de Service e o encaminhamento personalizado precisam de uma análise separada. A configuração é ilustrativa e não foi executada.

Prontidão, vitalidade e inicialização no Kubernetes: três decisões diferentes

A sonda determina o que o Kubernetes faz com o sinal do endpoint. Consulte o comportamento das sondas do Kubernetes antes de escolher a verificação.

A sonda de inicialização protege a inicialização

Uma sonda de inicialização suspende as verificações de vitalidade e prontidão até ter sucesso. Assim, a inicialização tem a sua própria margem de tempo sem enfraquecer as verificações contínuas. Continua a existir um limite: falhas repetidas na inicialização terminam o contentor. As orientações de configuração da inicialização descrevem esta espera limitada.

A prontidão controla a elegibilidade para receber tráfego

Uma falha de prontidão não reinicia nada por si só. Altera a prontidão e a elegibilidade para receber tráfego dos Services correspondentes. A prontidão do Pod também exige que os outros contentores e quaisquer condições adicionais de prontidão configuradas estejam satisfeitos, como explica a documentação sobre o ciclo de vida dos Pods. O trabalho em segundo plano não para só porque a instância deixa de estar pronta, e uma verificação falhada não prova que todas as rotas estejam inutilizáveis. Consulte a documentação sobre sondas para conhecer a consequência para o Service; o encerramento precisa de um contrato separado.

A vitalidade pergunta se reiniciar pode ajudar

Ao atingir o limiar de falha, a sonda de vitalidade desencadeia a terminação do contentor específico, sem substituir o Pod inteiro. A política de reinício determina o que acontece a seguir, incluindo a espera progressiva descrita na documentação sobre o ciclo de vida dos Pods. Um processo em execução pode estar bloqueado. Um processo à espera de um serviço externo indisponível pode não ter nenhum problema local.

O modelo Esperar, Encaminhar, Reiniciar para decisões sobre sondas

Esperar, Encaminhar, Reiniciar é uma ferramenta de apoio à decisão editorial original da Optijara, não uma funcionalidade do Kubernetes, uma norma da indústria ou um método verificado com clientes. Utilize-a para avaliar a justificação da recuperação antes de implementar uma verificação de saúde.

Associe a falha a uma ação

Todos os cenários abaixo são hipotéticos. Teste as condições de aceitação na carga de trabalho real.

As dependências partilhadas complicam a decisão de encaminhamento. Se todas as réplicas verificarem o mesmo serviço de retaguarda indisponível, retirar uma instância pode acabar por retirar todas. A análise prática de Colin Breck examina este problema do domínio de falha. Reiniciar as réplicas não pode, por si só, reparar a dependência que partilham.

Registe a evidência e a responsabilidade pela recuperação

Registe junto da configuração o que continua útil, o que o reinício alteraria e quem é responsável pela recuperação. Este JSON é um registo de planeamento, não uma política executável.

{
  "framework": "wait-route-restart",
  "wait": "bounded-initialization-allowance",
  "route": "scoped-request-usefulness",
  "restart": "tested-local-recovery-mechanism",
  "acceptance": "observed-state-and-real-requests"
}

Omitir a sonda de vitalidade pode ser razoável quando não existe um sinal de reinício justificado. O Kubernetes documenta essa opção. A objeção merece igual atenção: retirar uma instância por falta de prontidão pode, por si só, deixar uma instância bloqueada indisponível indefinidamente. A análise de Breck mostra por que razão esse desenho continua a precisar de alguém ou de algum mecanismo responsável por restabelecer o progresso.

Verificações de dependências na prontidão sem retirar capacidade útil

Separe as dependências essenciais das funcionalidades opcionais

As orientações oficiais permitem verificações de prontidão para dependências estritamente necessárias de serviços de retaguarda. Henning Jacobs alerta para as verificações de dependências partilhadas, enquanto Breck examina pedidos com dependências diferentes. Pergunte o que se consegue ao retirar a instância.

Considere uma API hipotética que precisa da sua base de dados para todos os pedidos autorizados. Marcar a instância como não pronta pode descrever corretamente a sua capacidade. Noutra API hipotética, as rotas de leitura funcionam apesar de uma falha na telemetria. Retirar a instância descartaria capacidade útil. O funcionamento degradado tem de continuar a respeitar a autorização e os outros requisitos de segurança.

Quando as rotas dependem de serviços diferentes, considere o tratamento de falhas por rota ou cargas de trabalho separadas com contratos de prontidão distintos. A fronteira de falha tem de justificar os custos adicionais de implantação e manutenção.

Limite as verificações e preserve o funcionamento degradado

Defina limites de tempo para as verificações de dependências e especifique o que acontece quando o tempo limite é excedido. O estado de saúde em cache precisa de uma idade máxima e de uma regra para resultados desconhecidos ou desatualizados. Uma verificação bem-sucedida ontem não é evidência de que o serviço pode aceitar pedidos agora.

A prontidão pode oscilar. O Kubernetes oferece limiares de sucessos e falhas consecutivos, cuja semântica está descrita no guia de configuração. Escolha esses limiares com base no comportamento observado. Qualquer suavização adicional no código da aplicação também precisa de testes.

Mantenha as falhas de dependências fora da verificação de vitalidade, a menos que os testes expliquem como um reinício local as repara. Os artigos dos profissionais incluem exemplos históricos de controladores; valide o percurso de entrada instalado em vez de presumir que esses exemplos descrevem o seu comportamento atual.

Uma configuração ilustrativa de sondas HTTP e um contrato de endpoints

Atribua significados separados à inicialização, à prontidão e à vitalidade

Este fragmento pertence à especificação de um contentor. Não é um Deployment completo e executável. Pressupõe uma aplicação à escuta na porta 8080 com os endpoints apresentados. Os valores de tempo são exemplos sem avaliação de desempenho, não recomendações de ajuste.

ports:
  - name: http
    containerPort: 8080
startupProbe:
  httpGet:
    path: /startupz
    port: http
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 24
  successThreshold: 1
readinessProbe:
  httpGet:
    path: /readyz
    port: http
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 3
  successThreshold: 2
livenessProbe:
  httpGet:
    path: /livez
    port: http
  periodSeconds: 10
  timeoutSeconds: 2
  failureThreshold: 3
  successThreshold: 1

Segundo este contrato proposto, /startupz comunica a conclusão da inicialização. /readyz comunica se a instância deve receber o tráfego abrangido pelo seu contrato. /livez deteta uma condição local que o reinício pode resolver. Os caminhos separados tornam este exemplo mais fácil de rever; o Kubernetes não exige URLs separados.

As sondas HTTP verificam o estado da resposta, não o sucesso de uma operação de negócio. O guia oficial de configuração define os códigos de estado de sucesso como 200 a 399. O tratamento de redirecionamentos tem exceções que merecem análise: o kubelet segue redirecionamentos para o mesmo anfitrião, mas um redirecionamento para um anfitrião diferente ou 11 ou mais redirecionamentos são tratados como sucesso com um evento ProbeWarning. Prefira uma resposta explícita de saúde a um redirecionamento para uma página de início de sessão. Mantenha os corpos das respostas pequenos e exclua segredos ou detalhes sensíveis sobre dependências.

Escolha os tempos com base em evidência da carga de trabalho

periodSeconds define a frequência das sondas. timeoutSeconds limita a duração de uma sonda individual. failureThreshold conta as falhas consecutivas, enquanto successThreshold conta os sucessos consecutivos após uma falha. Este último tem de ser 1 para as sondas de inicialização e vitalidade. A verificação de prontidão pode ser executada com maior frequência enquanto o contentor não estiver pronto. Estas são semânticas documentadas dos campos, não uma receita de ajuste.

Meça a inicialização nas condições de arranque que pretende suportar, incluindo arranques a frio relevantes. Reveja também o período de tolerância para a terminação. O kubelet respeita o período aplicável durante a terminação desencadeada por uma sonda; o período de tolerância definido ao nível da sonda está disponível para inicialização e vitalidade, mas não para prontidão. Consulte a documentação sobre sondas.

Multiplicar limiares não produz um prazo exato de recuperação. O agendamento, os tempos limite, o encerramento, a espera progressiva entre reinícios e a inicialização também afetam o tempo decorrido. Um guia executável precisaria de um ambiente de teste completo com versões fixadas e resultados de execução guardados. Este fragmento não foi executado num cluster.

Um guia para pré-produção: testar falhas, analisar a evidência e depois implementar

Registe a situação de referência e teste uma falha de cada vez

Estes são testes propostos, não resultados experimentais. Antes do primeiro teste:

1. Faça um inventário do comportamento dos endpoints, das predefinições de saúde do framework e dos pressupostos de encaminhamento.
2. Guarde a configuração atual das sondas e a evidência de referência dos pedidos, da prontidão e dos reinícios.
3. Atribua uma ação esperada e um responsável pela recuperação a cada falha.
4. Provoque uma falha de cada vez numa carga de trabalho isolada em pré-produção.
5. Compare as observações com o contrato antes de aprovar uma implementação de alcance limitado.
6. Guarde a configuração da aplicação revista e o procedimento de reversão da implantação.

Utilize uma aplicação descartável para bloqueios deliberados. Não introduza bloqueios mútuos em serviços de produção partilhados.

Verifique tanto o estado do Kubernetes como os pedidos reais

Leia as condições do Pod e as contagens de reinícios dos contentores. Analise os eventos e os registos do contentor anterior, quando disponíveis, e depois relacione a prontidão dos EndpointSlices dos Services correspondentes com os pedidos através do Service ou do percurso de entrada pretendido. A documentação sobre sondas e a documentação sobre o ciclo de vida explicam as transições de estado. Uma configuração aceite, por si só, demonstra pouco sobre a recuperação.

As alterações nos EndpointSlices chegam aos mecanismos de observação e às caches dos clientes em momentos diferentes, como explica a documentação oficial sobre EndpointSlice. Esta também documenta uma exceção: publishNotReadyAddresses faz com que ready do endpoint seja verdadeiro independentemente da prontidão do Pod. Este guia pressupõe que essa opção está desativada. Teste o percurso de encaminhamento instalado e os pedidos de longa duração; não presuma que todos os controladores param imediatamente novos encaminhamentos ou que uma falha de prontidão fecha ligações já estabelecidas.

Para serviços de inferência, compare a evidência das sondas com a observabilidade da inferência de IA. Um processo saudável não comprova a latência das respostas, o sucesso dos pedidos ou a qualidade dos resultados. O guia de rastreamento GenAI com OpenTelemetry acrescenta contexto para chamadas a modelos e ferramentas. Complementa os testes das sondas.

Meça a recuperação, não apenas indicadores verdes.

Defina a recuperação e a reversão antes da produção

Rejeite a alteração se forem retiradas réplicas não relacionadas, se os reinícios aumentarem sem recuperação, se as rotas úteis falharem ou se a recuperação continuar sem explicação. Defina critérios de aceitação para a carga de trabalho em vez de adotar limiares universais de latência ou disponibilidade.

A reversão tem de restabelecer o contrato de endpoints revisto e a configuração das sondas através do processo normal de implantação. Verifique depois a prontidão, o comportamento dos reinícios e os pedidos reais. Um comando de implantação bem-sucedido não comprova a recuperação.

Os erros das equipas e o que as sondas não podem garantir

Evite sinais de falha partilhados e reinícios injustificados

As verificações idênticas merecem análise quando as consequências das suas falhas são diferentes. Outros erros incluem verificar um serviço à escuta numa porta de gestão que revela pouco sobre o percurso de atendimento dos pedidos, ou definir limiares agressivos sem medir a inicialização. Jacobs aborda os pontos cegos das portas de gestão e os riscos dos reinícios.

Insistir em URLs diferentes também não é melhor como regra absoluta. O Kubernetes descreve configurações com um endpoint partilhado e limiares diferentes. Avalie o sinal e a sua consequência. O nome do endpoint não permite decidir se um reinício vai ajudar.

Trate as interrupções, o encerramento e o trabalho durável separadamente

Um PodDisruptionBudget limita as operações suportadas de remoção voluntária. Não coordena os reinícios de contentores desencadeados por sondas de vitalidade nem garante um nível mínimo de disponibilidade. A documentação oficial sobre interrupções define o seu âmbito. A discussão histórica da comunidade ajuda a explicar a confusão; não é uma especificação atual.

Retirar uma instância por falta de prontidão não proporciona terminação graciosa, escoamento de ligações ou encerramento dos processos de trabalho. A documentação sobre o ciclo de vida dos Pods trata a terminação separadamente. Essas responsabilidades precisam de desenhos e testes explícitos.

Reiniciar um contentor também não estabelece um estado de referência fiável das tarefas nem elimina escritas externas duplicadas. Para cargas de trabalho de agentes, analise o estado durável dos fluxos de trabalho e a recuperação em conjunto com a saúde dos contentores.

As sondas observam os sinais que escolheu. Não podem comprovar a correção completa da aplicação, a segurança ou a qualidade da inferência. Os mecanismos de resposta às verificações de saúde também consomem recursos, e o estado em cache pode ficar desatualizado. O guia operacional deve explicar estes limites e como reconhecer a recuperação.