Como resolvo uma falha na verificação de integridade de um balanceador de carga no Amazon EKS?

9 minuto de leitura
0

Meu balanceador de carga continua falhando na verificação de integridade no meu Amazon Elastic Kubernetes Service (Amazon EKS).

Breve descrição

Para solucionar problemas de verificação de integridade com o balanceador de carga no Amazon EKS, conclua as etapas nas seções a seguir:

  • Verifique o status do pod
  • Verifique o pod e os seletores de etiqueta de serviço
  • Verifique se há endpoints ausentes
  • Verifique a política de tráfego de serviço e os grupos de segurança de cluster para Application Load Balancers
  • Verifique se o EKS está configurado para targetPort
  • Verifique se o AWS Load Balancer Controller tem as permissões corretas
  • Verifique as anotações de entrada quanto a problemas com os Application Load Balancers
  • Verifique as anotações do Kubernetes Service quanto a problemas com Network Load Balancers
  • Teste manualmente uma verificação de integridade
  • Verifique as redes
  • Reinicie o kube-proxy

Resolução

Verifique o status do pod

Verifique se o pod está no status Em execução e se os contêineres nos pods estão prontos:

$ kubectl get pod -n YOUR_NAMESPACE

Observação: substitua YOUR_NAMESPACE pelo seu namespace do Kubernetes.

Saída de exemplo:

NAME                           READY   STATUS    RESTARTS   AGE
podname                        1/1     Running   0          16s

Observação: se o contêiner da aplicação no pod não estiver em execução, a verificação de integridade do balanceador de carga não será respondida e falhará.

Verifique o pod e os seletores de etiqueta de serviço

Para etiquetas de pod, execute o seguinte comando:

$ kubectl get pod -n YOUR_NAMESPACE --show-labels

Saída de exemplo:

NAME                           READY   STATUS    RESTARTS   AGE     LABELS
alb-instance-6cc5cd9b9-prnxw   1/1     Running   0          2d19h   app=alb-instance,pod-template-hash=6cc5cd9b9

Para verificar se o Kubernetes Services está usando as etiquetas do pod, execute o seguinte comando para verificar se a saída corresponde às etiquetas do pod:

$ kubectl get svc SERVICE_NAME -n YOUR_NAMESPACE -o=jsonpath='{.spec.selector}{"\n"}'

Observação: substitua SERVICE_NAME pelo seu Kubernetes Service e YOUR_NAMESPACE pelo namespace do Kubernetes.

Saída de exemplo:

{"app":"alb-instance"}

Verifique se há endpoints ausentes

O controlador Kubernetes para o seletor de serviço verifica continuamente os pods que correspondem ao seletor e, em seguida, publica atualizações em um objeto de endpoint. Se você selecionou uma etiqueta incorreta, nenhum endpoint será exibido.

Execute o seguinte comando:

$ kubectl describe svc SERVICE_NAME -n YOUR_NAMESPACE

Saída de exemplo:

Name:                     alb-instance
Namespace:                default
Labels:                   <none>
Annotations:              <none>
Selector:                 app=alb-instance-1      
Type:                     NodePort
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.100.44.151
IPs:                      10.100.44.151
Port:                     http  80/TCP
TargetPort:               80/TCP
NodePort:                 http  32663/TCP
Endpoints:                <none>                 
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

Verifique se o endpoint está ausente:

$ kubectl get endpoints SERVICE_NAME -n YOUR_NAMESPACE

Saída de exemplo:

NAME           ENDPOINTS                                AGE
alb-instance   <none>                                   2d20h

Verifique a política de tráfego de serviço e os grupos de segurança de cluster quanto a problemas com os Application Load Balancers

Os destinos não íntegros nos grupos de destino do Application Load Balancer acontecem por dois motivos. A política de tráfego de serviço,spec.externalTrafficPolicy, está definida como Local em vez de Cluster. Ou os grupos de nós em um cluster têm grupos de segurança de cluster diferentes associados a eles, e o tráfego não pode fluir livremente entre os grupos de nós.

Verifique se a política de tráfego está configurada corretamente:

$ kubectl get svc SERVICE_NAME -n YOUR_NAMESPACE -o=jsonpath='{.spec.externalTrafficPolicy}{"\n"}'

Saída de exemplo:

Local

Altere a configuração para Cluster:

$ kubectl edit svc SERVICE_NAME -n YOUR_NAMESPACE

Verifique os grupos de segurança do cluster

1.    Ouvrez la console Amazon EC2.

