Como soluciono problemas de alvos não íntegros para Network Load Balancers no Amazon EKS?

Breve descrição

A seguir estão os motivos comuns pelos quais os alvos do seu Network Load Balancer não estão íntegros:

• A verificação de integridade está configurada incorretamente.
• Há uma exceção inesperada do pod.
• Um Network Load Balancer com a externalTrafficPolicy definida como local com um DNS Amazon VPC personalizado no conjunto de opções de DHCP.

Resolução

Verifique se o grupo-alvo é um endereço IP ou uma instância

Execute o seguinte comando:

kubectl get service service_name -o yaml

Observação: substitua service_name pelo nome do seu serviço.

Se a anotação service.beta.kubernetes.io/aws-load-balancer-nlb-target-type não estiver presente, o tipo de destino padrão será uma instância.

Verifique se a verificação de integridade está configurada corretamente

Verifique quais anotações do Elastic Load Balancing (ELB) estão configuradas para seu serviço. Para obter mais informações sobre anotações, consulte Serviço no site do Kubernetes.

Execute o comando a seguir para obter uma lista de anotações:

kubectl get service service_name -o yaml

Exemplo de saída:

service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold: "2"# The number of successive successful health checks required for a backend to be considered healthy for traffic. Defaults to 2, must be between 2 and 10

service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold: "3"
# The number of unsuccessful health checks required for a backend to be considered unhealthy for traffic. Defaults to 6, must be between 2 and 10

service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "20"
# The approximate interval, in seconds, between health checks of an individual instance. Defaults to 10, must be between 5 and 300

service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: "5"
# The amount of time, in seconds, during which no response means a failed health check. This value must be less than the service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval value. Defaults to 5, must be between 2 and 60

service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol: TCP
service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: traffic-port
# can be integer or traffic-port

service.beta.kubernetes.io/aws-load-balancer-healthcheck-path: "/"
# health check path for HTTP(S) protocols

Se as anotações estiverem configuradas incorretamente, os alvos podem não estar íntegros.

Inicie manualmente a verificação de integridade a partir de uma máquina host que é executada no Amazon VPC

Para tipos de destino de instância, execute o seguinte comando curl com NodePort:

curl-ivk node_IP:NodePort

Observação: substitua node_IP pelo endereço IP do seu nó.

Para tipos de destino de endereço IP, execute o seguinte comando curl:

curl -ivk pod_IP:pod_port

Observação: substitua pod_IP pelo endereço IP do seu pod. Substitua pod_port pelo nome da porta na qual o aplicativo escuta dentro do contêiner.

Verifique se há uma exceção inesperada no pod

Tipo de destino da instância

1. Verifique a especificação do serviço para ver as anotações atuais da configuração da verificação de integridade. Para obter uma lista completa, consulte as anotações de configuração da verificação de integridade no site do GitHub:

   kubectl get service service_name -o yaml

2. Verifique se há endpoints para verificar se há pods por trás do serviço:

   kubectl get endpoints service_name -o yaml

3. Se não houver endpoints para o serviço, verifique se os rótulos do pod e os rótulos do serviço coincidem:

   kubectl describe servicekubectl describe pod pod_name or kubectl get pod --show-labels

   Observação: Substitua pod_name pelo nome do seu pod.

4. Verifique se os pods estão no status Em execução:

   kubectl get pod -o wide

5. Analise o status dos pods para verificar se eles podem ser executados sem nenhuma reinicialização:

   kubectl get pods -o wide

6. Se houver reinicializações, colete os registros do pod para determinar a causa:

   kubectl logs pod_namekubectl logs pod_name --previous

7. Faça login em uma máquina host na Amazon VPC onde você pode se comunicar com o nó. Em seguida, use o comando curl com o NodePort para verificar se os pods retornam o código de status HTTP esperado:

   curl node_IP:NodePort

   Se o comando curl não retornou o código de status HTTP esperado, os pods de backend não retornarão o código de status HTTP esperado.

8. Use a mesma máquina host para se conectar ao endereço IP do pod e verificar se o pod está configurado corretamente:

   curl pod_IP:pod_port

   Se o comando curl não retornou o código de status HTTP esperado, o pod não está configurado corretamente.

Observação: se a externalTrafficPolicy (do site do Kubernetes) do serviço estiver definida como Local, somente os nós em que os pods de backend do serviço estão em execução serão vistos como alvos íntegros.

Tipo de destino de endereço IP

1. Verifique a especificação do serviço para ver as anotações atuais da configuração da verificação de integridade. Para obter uma lista, consulte as anotações de configuração da verificação de integridade no site do GitHub.

   kubectl get service service_name -o yaml

2. Faça login em uma máquina host na Amazon VPC e use o comando curl para se comunicar com o endereço IP do pod:

   curl pod_IP:pod_port

   Se o comando curl não retornou o código de status HTTP esperado, o pod não está configurado corretamente.