As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Configurar sondas e verificações de integridade do balanceador de carga
<a name="probes-checks"></a>

O Kubernetes fornece várias maneiras de realizar verificações de integridade do aplicativo, além das verificações de integridade do balanceador de carga. Você pode executar os seguintes testes integrados do Kubernetes junto com a verificação de integridade do balanceador de carga como um comando no contexto do pod ou como um teste para o kubelet ou o HTTP/TCP endereço IP do host.

As sondas de vivacidade e prontidão devem ser diferentes e independentes (ou, pelo menos, com valores de tempo limite diferentes). Se um aplicativo tiver um problema temporário, a sondagem de prontidão marcará o pod como não pronto até que o problema seja resolvido. Se as configurações da sonda de atividade não estiverem corretas, a sonda de atividade poderá encerrar a cápsula.

## Sonda de inicialização
<a name="startup-probe"></a>

Use sondas de inicialização para proteger aplicativos com ciclos de inicialização longos. Até que a sondagem de inicialização seja bem-sucedida, as outras sondas serão desativadas.

Você pode definir o tempo máximo que o Kubernetes deve esperar pela inicialização do aplicativo. Se, após o tempo máximo configurado, o pod ainda falhar nos testes de inicialização, o aplicativo será encerrado e um novo pod será criado.

Use sondas de inicialização quando o tempo de inicialização de um aplicativo for imprevisível. Se você sabe que seu aplicativo precisa de 10 segundos para ser iniciado, use uma sonda de vivacidade ou uma sonda de prontidão. `initialDelaySeconds`

## Sonda de vivacidade
<a name="liveness-probe"></a>

Use sondas de atividade para detectar problemas no aplicativo ou se o processo está sendo executado sem problemas. Uma sonda de atividade pode detectar condições de impasse em que o processo continua em execução, mas o aplicativo deixa de responder. Ao usar uma sonda de vivacidade, faça o seguinte:
+ Use `initialDelaySeconds` para atrasar a primeira sonda.
+ Não defina a mesma especificação para sondas de vivacidade e prontidão.
+ Não configure uma sonda de atividade para depender de um fator externo ao seu pod (por exemplo, um banco de dados).
+ Defina a sonda de vivacidade para um específico. `terminationGracePeriodSeconds` Para obter mais informações, consulte [a documentação do Kubernetes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).

## Sonda de prontidão
<a name="readiness-probe"></a>

Use uma sonda de prontidão para detectar o seguinte:
+ Se o aplicativo está pronto para aceitar tráfego
+ Disponibilidade parcial, em que o aplicativo pode estar temporariamente indisponível, mas espera-se que volte a funcionar após a conclusão de uma determinada operação

Os testes de prontidão ajudam a garantir que a configuração e as dependências do aplicativo sejam executadas sem problemas ou erros, para que o aplicativo possa atender ao tráfego. No entanto, uma sonda de prontidão mal configurada pode causar uma interrupção em vez de evitá-la. Sondas de prontidão que dependem de fatores externos, como conectividade com um banco de dados, podem fazer com que todos os pods falhem na sondagem. Essas falhas podem resultar em uma interrupção e levar a uma falha em cascata de um serviço de back-end para outros serviços que usaram os pods com falha.

## Verificações de integridade do recurso de entrada e do balanceador de carga
<a name="health-checks"></a>

O Application Load Balancer e o Kubernetes `ingress` fornecem recursos de verificação de integridade. Para as verificações de integridade do Application Load Balancer, especifique as portas e o caminho de destino.

**nota**  
Para o Kubernetes`ingress`, haverá uma latência de cancelamento de registro. O padrão para o Application Load Balancer é 300 segundos. Considere configurar seu recurso de entrada ou a verificação de integridade do balanceador de carga usando os mesmos valores que você usou para sua análise de prontidão.

O NGINX também fornece uma verificação de integridade. Para obter mais informações, consulte a documentação do [NGINX](https://nginx.org/en/docs/http/load_balancing.html#nginx_load_balancing_health_checks).

Os gateways de entrada e saída do Istio não têm um mecanismo de verificação de integridade comparável à verificação de integridade HTTP do NGINX. No entanto, você pode obter uma funcionalidade semelhante usando o [disjuntor ou a detecção de `DestinationRule` valores discrepantes do Istio](https://istio.io/latest/docs/tasks/traffic-management/circuit-breaking/).

Para obter mais informações, consulte [Disponibilidade e ciclo de vida do pod](https://docs.aws.amazon.com/eks/latest/best-practices/load-balancing.html#_availability_and_pod_lifecycle) no Guia de *melhores práticas do Amazon EKS*.