Como solucionar problemas ao criar um balanceador de carga usando o AWS Load Balancer Controller?

Breve descrição

O AWS Load Balancer Controller gerencia o Elastic Load Balancing para um cluster do Amazon Elastic Kubernetes Service (Amazon EKS).

O controlador fornece os seguintes recursos:

• Um Application Load Balancer quando você cria uma entrada do Kubernetes.
• Um Network Load Balancer quando você cria um serviço Kubernetes do tipo LoadBalancer.
  Observação: com o AWS Load Balancer Controller versão 2.3.0 ou posterior, é possível criar um Network Load Balancer com o tipo de instância ou IP de destino.

Resolução

Verificar se atende a todos os pré-requisitos para instalar e usar o AWS Load Balancer Controller

Para obter uma lista das ações iniciais a serem tomadas, consulte Pré-requisitos.

Execute o comando a seguir para verificar se você implantou o AWS Load Balancer Controller:

kubectl get deployment -n kube-system aws-load-balancer-controller

Observação: é uma prática recomendada usar a versão 2.4.4 ou posterior.

Exemplo de saída:

NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
aws-load-balancer-controller   2/2     2            2           84s

Se você estiver usando um Application Load Balancer, verifique se tem pelo menos duas sub-redes em diferentes zonas de disponibilidade. O Network Load Balancer deve ter pelo menos uma sub-rede. As sub-redes devem ter pelo menos oito endereços IP disponíveis. Para mais informações, consulte Criar uma nuvem privada virtual (VPC).

Você deve usar a tag a seguir em determinados casos:

• Chave: "kubernetes.io/cluster/cluster-name"
• Valor: "shared" ou "owned"

Application Load Balancers

Você deve marcar um grupo de segurança nos seguintes casos:

• Você usa vários grupos de segurança anexados a um nó de processamento.
• Você usa o AWS Load Balancer Controller versão v2.1.1 ou anterior.

Network Load Balancers

Se você usar o AWS Load Balancer Controller versão v2.1.1 ou anterior, deverá adicionar tags às sub-redes.

Se você não especificou IDs de sub-rede em seu serviço ou nas anotações de entrada, certifique-se de que suas sub-redes tenham as tags necessárias para a descoberta automática de sub-redes. Para mais informações, consulte Subnet auto discovery (Descoberta automática de sub-redes) no site do GitHub.

Para sub-redes privadas, use as seguintes tags:

• Chave: "kubernetes.io/role/internal-elb"
• Valor: "1"

Para sub-redes públicas, use as seguintes tags:

• Chave: "kubernetes.io/role/elb"
• Valor: "1"

Verificar as anotações do objeto de entrada ou serviço

Verifique se as anotações no objeto de serviço ou no objeto de entrada estão corretas.

Observação: nos comandos a seguir, substitua SERVICE-NAME, INGRESS-NAME e NAMESPACE por seus valores.

Para visualizar o objeto de serviço, execute o seguinte comando:

kubectl describe service SERVICE-NAME -n NAMESPACE

Para visualizar o objeto de entrada, execute o seguinte comando:

kubectl describe ingress INGRESS-NAME -n NAMESPACE

Para editar o objeto de serviço, execute o seguinte comando:

kubectl edit service SERVICE-NAME -n NAMESPACE

Para editar o objeto de entrada, execute o seguinte comando:

kubectl edit ingress INGRESS-NAME -n NAMESPACE

Outras anotações usam valores padrão. Para ver uma lista de anotações que o AWS Load Balancer Controller suporta para Application Load Balancers, consulte Ingress annotations (Anotações de entrada) no site do GitHub. Para obter uma lista de anotações compatíveis com Network Load Balancers, consulte Service annotations (Anotações de serviço) no site do GitHub.

Application Load Balancer

Nas versões do Kubernetes anteriores à 1.18, as classes de entrada usavam a anotação kubernetes.io/ingress.class que faz referência ao nome do controlador de entrada. As classes de entrada em todas as versões posteriores do Kubernetes usam a anotação ingressClassName que faz referência ao recurso da classe de entrada.

Para mais informações, consulte Deprecated kubernetes.io/ingress.class annotation (Anotação kubernetes.io/ingress.class obsoleta) no site do GitHub.

Network Load Balancer

Use as seguintes anotações:

• Com destinos IP, use service.beta.kubernetes.io/aws-load-balancer-type: "external" e service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip".
• Com destinos de instância, use service.beta.kubernetes.io/aws-load-balancer-type: "external" e service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "instance".

Solucionar problemas ao criar o balanceador de carga de entrada ou tipo de serviço no Amazon EKS

Você recebe o erro "AccessDenied"

Você vê a seguinte mensagem de erro:

"Failed deploy model due to AccessDenied"

Esse erro ocorre porque a permissão elasticloadbalancing:AddTags para criar recursos foi alterada. Para resolver o problema, anexe a política mais recente do AWS Identity and Access Management (AWS IAM) ao perfil AWSLoadBalancerController. Para obter a política mais recente, consulte IAM policy JSON (Política JSON do IAM) no site do GitHub.