2.    Selecione a instância íntegra.

3.    Escolha a guia Security (Segurança) e verifique as regras de entrada do grupo de segurança.

4.    Selecione a instância não íntegra.

5.    Escolha a guia Security (Segurança) e verifique as regras de entrada do grupo de segurança.

Se o grupo de segurança para cada instância for diferente, você deverá modificar a regra de entrada de segurança no console do grupo de segurança:

1.    Na guia Security (Segurança), selecione o ID do grupo de segurança.

2.    Escolha o botão Edit inbound rules (Editar regras de entrada) para modificar as regras de entrada.

3.    Adicione regras de entrada para permitir o tráfego de outros grupos de nós no cluster.

Verifique se o serviço está configurado para targetPort

Seu targetPort deve corresponder ao containerPort no pod para o qual o serviço está enviando tráfego.

Para verificar para se o targetPort está configurado, execute o seguinte comando:

$ kubectl get svc  SERVICE_NAME -n YOUR_NAMESPACE -o=jsonpath="{.items[*]}{.metadata.name}{'\t'}{.spec.ports[].targetPort}{'\t'}{.spec.ports[].protocol}{'\n'}"

Saída de exemplo:

alb-instance 8080 TCP

Na saída do exemplo anterior, o targetPort está configurado para 8080. No entanto, como o containerPort está definido como 80, você deve configurar o targetPort como 80.

Verifique se o AWS Load Balancer Controller tem as permissões corretas

O AWS Load Balancer Controller deve ter as permissões corretas para atualizar grupos de segurança para permitir o tráfego do balanceador de carga para instâncias ou pods. Se o controlador não tiver as permissões corretas, você receberá erros.

Verifique se há erros nos logs de implantação do AWS Load Balancer Controller:

$ kubectl logs deploy/aws-load-balancer-controller -n kube-system

Verifique se há erros nos logs individuais do pod do controlador:

$ kubectl logs CONTROLLER_POD_NAME -n YOUR_NAMESPACE

Observação: substitua CONTROLLER_POD_NAME pelo nome do pod do controlador e YOUR_NAMESPACE pelo namespace do Kubernetes.

Verifique as anotações de entrada quanto a problemas com os Application Load Balancers

Para problemas com o Application Load Balancer, verifique as anotações de entrada do Kubernetes:

$ kubectl describe ing INGRESS_NAME -n YOUR_NAMESPACE

Observação: substitua INGRESS_NAME pelo nome de sua entrada do Kubernetes e YOUR_NAMESPACE pelo namespace do Kubernetes.

Saída de exemplo:

Name:             alb-instance-ingress
Namespace:        default
Address:          k8s-default-albinsta-fcb010af73-2014729787.ap-southeast-2.elb.amazonaws.com
Default backend:  alb-instance:80 (192.168.81.137:8080)
Rules:
  Host          Path  Backends
  ----          ----  --------
  awssite.cyou
                /   alb-instance:80 (192.168.81.137:8080)
Annotations:    alb.ingress.kubernetes.io/scheme: internet-facing        
                kubernetes.io/ingress.class: alb                         
Events:
  Type    Reason                  Age                  From     Message
  ----    ------                  ----                 ----     -------
  Normal  SuccessfullyReconciled  25m (x7 over 2d21h)  ingress  Successfully reconciled

Para encontrar anotações de entrada específicas para seu caso de uso, consulte Anotações de entrada (no site do Kubernetes).

Verifique as anotações do Kubernetes Service quanto a problemas com Network Load Balancers

Para problemas com o Network Load Balancer, verifique as anotações do Kubernetes Service:

$ kubectl describe svc SERVICE_NAME -n YOUR_NAMESPACE

Saída de exemplo:

Name:                     nlb-ip
Namespace:                default
Labels:                   <none>
Annotations:              service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip              
                          service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing          
                          service.beta.kubernetes.io/aws-load-balancer-type: external                   
Selector:                 app=nlb-ip
Type:                     LoadBalancer
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.100.161.91
IPs:                      10.100.161.91
LoadBalancer Ingress:     k8s-default-nlbip-fff2442e46-ae4f8cf4a182dc4d.elb.ap-southeast-2.amazonaws.com
Port:                     http  80/TCP
TargetPort:               80/TCP
NodePort:                 http  31806/TCP
Endpoints:                192.168.93.144:80
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

Observação: anote oAPPLICATION_POD_IP. Você precisará dele para executar um comando de verificação de integridade.

