Por que o status do meu nó de processamento é “Unhealthy” quando uso o NGINX Ingress Controller com o Amazon EKS?
Data da última atualização: 13/12/2021
Eu uso o NGINX Ingress Controller para expor o recurso de entrada, mas meus nós de processamento do Amazon Elastic Kubernetes Service (Amazon EKS) não usam o Network Load Balancer.
Breve descrição
O NGINX Ingress Controller define a opção SPEC.ExternalTrafficPolicy como Local para preservar o IP do cliente. Além disso, as solicitações não são roteadas para nós de processamento não íntegros. A solução de problemas a seguir implica que você não precise manter o endereço IP do cluster ou preservar o endereço IP do cliente.
Resolução
Confira o status de integridade do seu nó de processamento:
Nota: Os exemplos a seguir usam o NGINX Ingress Controller v1.0.2.
1. Crie os recursos obrigatórios para o NGINX Ingress Controller (do site do Kubernetes) em seu cluster:
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.0.2/deploy/static/provider/aws/deploy.yaml
Por padrão, o NGINX Ingress Controller cria o serviço Kubernetes ingress-nginx-controller com a opção .spec.ExternalTrafficPolicy definida como Local (no site do GitHub).
2. Verifique se a política de tráfego externo (do site do Kubernetes) está definida como Local:
$ kubectl -n ingress-nginx describe svc ingress-nginx-controller
Resultado:
Name: ingress-nginx-controller
Namespace: ingress-nginx
Labels: app.kubernetes.io/component=controller
app.kubernetes.io/instance=ingress-nginx
app.kubernetes.io/managed-by=Helm
app.kubernetes.io/name=ingress-nginx
app.kubernetes.io/version=1.0.2
helm.sh/chart=ingress-nginx-4.0.3
Annotations: service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp
service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: true
service.beta.kubernetes.io/aws-load-balancer-type: nlb
Selector: app.kubernetes.io/component=controller,app.kubernetes.io/instance=ingress-nginx,app.kubernetes.io/name=ingress-nginx
Type: LoadBalancer
IP Families: <none>
IP: 10.100.115.226
IPs: 10.100.115.226
LoadBalancer Ingress: a02245e77404f4707a725d0b977425aa-5b97f717658e49b9.elb.eu-west-1.amazonaws.com
Port: http 80/TCP
TargetPort: http/TCP
NodePort: http 31748/TCP
Endpoints: 192.168.43.203:80
Port: https 443/TCP
TargetPort: https/TCP
NodePort: https 30045/TCP
Endpoints: 192.168.43.203:443
Session Affinity: None
External Traffic Policy: Local
HealthCheck NodePort: 30424
Events: <none>
Observação: a configuração Local descarta pacotes que são enviados para nós do Kubernetes que não estão executando instâncias do NGINX Ingress Controller. Atribua pods NGINX (do site do Kubernetes) aos nós nos quais você deseja agendar o NGINX Ingress Controller.
3. Verifique o comando iptables que configurou as regras DROP nos nós que não estão executando instâncias do NGINX Ingress Controller:
$ sudo iptables-save | grep -i "no local endpoints"
-A KUBE-XLB-CG5I4G2RS3ZVWGLK -m comment --comment "ingress-nginx/ingress-nginx-controller:http has no local endpoints
" -j KUBE-MARK-DROP
-A KUBE-XLB-EDNDUDH2C75GIR6O -m comment --comment "ingress-nginx/ingress-nginx-controller:https has no local endpoints " -j KUBE-MARK-DROP
Defina a opção de política
Atualize a opção PEC.ExternalTrafficPolicy para Cluster:
$ kubectl -n ingress-nginx patch service ingress-nginx-controller -p '{"spec":{"externalTrafficPolicy":"Cluster"}}'
service/ingress-nginx-controller patched
Observação: por padrão, os serviços do NodePort realizam a tradução do endereço de origem (do site do Kubernetes). Para o NGINX, isso significa que o IP de origem de uma solicitação HTTP é sempre o endereço IP do nó do Kubernetes que recebeu a solicitação. Se você definir um nodePort para o valor do campo ExternalTrafficPolicy na especificação do serviço ingress-nginx como Cluster, não será possível manter o endereço IP de origem.
Este artigo ajudou?
Precisa de ajuda com faturamento ou suporte técnico?