Como resolvo uma falha na verificação de integridade de um balanceador de carga no Amazon EKS?
Meu balanceador de carga falha na verificação de integridade do meu Amazon Elastic Kubernetes Service (Amazon EKS).
Resolução
Para solucionar problemas de verificação de saúde com o balanceador de carga no Amazon EKS, conclua as etapas nas seções a seguir.
Verifique o status do pod
Verifique se o pod está no status Running e se os contêineres nos pods estão prontos:
$ kubectl get pod -n YOUR_NAMESPACE
Observação: substitua YOUR_NAMESPACE pelo seu namespace Kubernetes.
Exemplo de saída:
NAME READY STATUS RESTARTS AGEpodname 1/1 Running 0 16s
Se o contêiner do aplicativo no status do pod não estiver no status Running, a verificação de integridade do balanceador de carga não será respondida e falhará.
Verifique os seletores do pod e da etiqueta de serviço
Para rótulos de pods, execute o seguinte comando:
$ kubectl get pod -n YOUR_NAMESPACE --show-labels
Exemplo de saída:
NAME READY STATUS RESTARTS AGE LABELSalb-instance-6cc5cd9b9-prnxw 1/1 Running 0 2d19h app=alb-instance,pod-template-hash=6cc5cd9b9
Para verificar se o Kubernetes Service usa os rótulos do pod, execute o comando a seguir para verificar se a saída corresponde aos rótulos 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 seu namespace Kubernetes.
Exemplo de saída:
{"app":"alb-instance"}
Verifique se há endpoints ausentes
O controlador Kubernetes para o seletor de serviços verifica continuamente os pods que correspondam ao seletor e, em seguida, publica atualizações em um objeto de endpoint. Se você selecionou um rótulo incorreto, nenhum endpoint será exibido.
Execute o seguinte comando:
$ kubectl describe svc SERVICE_NAME -n YOUR_NAMESPACE
Exemplo de saída:
Name: alb-instanceNamespace: 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 há um endpoint ausente:
$ kubectl get endpoints SERVICE_NAME -n YOUR_NAMESPACE
Exemplo de saída:
NAME ENDPOINTS AGEalb-instance <none> 2d20h
Verifique se há problemas com os Application Load Balancers na política de tráfego de serviços e nos grupos de segurança do cluster
Os alvos não íntegros nos grupos-alvo do Application Load Balancer ocorrem por dois motivos:
- A política de tráfego do serviço, spec.externalTrafficPolicy está definida como Local em vez de Cluster.
- Os grupos de nós em um cluster têm diferentes grupos de segurança de cluster 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"}'
Exemplo de saída:
Local
Altere a configuração para Cluster:
$ kubectl edit svc SERVICE_NAME -n YOUR_NAMESPACE
Verifique os grupos de segurança do cluster
Conclua as seguintes etapas:
- Abra o console do Amazon EC2.
- Selecione a instância íntegra.
- Escolha a guia Segurança e, em seguida, verifique as regras de entrada do grupo de segurança.
- Selecione a instância não íntegra.
- Escolha a guia Segurança e, em seguida, verifique as regras de entrada do grupo de segurança.
Se o grupo de segurança de cada instância for diferente, você deverá modificar a regra de entrada de segurança no console do grupo de segurança:
Na guia Segurança, selecione o ID do grupo de segurança.
Escolha Editar regras de entrada para modificar as regras de entrada.
Adicione regras de entrada para permitir o tráfego de outros grupos de nós no cluster.
Verifique se seu serviço está configurado para targetPort
Seu targetPort deve corresponder ao containerPort no pod para o qual o serviço envia tráfego.
Para verificar para que seu 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'}"
Exemplo de saída:
alb-instance 8080 TCP
No exemplo de saída, 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 controlador do AWS Load Balancer tem as permissões corretas
O AWS Load Balancer Controller deve ter as permissões corretas para atualizar grupos de segurança e 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 registros de implantação do AWS Load Balancer Controller:
$ kubectl logs deploy/aws-load-balancer-controller -n kube-system
Verifique se há erros nos registros 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 Kubernetes.
Verifique as anotações de entrada para ver se há 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 do seu Kubernetes Ingress e YOUR_NAMESPACE pelo seu namespace Kubernetes.
Exemplo de saída:
Name: alb-instance-ingressNamespace: 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 Ingress annotations no site do Kubernetes.
Verifique as anotações do Kubernetes Service para ver se há problemas com os balanceadores de carga de rede
Para problemas com o Network Load Balancer, verifique as anotações do Kubernetes Service:
$ kubectl describe svc SERVICE_NAME -n YOUR_NAMESPACE
Exemplo de saída:
Name: nlb-ipNamespace: 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: observe o valor de APPLICATION_POD_IP para executar um comando de verificação de integridade em uma etapa posterior.
Para encontrar anotações do Kubernetes Service específicas para seu caso de uso, consulte Service annotations no site do Kubernetes.
Teste manualmente uma verificação de integridade
Verifique o endereço IP do pod do aplicativo:
$ kubectl get pod -n YOUR_NAMESPACE -o wide
Execute um pod de teste para testar manualmente uma verificação de integridade no cluster:
$ kubectl run -n YOUR_NAMESPACE troubleshoot -it --rm --image=amazonlinux -- /bin/bash
Em seguida, execute a verificação de integridade do HTTP:
# curl -Iv APPLICATION_POD_IP/HEALTH_CHECK_PATH
Observação: substitua APPLICATION_POD_IP pelo endereço IP do pod de aplicativo e HEALTH_CHECK_PATH com o caminho de verificação de integridade do grupo de destino do Application Load Balancer.
Exemplo de comando:
# curl -Iv 192.168.81.137
Exemplo de saída:
* 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, seu aplicativo responderá corretamente ao caminho da verificação de integridade.
Se o código de status da resposta HTTP for 3xx ou 4xx, altere o caminho da verificação de integridade. A anotação a seguir responde com 200 OK:
alb.ingress.kubernetes.io/healthcheck-path: /ping
-ou-
Use 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 endereço IP do pod de aplicativo e CONTAINER_PORT_NUMBER pela porta do contêiner.
Exemplo de comando:
# nc -z -v 192.168.81.137 80
Exemplo de saída:
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 a rede
Para problemas de rede, verifique o seguinte:
- Os vários grupos de nós no cluster EKS podem se comunicar livremente entre si.
- A lista de controle de acesso à rede (ACL de rede) associada à sub-rede em que seus pods são executados permite o tráfego da faixa CIDR da sub-rede do balanceador de carga.
- A ACL de rede associada à sub-rede do balanceador de carga permite retornar tráfego no intervalo de portas efêmeras da sub-rede em que os pods são executados.
- A tabela de rotas permite tráfego local de dentro do intervalo CIDR da VPC.
Reinicie o kube-proxy
Se o kube-proxy executado em cada nó não funcionar corretamente, o kube-proxy pode 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
Exemplo de saída:
daemonset.apps/kube-proxy restarted
Informações relacionadas
- Tópicos
- Containers
- Idioma
- Português
Conteúdo relevante
feita há um ano
