Comment puis-je résoudre les problèmes rencontrés lorsque j'utilise AWS Load Balancer Controller pour créer un équilibreur de charge ?

Brève description

AWS Load Balancer Controller gère Elastic Load Balancing pour un cluster Amazon Elastic Kubernetes Service (Amazon EKS).

Le contrôleur fournit les ressources suivantes :

• Un Application Load Balancer lorsque vous créez une entrée Kubernetes.
• Un Network Load Balancer lorsque vous créez un service Kubernetes de type LoadBalancer.
  Remarque : Grâce à AWS Load Balancer Controller version 2.3.0 ou ultérieure, vous pouvez créer un Network Load Balancer avec le type instance ou cible IP.

Résolution

Assurez-vous de réunir toutes les conditions requises pour installer et utiliser AWS Load Balancer Controller

Pour obtenir la liste des mesures initiales à prendre, consultez la section Prérequis.

Exécutez la commande suivante pour vérifier que vous avez correctement déployé AWS Load Balancer Controller :

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

Remarque : Il est recommandé d'utiliser la version 2.4.4 ou ultérieure.

Exemple de sortie :

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

Si vous utilisez un Application Load Balancer, vérifiez que vous disposez d'au moins deux sous-réseaux dans des zones de disponibilité différentes. Un Network Load Balancer doit comporter au moins un sous-réseau. Les sous-réseaux doivent avoir au moins huit adresses IP disponibles. Pour plus d'informations, consultez la section Créer un cloud privé virtuel (VPC).

Vous devez utiliser l’identification suivante dans certains scénarios :

• Clé : "kubernetes.io/cluster/cluster-name"
• Valeur : "shared" ou "owned"

Application Load Balancers

Vous devez identifier un groupe de sécurité dans les scénarios suivants :

• Vous utilisez plusieurs groupes de sécurité associés à un composant master.
• Vous utilisez la version 2.1.1 ou antérieure d'AWS Load Balancer Controller.

Network Load Balancers

Si vous utilisez la version 2.1.1 ou antérieure d'AWS Load Balancer Controller, vous devez ajouter des identifications aux sous-réseaux.

Si vous n'avez pas spécifié d'ID de sous-réseau dans vos annotations de service ou d'entrée, assurez-vous que vos sous-réseaux utilisent les identifications requises pour la détection automatique de sous-réseaux. Pour plus d'informations, consultez la page Détection automatique de sous-réseaux sur le site Web de GitHub.

Pour un sous-réseau privé, utilisez les identifications suivantes :

• Clé : "kubernetes.io/role/internal-elb"
• Valeur : "1"

Pour les sous-réseaux publics, ajoutez les identifications suivantes :

• Clé : "kubernetes.io/role/elb"
• Valeur : "1"

Vérifier les annotations de l'objet d’entrée ou de service

Assurez-vous que les annotations sur l'objet de service ou l'objet d'entrée sont correctes.

Remarque : Dans les commandes suivantes, remplacez SERVICE-NAME, INGRESS-NAME et NAMESPACE par vos valeurs.

Pour consulter l’objet de service, exécutez la commande suivante :

kubectl describe service SERVICE-NAME -n NAMESPACE

Pour consulter l’objet d'entrée, exécutez la commande suivante :

kubectl describe ingress INGRESS-NAME -n NAMESPACE

Pour modifier l’objet de service, exécutez la commande suivante :

kubectl edit service SERVICE-NAME -n NAMESPACE

Pour modifier l'objet d'entrée, exécutez la commande suivante :

kubectl edit ingress INGRESS-NAME -n NAMESPACE

Les autres annotations utilisent des valeurs par défaut. Pour obtenir la liste des annotations prises en charge par AWS Load Balancer Controller pour les Application Load Balancers, consultez la page Annotations d’entrée sur le site Web de GtHub. Pour obtenir la liste des annotations prises en charge pour les Network Load Balancers, consultez la page Annotations de service sur le site Web de GitHub.

Application Load Balancer

Dans les versions de Kubernetes antérieures à 1.18, les classes d'entrée utilisaient l'annotation kubernetes.io/ingress.class qui fait référence au nom du contrôleur d'entrée. Les classes d'entrée de toutes les versions ultérieures de Kubernetes utilisent l'annotation ingressClassName qui fait référence à la ressource de classe d'entrée.

Pour plus d'informations, consultez la page Annotation kubernetes.io/ingress.class obsolète sur le site Web de GitHub.

Network Load Balancer

Utilisez les annotations suivantes :

• Avec des cibles IP, utilisez service.beta.kubernetes.io/aws-load-balancer-type: "external" et service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip".
• Avec des cibles d’instance, utilisez service.beta.kubernetes.io/aws-load-balancer-type: "external" et service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "instance".

