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

6 minuto de leitura
0

Desejo resolver destinos não íntegros para Network Load Balancers no meu Amazon Elastic Kubernetes Service (Amazon EKS).

Breve descrição

Veja a seguir os motivos comuns pelos quais os destinos do seu Network Load Balancer não estão íntegros:

  • A verificação de integridade está configurada incorretamente. Para resolver esse problema, inicie manualmente a verificação de integridade de uma máquina host que esteja sendo executada na Amazon Virtual Private Cloud (Amazon VPC).
  • Há uma exceção inesperada a partir do pod. Para resolver esse problema, siga as etapas de solução de problemas na seção de resolução Verificar se há uma exceção inesperada a partir do pod.
  • Um Network Load Balancer com externalTrafficPolicy definido como Local (no site do Kubernetes), com um DNS personalizado da Amazon VPC no conjunto de opções de DHCP. Para resolver esse problema, corrija o kube-proxy com a marcação de substituição do nome de host.

Observação: Você pode determinar se o tipo de grupo de destino é um endereço IP ou uma instância verificando se existe a anotação de serviço service.beta.kubernetes.io/aws-load-balancer-nlb-target-type.

Resolução

Verifique se o grupo de destino é 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.

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

Verifique quais anotações do Elastic Load Balancing (ELB) (no site do Kubernetes) estão configuradas para o seu serviço:

`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.

Se as anotações anteriores estiverem configuradas incorretamente, os destinos poderão não estar íntegros.

Iniciar manualmente a verificação de integridade a partir de uma máquina host que está sendo executada na 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 com 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 e pod_port pela porta do pod.

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

Tipo de destino da instância

Verifique a especificação do serviço para as anotações de configuração da verificação de integridade atuais (no site do GitHub):

kubectl get service service_name -o yaml

Verifique se há endpoints para saber se existem pods por trás do serviço:

kubectl get endpoints service_name -o yaml

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

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

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

Verifique se os pods estão no status Running (Executando):

kubectl get pod -o wide

Verifique os status dos pods para saber se os pods estão sendo executados sem reinicializações:

kubectl get pods -o wide

Se houver reinicializações, reúna os logs do pod para determinar a causa:

kubectl logs pod_name
kubectl logs pod_name --previous

Faça o login em uma máquina host na Amazon VPC onde possa se comunicar com o nó.

Use o comando curl com NodePort para verificar se os pods estão retornando 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 também não estão retornando o código de status HTTP esperado.

Use a mesma máquina host para se conectar ao endereço IP do pod e verifique 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 o externalTrafficPolicy do serviço (no site do Kubernetes) estiver definido como Local, somente os nós nos quais os pods de backend do serviço estão sendo executados são vistos como destinos íntegros.

Tipo de destino de endereço IP

Verifique a especificação do serviço para as anotações de configuração da verificação de integridade atuais (no site do GitHub):

kubectl get service service_name -o yaml

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.

Modificar o kube-proxy com a marcação de substituição do nome do host

Modifique o comando de especificação daemonset do kube-proxy, args e env, com:

---
spec:
  template:
    spec:
      containers:
      - name: kube-proxy
        command: [ "/bin/sh" ]
        args:
        - -c
        - |
          kube-proxy --v=2 --hostname-override=$(NODE_NAME) --config=/var/lib/kube-proxy-config/config
        env:
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: spec.nodeName

Para tipos de destino de instância, se externalTrafficPolicy estiver definido como Cluster ou Local, a configuração de entrada padrão do grupo de segurança do nó para NodePort será 0.0.0.0/0. Além disso, quando externalTrafficPolicy estiver definido como Local, uma verificação de integridade adicional NodePort será configurada para permitir intervalos de endereços IP CIDR de sub-rede.

Para controlar o endereço IP de origem no grupo de segurança do nó para NodePort, adicione loadBalancerSourceRanges na especificação e inclua os intervalos:

spec:
loadBalancerSourceRanges:
- "143.231.0.0/16"
- "xx.yy.zz.zz/24"

Observação: Se .spec.loadBalancerSourceRanges não estiver definido, o Kubernetes permitirá o tráfego de 0.0.0.0/0 para os grupos de segurança do nó. Se os nós tiverem endereços IP públicos, o tráfego que não seja do Network Load Balancer também poderá chegar a todas as instâncias nos grupos de segurança modificados.


AWS OFICIAL
AWS OFICIALAtualizada há 2 anos