Como resolvo uma falha na verificação de integridade de um balanceador de carga no Amazon EKS?
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 soluciono problemas de balanceadores de carga de serviço do Amazon EKS?
Vídeos relacionados
Conteúdo relevante
- AWS OFICIALAtualizada há 2 anos
- AWS OFICIALAtualizada há um ano
- AWS OFICIALAtualizada há um ano