Configurar sondas e verificações de integridade do balanceador de carga - AWS Orientação prescritiva

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

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 HTTP/TCP para o kubelet ou o 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 livenss não estiverem corretas, a sonda livenss poderá encerrar o pod.

Sonda de inicialização

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

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.

Sonda de prontidão

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

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.

Observação: para o Kubernetesingress, 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.

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.

Para obter mais informações, consulte Melhores práticas do EKS — balanceamento de carga (disponibilidade e ciclo de vida do pod).