Para mais informações, consulte Create IAM role using eksctl (Criar perfil do IAM usando eksctl).

O balanceador de carga não é compatível com a zona de disponibilidade

Se você especificar uma sub-rede em uma zona de disponibilidade restrita, poderá receber uma mensagem de erro semelhante à seguinte:

"Load balancers with type 'network' are not supported in availability-zone-name"

Para resolver esse problema, especifique uma sub-rede em outra zona de disponibilidade que não esteja restrita. Em seguida, use o balanceamento de carga entre zonas para distribuir o tráfego para destinos na zona de disponibilidade restrita.

Para usar sub-redes diferentes, adicione a tag kubernetes.io/role/internal-elb=1 às sub-redes que você usa para criar um Network Load Balancer interno. Para mais informações, consulte Tag a Network Load Balancer (Marcar um Network Load Balancer).

Ou adicione a seguinte anotação para especificar as sub-redes no arquivo de manifesto do serviço:

service.beta.kubernetes.io/aws-load-balancer-subnets: subnet-xxxx, mySubnet

Observação: substitua subnet-xxxx pelo ID da sub-rede e mySubnet pelo nome da sub-rede.

Não é possível usar a descoberta automática para sub-redes

Se você não marcar suas sub-redes para descoberta automática, poderá receber a seguinte mensagem de erro:

"couldn't auto-discover subnets: unable to resolve at least one subnet"

O AWS Load Balancer Controller descobre automaticamente sub-redes de rede por padrão. Para Application Load Balancers, você deve ter pelo menos duas sub-redes em diferentes zonas de disponibilidade. Um Network Load Balancer requer somente uma sub-rede.

Para que a descoberta automática funcione, você deve aplicar as tags apropriadas às suas sub-redes. O controlador seleciona uma sub-rede de cada zona de disponibilidade. Se uma zona de disponibilidade tiver várias sub-redes marcadas, o controlador escolherá somente uma com base nas IDs de sub-rede alfabéticas.

Para mais informações sobre as tags de sub-rede necessárias para sub-redes privadas e públicas, consulte Subnet auto discovery (Descoberta automática de sub-rede) no site do GitHub.

Há um problema de configuração do gerenciador de certificados ou do webhook

Se a validação do webhook falhar, você poderá receber a seguinte mensagem de erro:

"Internal error occurred: failed calling webhook "vingress.elbv2.k8s.aws": Post "https://aws-load-balancer-webhook-service.kube-system.svc:443/validate-networking-v1beta1-ingress?timeout=10s": x509: certificate has expired or is not yet valid"

Esse erro ocorre quando há problemas com os certificados que o AWS Certificate Manager (ACM) gerencia para seus webhooks.

Para resolver esse problema, verifique se os pods do Certificate Manager estão em execução.

Para consultar o status do pod, execute o seguinte comando:

kubectl describe pod your-pod-name -n your-namespace

Para coletar logs, execute o seguinte comando:

kubectl logs your-pod-name -n your-namespace

Observação: nos comandos anteriores, substitua your-pod-name pelo nome do seu pod e your-namespace pelo nome do seu namespace.

A criação da vinculação do grupo de destino falhou

Se a criação da vinculação do seu grupo de destino falhar, você poderá receber a seguinte mensagem de erro:

"Warning FailedDeployModel 11m (x2 over 39m) ingress Failed deploy model due to Internal error occurred: failed calling webhook "vtargetgroupbinding.elbv2.k8s.aws": failed to call webhook: Post "https://aws-load-balancer-webhook-service.kube-system.svc:443/validate-elbv2-k8s-aws-v1beta1-targetgroupbinding?timeout=10s": context deadline exceeded"

Esse erro ocorre quando as restrições do grupo de segurança bloqueiam o acesso ao serviço de webhook. O serviço usa a porta 9443 por padrão.

Para resolver esse problema, modifique seu grupo de segurança de nós. Permita tráfego de entrada do grupo de segurança do ambiente de gerenciamento na porta 9443. Para mais informações, consulte Controller configuration options (Opções de configuração do controlador) no site do GitHub.

Falha em AssumeRoleWithWebIdentity no perfil de nó

Se seu perfil de nó não puder assumir o perfil que você especificou na conta de serviço, você poderá receber a seguinte mensagem de erro:

"WebIdentityErr: failed to retrieve credentials\ncaused by: AccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity\n\tstatus code: 403, request id: c6241a7d-d8a8-452c-bb67-bf1ff9bab0c0"

Esse erro ocorre porque você configurou incorretamente os perfis do IAM para contas de serviço (IRSA).

Para resolver esse problema, use o perfil correto na conta de serviço e defina uma política de confiança para o perfil.

Para mais informações, consulte Por que recebo o erro "WebIdentityErr" quando uso o AWS Load Balancer Controller no Amazon EKS? e Como solucionar problemas de um provedor de OIDC e IRSA no Amazon EKS?

