Come posso risolvere i problemi che si verificano quando utilizzo AWS Load Balancer Controller per creare un bilanciatore del carico?

Breve descrizione

AWS Load Balancer Controller gestisce Elastic Load Balancing per un cluster Amazon Elastic Kubernetes Service (Amazon EKS).

Il controller fornisce le seguenti risorse:

• Un Application Load Balancer quando crei un ingress in Kubernetes.
• Un Network Load Balancer quando crei un servizio Kubernetes del tipo LoadBalancer.
  Nota: con AWS Load Balancer Controller versione 2.3.0 o successiva, puoi creare un Network Load Balancer con l'istanza o il tipo di destinazione IP.

Risoluzione

Assicurati di soddisfare tutti i prerequisiti per installare e utilizzare AWS Load Balancer Controller

Per un elenco delle azioni iniziali da intraprendere, consulta Prerequisiti.

Esegui questo comando per verificare di aver distribuito correttamente AWS Load Balancer Controller:

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

Nota: è consigliabile utilizzare la versione 2.4.4 o successiva.

Esempio di output:

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

Se utilizzi un Application Load Balancer, verifica di avere almeno due sottoreti in diverse zone di disponibilità. Un Network Load Balancer deve avere almeno una sottorete. Le sottoreti devono avere almeno otto indirizzi IP disponibili. Per ulteriori informazioni, consulta Crea un VPC.

Devi utilizzare il seguente tag in determinati scenari:

• Chiave: "kubernetes.io/cluster/cluster-name"
• Valore: "shared" o "owned"

Application Load Balancer

Devi applicare un tag a un gruppo di sicurezza nei seguenti scenari:

• Utilizzi più gruppi di sicurezza collegati a un nodo worker.
• Utilizzi AWS Load Balancer Controller versione v2.1.1 o precedente.

Network Load Balancer

Se utilizzi AWS Load Balancer Controller versione v2.1.1 o precedente, devi aggiungere tag alle sottoreti.

Se non hai specificato gli ID di sottorete nelle annotazioni per l'ingress o il servizio, assicurati che le sottoreti abbiano i tag richiesti per il loro rilevamento automatico. Per ulteriori informazioni, consulta Subnet Auto Discovery (Rilevamento automatico delle sottoreti) sul sito web GitHub.

Per una sottorete privata, utilizza i seguenti tag:

• Chiave: "kubernetes.io/role/internal-elb"
• Valore: "1"

Per le sottoreti pubbliche, utilizza i seguenti tag:

• Chiave: "kubernetes.io/role/elb"
• Valore: "1"

Controlla le annotazioni per l'oggetto ingress o servizio

Assicurati che le annotazioni per l'oggetto ingress o servizio siano corrette.

Nota: nei comandi seguenti sostituisci SERVICE-NAME, INGRESS-NAME e NAMESPACE con i tuoi valori.

Per visualizzare l'oggetto servizio, esegui questo comando:

kubectl describe service SERVICE-NAME -n NAMESPACE

Per visualizzare l'oggetto ingress, esegui questo comando:

kubectl describe ingress INGRESS-NAME -n NAMESPACE

Per modificare l'oggetto servizio, esegui questo comando:

kubectl edit service SERVICE-NAME -n NAMESPACE

Per modificare l'oggetto ingress, esegui questo comando:

kubectl edit ingress INGRESS-NAME -n NAMESPACE

Le altre annotazioni utilizzano valori predefiniti. Per un elenco delle annotazioni supportate da AWS Load Balancer Controller per gli Application Load Balancer, consulta Ingress annotations (Annotazioni per l’ingress) sul sito web GitHub. Per un elenco delle annotazioni supportate per i Network Load Balancer, consulta Service annotations (Annotazioni per il servizio) sul sito web GitHub.

Application Load Balancer

Nelle versioni di Kubernetes precedenti alla 1.18, le classi di ingress utilizzavano l'annotazione kubernetes.io/ingress.class che fa riferimento al nome del controller ingress. Le classi ingress in tutte le versioni successive di Kubernetes utilizzano l'annotazione IngressClassName che fa riferimento alla risorsa della classe ingress.

Per ulteriori informazioni, consulta Deprecated kubernetes.io/ingress.class annotation (Annotazione kubernetes.io/ingress.class obsoleta) sul sito web GitHub.

Network Load Balancer

Utilizza le seguenti annotazioni:

• Con le destinazioni IP, utilizza service.beta.kubernetes.io/aws-load-balancer-type: "external" e service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip".
• Con le destinazioni istanza, utilizza service.beta.kubernetes.io/aws-load-balancer-type: "external" e service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "instance".

