Como soluciono os erros HTTP 503 (serviço indisponível) quando acesso um serviço Kubernetes em um cluster do Amazon EKS?

4 minuto de leitura
0

Recebo erros HTTP 503 (serviço indisponível) quando me conecto a um serviço Kubernetes executado no cluster do Amazon Elastic Kubernetes Service (Amazon EKS).

Breve descrição

Os erros HTTP 503 são erros no lado do servidor. Eles ocorrem ao se conectar a um pod do Kubernetes Service localizado em um cluster do Amazon EKS configurado para um balanceador de carga.

Para solucionar problemas de erros HTTP 504, consulte Como resolvo erros HTTP 504 no Amazon EKS?

Para solucionar erros HTTP 503, conclua as seguintes etapas de solução de problemas.

Resolução

Verifique se o rótulo do pod corresponde ao valor especificado no seletor de serviços do Kubernetes

1.    Execute o seguinte comando para obter o valor do seletor:

$ kubectl describe service service_name -n your_namespace

Observação: substituaservice_name pelo nome do serviço e your_namespace pelo namespace de serviço.

Saída de exemplo:

Name:                     service-name
Namespace:                pod-name
Labels:                   none
Annotations:              none
Selector:                 app.kubernetes.io/name=namespace
Type:                     NodePort
IP Families:              none
IP:                       10.100.17.189
IPs:                      10.100.17.189
Port:                     unset  80/TCP
TargetPort:               80/TCP
NodePort:                 unset  31560/TCP
Endpoints:                none
Session Affinity:         none
External Traffic Policy:  Cluster
Events:                   none

Na saída anterior, o valor do seletor de exemplo é app.kubernetes.io/name=namespace.

2.    Verifique se há pods com o rótulo app.kubernetes.io/name=namespace:

$ kubectl get pods -n your_namespace -l "app.kubernetes.io/name=namespace"

Saída de exemplo:

No resources found in your_namespace namespace.

Se nenhum recurso for encontrado com o valor que você pesquisou, você receberá um erro HTTP 503.

Verifique se os pods definidos para o Kubernetes Service estão sendo executados

Use o rótulo no seletor do Kubernetes Service para verificar se os pods existem e estão no estado Em execução:

$ kubectl -n your_namespace get pods -l "app.kubernetes.io/name=your_namespace"

Resultado:

NAME                               READY   STATUS             RESTARTS   AGE
POD_NAME                           0/1     ImagePullBackOff   0          3m54s

Verifique se os pods podem passar no readiness probe para a implantação do Kubernetes

1.    Verifique se os pods de aplicações podem passar no readiness probe. Para obter mais informações, consulte Configurar liveness, readiness e startup probes (no site do Kubernetes).

2.    Verifique o readiness probe para o pod:

$ kubectl describe pod pod_name -n your_namespace | grep -i readiness

Observação: substitua o pod_name pelo nome do seu pad e o your_namespace pelo seu namespace.

Saída de exemplo:

Readiness:      tcp-socket :8080 delay=5s timeout=1s period=2s #success=1 #failure=3
Warning  Unhealthy  2m13s (x298 over 12m)  kubelet            Readiness probe failed:

Na saída anterior, você pode ver Readiness probe failed (Falha na sondagem de prontidão).

Observação: esta etapa só fornece uma saída útil se a aplicação estiver sendo escutada no caminho e na porta corretos. Verifique a saída do curl com o comando curl -Ivk e verifique se o caminho definido no nível de serviço está recebendo uma resposta válida. Por exemplo, 200 ms é uma boa resposta.

Verifique a capacidade do Classic Load Balancer

Se você receber um erro HTTP 503 intermitente, o balanceador de carga clássico não terá capacidade suficiente para lidar com a solicitação. Para resolver esse problema, verifique se o balanceador de carga clássico tem capacidade suficiente e se os nós de processamento podem lidar com a taxa de solicitação.

Verifique se suas instâncias estão registradas

Você também receberá um erro HTTP 503 se não houver instâncias registradas. Para resolver esse problema, tente as seguintes soluções:

  • Verifique se os grupos de segurança do nó de processamento têm uma regra de entrada que permite o acesso à porta na porta do nó para os nós de processamento. Além disso, verifique se nenhuma regra de NAT está bloqueando o tráfego de rede nos intervalos de portabilidade do nó.
  • Verifique se o grupo de segurança personalizado especificado para o balanceador de carga clássico tem permissão para acesso de entrada nos nós de processamento.
  • Verifique se há nós de processamento em todas as zonas de disponibilidade especificadas pelas sub-redes.

Informações relacionadas

Por que recebo um erro HTTP 5xx ao me conectar com servidores Web executados em instâncias do EC2 configuradas para usar o Classic Load Balancer?

HTTP 503: serviço indisponível

Monitore seu balanceador de carga clássico

Monitore seus balanceadores de carga de aplicação

Solução de problemas de um balanceador de carga clássico: erros HTTP

AWS OFICIAL
AWS OFICIALAtualizada há 2 anos