Résoudre les problèmes liés à la création de l'équilibreur de charge de type entrée ou service dans Amazon EKS

**Vous recevez l'erreur « AccessDenied » **

Le message d’erreur suivant s’affiche :

« Failed deploy model due to AccessDenied »

Cette erreur se produit car l'autorisation elasticloadbalancing:AddTags pour créer des ressources a changé. Pour résoudre le problème, associez la dernière politique de Gestion des identités et des accès AWS (AWS IAM) au rôle AWSLoadBalancerController. Pour obtenir la dernière politique, consultez la page Politique JSON IAM sur le site Web de GitHub.

Pour plus d'informations, consultez la section Créer un rôle IAM à l'aide d'eksctl.

L'équilibreur de charge n'est pas pris en charge dans la zone de disponibilité

Si vous spécifiez un sous-réseau dans une zone de disponibilité limitée, un message d'erreur similaire au suivant peut s’afficher :

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

Pour résoudre ce problème, spécifiez un sous-réseau dans une autre zone de disponibilité qui n'est pas limitée. Utilisez ensuite l'équilibrage de charge entre zones pour répartir le trafic sur les cibles situées dans la zone de disponibilité limitée.

Pour utiliser différents sous-réseaux, ajoutez l’identification kubernetes.io/role/internal-elb=1 pour les sous-réseaux que vous utilisez pour créer un Network Load Balancer interne. Pour plus d'informations, consultez la section Identifier un Network Load Balancer.

Vous pouvez également ajouter l'annotation suivante pour spécifier les sous-réseaux dans le fichier manifeste du service :

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

Remarque : Remplacez subnet-xxxx par votre ID de sous-réseau et mySubnet par le nom de votre sous-réseau.

Il n’est pas possible d’utiliser la détection automatique des sous-réseaux

Si vous n’identifiez pas vos sous-réseaux pour la détection automatique, le message d'erreur suivant peut s'afficher :

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

AWS Load Balancer Controller détecte automatiquement les sous-réseaux du réseau par défaut. Pour les Application Load Balancers, vous devez disposer d'au moins deux sous-réseaux dans différentes zones de disponibilité. Un Application Load Balancer ne nécessite qu'un seul sous-réseau.

Pour que la détection automatique fonctionne, vous devez appliquer les identifications appropriées à vos sous-réseaux. Le contrôleur sélectionne un sous-réseau dans chaque zone de disponibilité. Si une zone de disponibilité comporte plusieurs sous-réseaux identifiés, le contrôleur n'en choisit qu'un en fonction des ID de sous-réseau alphabétiques.

Pour plus d'informations sur les identifications de sous-réseau requises pour les sous-réseaux privés et publics, consultez la page Détection automatique de sous-réseaux sur le site Web de GitHub.

Un problème de configuration du gestionnaire de certificats ou du webhook est survenu

Si la validation de votre webhook échoue, le message d'erreur suivant peut s'afficher :

« 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 »

Cette erreur survient en présence de problèmes liés aux certificats gérés par AWS Certificate Manager (ACM) pour vos webhooks.

Pour résoudre ce problème, vérifiez si les pods Certificate Manager sont exécutés.

Pour obtenir l'état du pod, exécutez la commande suivante :

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

Pour collecter des journaux, exécutez la commande suivante :

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

Remarque : Dans les commandes précédentes, remplacez your-pod-name par le nom de votre pod et your-namespace par le nom de votre espace de noms.

La création de la liaison du groupe cible a échoué

Si la création de la liaison de votre groupe cible échoue, le message d'erreur suivant peut s'afficher :

« 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 »

Cette erreur se produit lorsque des restrictions de groupe de sécurité bloquent l'accès au service webhook. Le service utilise le port 9443 par défaut.

Pour résoudre ce problème, modifiez le groupe de sécurité de votre nœud. Autorisez le trafic entrant depuis le groupe de sécurité du plan de contrôle sur le port 9443. Pour plus d'informations, consultez la page Options de configuration du contrôleur sur le site Web de GitHub.

AssumeRoleWithWebIdentity a échoué pour le rôle de nœud

Si votre rôle de nœud ne peut pas assumer le rôle que vous avez spécifié dans le compte de service, le message d'erreur suivant peut s'afficher :

« 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 »

Cette erreur se produit car vous avez incorrectement configuré les rôles IAM pour les comptes de service (IRSA).

Pour résoudre ce problème, utilisez le rôle approprié dans le compte de service et définissez une politique d’approbation pour ce rôle.

Pour plus d'informations, consultez les sections Pourquoi l'erreur « WebIdentityErr » s'affiche-t-elle lorsque j'utilise AWS Load Balancer Controller dans Amazon EKS ? et Comment résoudre les problèmes liés à un fournisseur OIDC et à IRSA dans Amazon EKS ?