Risolvi i problemi che si verificano durante la creazione del bilanciatore del carico del tipo iingress o servizio in Amazon EKS

Ricevi l'errore "AccessDenied"

Ricevi il seguente messaggio di errore:

"Failed deploy model due to AccessDenied"

L'errore si verifica perché l'autorizzazione elasticloadbalancing:AddTags per creare risorse è cambiata. Per risolvere il problema, collega la policy AWS Identity and Access Management (AWS IAM) più recente al ruolo AWSLoadBalancerController. Per ottenere la policy più recente, consulta IAM policy JSON (JSON della policy IAM) sul sito web GitHub.

Per ulteriori informazioni, consulta Creare un ruolo IAM utilizzando eksctl.

Il bilanciatore del carico non è supportato nella zona di disponibilità

Se specifichi una sottorete in una zona di disponibilità vincolata, potresti ricevere un messaggio di errore simile al seguente:

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

Per risolvere il problema, specifica una sottorete in un'altra zona di disponibilità che non sia vincolata. Quindi utilizza il bilanciamento del carico tra zone per distribuire il traffico verso le destinazioni nella zona di disponibilità vincolata.

Per utilizzare sottoreti diverse, aggiungi il tag kubernetes.io/role/internal-elb=1 per le sottoreti che utilizzi per creare un Network Load Balancer interno. Per ulteriori informazioni, consulta Etichetta un Network Load Balancer.

Oppure aggiungi la seguente annotazione per specificare le sottoreti nel file manifesto del servizio:

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

Nota: sostituisci subnet-xxxx con l'ID della tua sottorete e mySubnet con il nome della tua sottorete.

Non riesci a utilizzare il rilevamento automatico per le sottoreti

Se non applichi un tag alle sottoreti per il rilevamento automatico, potresti ricevere il seguente messaggio di errore:

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

AWS Load Balancer Controller rileva automaticamente le sottoreti di rete per impostazione predefinita. Per gli Application Load Balancer, devi avere almeno due sottoreti in diverse zone di disponibilità. Un Network Load Balancer richiede una sola sottorete.

Affinché il rilevamento automatico funzioni, devi applicare i tag appropriati alle sottoreti. Il controller seleziona una sottorete da ciascuna zona di disponibilità. Se una zona di disponibilità ha più sottoreti con tag, il controller ne sceglie solamente una in base agli ID alfabetici delle sottoreti.

Per ulteriori informazioni sui tag richiesti per le sottoreti private e pubbliche, consulta Subnet auto discovery (Rilevamento automatico delle sottoreti) sul sito web GitHub.

È presente un problema di configurazione del gestore dei certificati o del webhook

Se la convalida del webhook ha esito negativo, potresti ricevere il seguente messaggio di errore:

"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"

Questo errore si verifica in caso di problemi con i certificati gestiti da Gestione certificati AWS (ACM) per i webhook.

Per risolvere il problema, controlla se i pod di Gestione certificati sono in esecuzione.

Per ottenere lo stato di un pod, esegui questo comando:

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

Per raccogliere i log, esegui questo comando:

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

Nota: nei comandi precedenti, sostituisci your-pod-name con il nome del tuo pod e your-namespace con il nome del tuo namespace.

La creazione dell'associazione del gruppo di destinazione non è riuscita

Se la creazione dell'associazione del gruppo di destinazione non riesce, potresti ricevere il seguente messaggio di errore:

"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"

Questo errore si verifica quando le restrizioni dei gruppi di sicurezza bloccano l'accesso al servizio webhook. Il servizio utilizza la porta 9443 per impostazione predefinita.

Per risolvere il problema, modifica il gruppo di sicurezza del nodo. Consenti il traffico in entrata dal gruppo di sicurezza del piano di controllo (control-plane) sulla porta 9443. Per ulteriori informazioni, consulta Controller configuration options (Opzioni di configurazione del controller) sul sito web GitHub.

AssumeRoleWithWebIdentity non riuscito per il ruolo del nodo

Se il ruolo del nodo non può assumere il ruolo specificato nell'account di servizio, potresti ricevere il seguente messaggio di errore:

"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"

Questo errore si verifica perché hai configurato erroneamente i ruoli IAM per gli account di servizio (IRSA).

Per risolvere il problema, utilizza il ruolo corretto nell'account di servizio e definisci una policy di attendibilità per il ruolo.

Per ulteriori informazioni, consulta Perché ricevo il messaggio di errore "webidentityerr", quando utilizzo AWS Load Balancer Controller in Amazon EKS? e Come posso risolvere i problemi relativi a un provider OIDC e IRSA in Amazon EKS?