Para encontrar anotações do Kubernetes Service específicas para seu caso de uso, consulte Anotações de serviço (no site do Kubernetes).

Teste manualmente uma verificação de integridade

Verifique o endereço IP do pod da aplicação:

$ kubectl get pod -n YOUR_NAMESPACE -o wide

Execute um pod de teste para testar manualmente uma verificação de integridade dentro do cluster para verificações de integridade HTTP:

$ kubectl run -n YOUR_NAMESPACE troubleshoot -it --rm --image=amazonlinux -- /bin/bash

Para verificações de integridade HTTP:

# curl -Iv APPLICATION_POD_IP/HEALTH_CHECK_PATH

Observação: substitua APPLICATION_POD_IP pelo IP do pod da aplicação e HEALTH_CHECK_PATH pelo caminho de verificação de integridade do grupo de destino do ALB.

Exemplo de comando:

# curl -Iv 192.168.81.137

Saída de exemplo:

* Trying 192.168.81.137:80...
* Connected to 192.168.81.137 (192.168.81.137) port 80 (#0)
> HEAD / HTTP/1.1
> Host: 192.168.81.137
> User-Agent: curl/7.78.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Server: nginx/1.21.3
Server: nginx/1.21.3
< Date: Tue, 26 Oct 2021 05:10:17 GMT
Date: Tue, 26 Oct 2021 05:10:17 GMT
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 615
Content-Length: 615
< Last-Modified: Tue, 07 Sep 2021 15:21:03 GMT
Last-Modified: Tue, 07 Sep 2021 15:21:03 GMT
< Connection: keep-alive
Connection: keep-alive
< ETag: "6137835f-267"
ETag: "6137835f-267"
< Accept-Ranges: bytes
Accept-Ranges: bytes

< 
* Connection #0 to host 192.168.81.137 left intact

Verifique o código de status da resposta HTTP. Se o código de status da resposta for 200 OK, significa que sua aplicação está respondendo corretamente no caminho da verificação de integridade.

Se o código de status da resposta HTTP for 3xx ou 4xx, você poderá alterar o caminho da verificação de integridade. A seguinte anotação pode responder com 200 OK:

alb.ingress.kubernetes.io/healthcheck-path: /ping

-ou-

Você pode usar a seguinte anotação no recurso de entrada para adicionar um intervalo de códigos de status de resposta de verificação de integridade bem-sucedido:

alb.ingress.kubernetes.io/success-codes: 200-399

Para verificações de integridade do TCP, use o seguinte comando para instalar o comando netcat:

# yum update -y && yum install -y nc

Teste as verificações de integridade do TCP:

# nc -z -v APPLICATION_POD_IP CONTAINER_PORT_NUMBER

Observação: substitua APPLICATION_POD_IP pelo IP do pod da aplicação e CONTAINER_PORT_NUMBER pela porta do contêiner.

Exemplo de comando:

# nc -z -v 192.168.81.137 80

Saída de exemplo:

Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 192.168.81.137:80.
Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.

Verifique as redes

Para problemas de rede, verifique o seguinte:

  • Os vários grupos de nós no cluster do EKS podem se comunicar livremente uns com os outros
  • A lista de controle de acesso à rede (ACL da rede) associada à sub-rede em que os pods estão sendo executados permite o tráfego do intervalo CIDR da sub-rede do balanceador de carga
  • A ACL da rede associada à sub-rede do balanceador de carga deve permitir o tráfego de retorno no intervalo de portas efêmeras da sub-rede em que os pods estão sendo executados
  • A tabela de rotas permite o tráfego local de dentro do intervalo CIDR da VPC

Reinicie o kube-proxy

Se o kube-proxy executado em cada nó não estiver se comportando corretamente, ele poderá falhar ao atualizar as regras do iptables para o serviço e os endpoints. Reinicie o kube-proxy para forçá-lo a verificar novamente e atualizar as regras do iptables:

kubectl rollout restart daemonset.apps/kube-proxy -n kube-system

Saída de exemplo:

daemonset.apps/kube-proxy restarted

Informações relacionadas

Como faço para configurar um Application Load Balancer usando o AWS Load Balancer Controller em um grupo de nós do Amazon EC2 no Amazon EKS?

Como soluciono problemas de balanceadores de carga de serviço do Amazon EKS?

Como posso marcar as sub-redes do Amazon VPC em meu cluster do Amazon EKS para a descoberta automática de sub-redes por balanceadores de carga ou controladores de entrada?


AWS OFICIAL
AWS OFICIALAtualizada há 2 anos