Les données sont insuffisantes dans les journaux du pod de contrôleur

Si vous nécessitez de plus d'informations de débogage que celles fournies dans les journaux du pod de contrôleur par défaut, ajoutez l'indicateur --log-level debug à la configuration de votre pod de contrôleur.

Pour plus d'informations, consultez la page Indicateurs de ligne de commande du contrôleur sur le site Web de GitHub.

Consulter les journaux du pod d'AWS Load Balancer Controller pour des informations supplémentaires

Pour consulter les journaux d'AWS Load Balancer Controller, exécutez la commande suivante :

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

En cas de problème, l’erreur « Reconciler » s’affiche. Un message d'erreur détaillé expliquant pourquoi la création ou la mise à jour d'un objet d’entrée ou d'un service d’équilibrage de charge échoue s'affiche également.

Ce problème peut se produire pour les raisons suivantes :

• Si l'erreur se produit lorsque le contrôleur essaie d'effectuer des appels API AWS, cela signifie qu’un problème d'autorisation ou de connectivité est survenu. Examinez les autorisations IAM du contrôleur. Assurez-vous ensuite que les groupes de sécurité ou les listes de contrôle d'accès au réseau (ACL réseau) ne rejettent pas explicitement les connexions sortantes.
• Si l'erreur se produit dans la configuration de l'objet, cela signifie que vous avez incorrectement configuré la spécification ou les annotations d'entrée ou de service. Vérifiez les annotations relatives à l'Application Load Balancer ou au Network Load Balancer sur le site Web de GitHub.

Si aucun des pods de contrôleur n'affiche de journal, exécutez la commande suivante pour confirmer que les pods de contrôleur sont exécutés :

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

Effectuer une mise à niveau vers une version de contrôleur prise en charge

Si vous utilisez une version d'AWS Load Balancer Controller qui n'est plus prise en charge, vous ne pourrez pas migrer vers une version ultérieure. À la place, vous devez supprimer le contrôleur existant, puis installer la dernière version.

Utiliser AWS Load Balancer Controller plutôt que l'ancien fournisseur de cloud

Kubernetes inclut un ancien fournisseur de cloud pour AWS qui peut fournir des Classic Load Balancers. Si vous n'installez pas AWS Load Balancer Controller, Kubernetes utilise l'ancien fournisseur de cloud. Cependant, il est recommandé d'utiliser AWS Load Balancer Controller.

AWS Load Balancer Controller version 2.5 et versions ultérieures est le contrôleur par défaut pour les ressources de service Kubernetes avec le type LoadBalancer. Ils créent un Network Load Balancer pour chaque service. Les dernières versions implémentent également un webhook en mutation pour les services. Ils ont défini le champ spec.loadBalancerClass sur service.k8s.aws/nlb pour le nouveau type Services LoadBalancer.

Pour effectuer une mise à niveau vers AWS Load Balancer Controller, exécutez la commande suivante :

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

Remarque : Remplacez CLUSTER-NAME par le nom de votre cluster :

Si vous devez utiliser l'ancien fournisseur de cloud, définissez la valeur du graphique Helm enableServiceMutatorWebhook sur faux afin de ne pas fournir de nouveaux Classic Load Balancers. Seuls les Classic Load Balancers existants continuent de fonctionner.

Vérifier qu'un profil Fargate est créé pour l'espace de noms dans lequel se trouve l'objet d’entrée ou de service

Lorsque les pods cibles s'exécutent sur AWS Fargate, vous devez inclure le type de cible IP. Pour vérifier que vous avez un profil Fargate pour l'espace de noms dans lequel se trouve l'objet d’entrée ou de service, exécutez la commande suivante :

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

Remarque : Remplacez CLUSTER-NAME par le nom de votre cluster.

Pour créer un profil Fargate, exécutez la commande suivante :

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

Remarque : Remplacez CLUSTER-NAME, REGION, FARGATE-PROFILE-NAME et NAMESPACE par vos valeurs.

Vérifier que vous remplissez les conditions requises pour acheminer le trafic

Pour vous assurer de répondre à toutes les exigences, consultez les sections Prérequis pour les Application Load Balancers et Prérequis pour les Network Load Balancers. Par exemple, si vous utilisez un Application Load Balancer, l'objet de service doit spécifier le NodePort ou le LoadBalancer pour utiliser le mode trafic d'instance.

Amazon EKS ajoute les règles suivantes au groupe de sécurité du nœud :

• Une règle entrante pour le trafic client
• Une règle entrante pour chaque sous-réseau d'équilibreur de charge du VPC pour chaque Network Load Balancer que vous créez pour les surveillances de l'état

Si les règles ajoutées par Amazon EKS amènent votre groupe de sécurité à dépasser le nombre maximum de règles, le déploiement de votre équilibreur de charge peut échouer.