Como soluciono problemas de destinos não íntegros para Network Load Balancers no Amazon EKS?
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.
Conteúdo relevante
- AWS OFICIALAtualizada há um ano
- AWS OFICIALAtualizada há um ano
- AWS OFICIALAtualizada há 2 anos
- AWS OFICIALAtualizada há 2 anos