Nei log dei pod del controller i dati sono insufficienti

Se hai bisogno di più informazioni di debug rispetto a quelle fornite dai log predefiniti dei pod del controller, aggiungi il flag --log-level debug alla configurazione del pod del controller.

Per ulteriori informazioni, consulta Controller command line flags (Flag della riga di comando del controller) sul sito web GitHub.

Esamina i log del pod di AWS Load Balancer Controller per ulteriori informazioni

Per esaminare i log di AWS Load Balancer Controller, esegui questo comando:

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

Se è presente un problema, ricevi un "Reconciler error". Ricevi inoltre un messaggio di errore dettagliato che indica il motivo per cui la creazione o l'aggiornamento di un oggetto ingress o servizio del bilanciatore del carico ha esito negativo.

L'errore può verificarsi per i seguenti motivi:

• Se l'errore si verifica quando il controller tenta di effettuare chiamate API AWS, è presente un problema di autorizzazioni o connettività. Rivedi le autorizzazioni IAM del controller. Quindi assicurati che i gruppi di sicurezza o le liste di controllo degli accessi alla rete (ACL) non neghino esplicitamente le connessioni in uscita.
• Se l'errore si verifica nella configurazione dell'oggetto, ciò significa che le specifiche o le annotazioni per l'ingress o il servizio sono state configurate in modo errato. Rivedi le annotazioni per Application Load Balancer o Network Load Balancer sul sito web GitHub.

Se nessuno dei pod del controller mostra log, esegui questo comando per verificare che i pod del controller siano in esecuzione:

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

Aggiorna a una versione del controller supportata

Se utilizzi una versione di AWS Load Balancer Controller che non è più supportata, non puoi eseguire l'aggiornamento a una versione successiva. Devi invece rimuovere il controller esistente e installare la versione più recente.

Utilizza AWS Load Balancer Controller anziché il provider di cloud legacy

Kubernetes include un provider cloud legacy per AWS in grado di fornire Classic Load Balancer. Se non installi AWS Load Balancer Controller, Kubernetes utilizza il provider cloud legacy. È tuttavia consigliabile utilizzare AWS Load Balancer Controller.

AWS Load Balancer Controller versione 2.5 e successive è il controller predefinito per le risorse del servizio Kubernetes del tipo LoadBalancer, crea un Network Load Balancer per ogni servizio e, nelle ultime versioni, implementa anche un webhook mutante per i servizi. Inoltre, imposta il campo spec.loadBalancerClass su service.k8s.aws/nlb per i servizi LoadBalancer del nuovo tipo.

Per passare a AWS Load Balancer Controller, esegui questo 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

Nota: sostituisci CLUSTER-NAME con il nome del tuo cluster.

Se devi utilizzare il provider cloud legacy, imposta il valore del grafico Helm enableServiceMutatorWebhook su false in modo da non fornire nuovi Classic Load Balancer. Solo i Classic Load Balancer esistenti continuano a funzionare.

Verifica di aver creato un profilo Fargate per il namespace in cui si trova l'oggetto ingress o servizio

Quando i pod di destinazione sono in esecuzione su AWS Fargate, devi includere il tipo di destinazione IP. Per verificare di avere un profilo Fargate per il namespace in cui si trova l'oggetto ingress o servizio, esegui questo comando:

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

Nota: sostituisci CLUSTER-NAME con il nome del tuo cluster.

Per creare un profilo Fargate, esegui questo comando:

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

Nota: sostituisci CLUSTER-NAME, REGION, FARGATE-PROFILE-NAME e NAMESPACE con i tuoi valori.

Verifica di soddisfare i requisiti per indirizzare il traffico

Per accertarti di soddisfare tutti i requisiti, consulta Prerequisiti per gli Application Load Balancer e Prerequisiti per i Network Load Balancer. Ad esempio, se utilizzi un Application Load Balancer, l'oggetto Servizio deve specificare il valore NodePort o LoadBalancer per utilizzare la modalità di traffico dell'istanza.

Amazon EKS aggiunge le seguenti regole al gruppo di sicurezza del nodo:

• Una regola in entrata per il traffico del client
• Una regola in entrata per ogni sottorete del bilanciatore del carico nel VPC per ogni Network Load Balancer creato per i controlli dell'integrità

Se le regole aggiunte da Amazon EKS fanno sì che il gruppo di sicurezza superi il numero massimo di regole, la distribuzione del bilanciatore del carico potrebbe non riuscire.