Os dados são insuficientes nos logs do pod do controlador

Se você precisar de mais informações de depuração do que as fornecidas pelos logs padrão do pod do controlador, adicione o sinalizador --log-level debug à configuração do pod do controlador.

Para mais informações, consulte Controller command line flags (Sinalizadores da linha de comandos do controlador) no site do GitHub.

Consulte os logs do pod do AWS Load Balancer Controller para mais informações

Para consultar os logs do AWS Load Balancer Controller, execute o seguinte comando:

kubectl logs -n kube-system deployment.apps/aws-load-balancer-controller

Se houver um problema, você receberá um "Reconciler error". Você também recebe uma mensagem de erro detalhada que indica por que um objeto de entrada ou serviço de balanceador de carga falha na criação ou atualização.

Essa falha pode ocorrer pelos seguintes motivos:

• Se o erro ocorrer quando o controlador tentar fazer chamadas de API da AWS, então há um problema de permissão ou conectividade. Analise as permissões de IAM do controlador. Em seguida, certifique-se de que os grupos de segurança ou as listas de controle de acesso à rede (ACLs de rede) não neguem explicitamente as conexões de saída.
• Se o erro ocorrer na configuração do objeto, você configurou incorretamente a especificação de entrada ou de serviço ou as anotações. Consulte as anotações de Application Load Balancer ou Network Load Balancer no site do GitHub.

Se nenhum dos pods do controlador mostrar logs, execute o seguinte comando para confirmar se os pods do controlador estão em execução:

kubectl get deployment -n kube-system aws-load-balancer-controller

Atualizar para uma versão de controlador compatível

Se você usa uma versão do AWS Load Balancer Controller que não é mais suportada, não é possível fazer o upgrade para uma versão posterior. Em vez disso, você deve remover o controlador atual e instalar a versão mais recente.

Use o AWS Load Balancer Controller em vez do provedor de nuvem legado

O Kubernetes inclui um provedor de nuvem legado para a AWS que pode fornecer Classic Load Balancers. Se você não instalar o AWS Load Balancer Controller, o Kubernetes usará o provedor de nuvem legado. No entanto, é uma prática recomendada usar o AWS Load Balancer Controller.

O AWS Load Balancer Controller versão 2.5 e posteriores é o controlador padrão para recursos de serviço do Kubernetes com o tipo LoadBalancer. Ele cria um Network Load Balancer para cada serviço. As versões mais recentes também implementam um webhook variável para serviços. Elas definem o campo spec.loadBalancerClass como service.k8s.aws/nlb para o novo tipo de serviços do LoadBalancer.

Para fazer upgrade do AWS Load Balancer Controller, execute o seguinte comando:

helm upgrade aws-load-balancer-controller eks/aws-load-balancer-controller -n kube-system --set clusterName=CLUSTER-NAME --set serviceAccount.create=false --set serviceAccount.name=aws-load-balancer-controller --set enableServiceMutatorWebhook=false

Observação: substitua CLUSTER-NAME pelo nome do seu cluster.

Se você precisar usar o provedor de nuvem legado, defina o valor do chart do Helm enableServiceMutatorWebhook como false para que isso não forneça novos Classic Load Balancers. Somente os Classic Load Balancers atuais continuam funcionando.

Verifique se você criou um perfil do Fargate para o namespace em que o objeto de entrada ou serviço está

Quando os pods de destino estão em execução no AWS Fargate, você deve incluir o tipo de destino IP. Para verificar se você tem um perfil do Fargate para o namespace em que está o objeto de entrada ou serviço, execute o seguinte comando:

eksctl get fargateprofile --cluster CLUSTER-NAME -o yaml

Observação: substitua CLUSTER-NAME pelo nome do seu cluster.

Para criar um perfil do Fargate, execute o seguinte comando:

eksctl create fargateprofile --cluster CLUSTER-NAME --region REGION --name FARGATE-PROFILE-NAME --namespace NAMESPACE

Observação: substitua CLUSTER-NAME, REGION, FARGATE-PROFILE-NAME e NAMESPACE por seus valores.

Verificar se atende aos requisitos para rotear o tráfego

Para garantir que você atenda a todos os requisitos, consulte Pré-requisitos para Application Load Balancers e Pré-requisitos para Network Load Balancers. Por exemplo, se você usa um Application Load Balancer, o objeto Service deve especificar NodePort ou LoadBalancer para usar o modo de tráfego da instância.

O Amazon EKS adiciona as seguintes regras ao grupo de segurança do nó:

• Uma regra de entrada para tráfego de cliente
• Uma regra de entrada para cada sub-rede do balanceador de carga na VPC para cada Network Load Balancer que você cria para verificações de integridade

Se as regras adicionadas pelo Amazon EKS fizerem com que seu grupo de segurança exceda o número máximo de regras, a implantação do balanceador de carga poderá falhar.