Comment résoudre les erreurs d'AWS Load Balancer Controller dans Amazon EKS ?

Résolution

Erreurs de création d'objets d'entrée

Si vous essayez de créer un objet d'entrée et que vous n'avez pas configuré correctement le service Webhook ou que le certificat de service a expiré, l'un des messages d'erreur suivants alors peut s'afficher :

« Erreur du serveur (InternalError) : erreur lors de la création de « sample.yaml » : Une erreur interne s'est produite : échec de l'appel du webhook « mservice.elbv2.k8s.aws » : échec de l'appel du webhook : Publiez « https://aws-load-balancer-webhook-service.default.svc:443/mutate-v1-service?timeout=10s » : aucun point de terminaison disponible pour le service « aws-load-balancer-webhook-service » »

« Une erreur interne s'est produite : échec de l'appel au webhook « vingress.elbv2.k8s.aws » : Publiez « https://aws-load-balancer-webhook-service.kube-system.svc:443/validate-networking-v1beta1-ingress?timeout=10s » : x509 : le certificat a expiré ou n'est pas encore valide »

Pour résoudre ces problèmes, vérifiez l'état du déploiement d'AWS Load Balancer Controller, vérifiez les configurations de service et validez les dates d'expiration des certificats.

Pour identifier la CA racine et résoudre l'erreur, procédez comme suit :

1. Exécutez la commande suivante pour vérifier que les pods aws-load-balancer s'exécutent correctement :

   kubectl get pods -n kube-system | grep aws-load-balancer

   Exemple de sortie :

   aws-load-balancer-controller-df9b89cf7-hbsrd    1/1       Running    0    26d

2. Exécutez la commande suivante pour confirmer que aws-load-balancer-webhook-service existe et que le point de terminaison existe pour aws-load-balancer :

   kubectl get svc -n kube-system

   Exemple de sortie :

   NAME TYPE                           CLUSTER-IP                EXTERNAL-IP  PORT(S)    AGE
   aws-load-balancer-webhook-service   ClusterIP 10.100.219.187  "none"       443/TCP    86d

   Dans la sortie, vérifiez que aws-load-balancer-webhook-service est répertorié et vérifiez que vous avez attribué une adresse CLUSTER-IP valide. Vérifiez que le PORT indique 443/TCP pour la communication du webhook.

3. Exécutez la commande suivante pour vérifier que vous avez correctement connecté les services :

   kubectl get ep -n kube-system

   Exemple de sortie :

   NAME                                ENDPOINTS          AGE
   aws-load-balancer-webhook-service   172.31.3.28:9443    86d

   Remarque : Dans la sortie, vérifiez que le aws-load-balancer-webhook-service possède une valeur ENDPOINTS. Le port de point de terminaison doit comporter 9443 pour indiquer que le service Webhook est correctement configuré.

4. Exécutez la commande suivante pour vérifier si le certificat a expiré :

   kubectl get secret -n kube-system aws-load-balancer-webhook-tls -ojsonpath="{.data.ca\.crt}" | base64 -d | openssl x509 -noout -text

   Exemple de sortie :

   Validity
           Not Before: [START_DATE]
           Not After : [END_DATE]

   Remarque : Vérifiez que la date courante se situe entre les dates Pas avant et Pas après. Si la date Pas après est dépassée, le certificat a expiré.

5. (Facultatif) Si le certificat est expiré, exécutez alors la commande suivante :

   kubectl apply  --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v1.13.5/cert-manager.yaml

Si les problèmes persistent, réinstallez alors AWS Load Balancer Controller pour résoudre les problèmes liés à la configuration des webhooks, aux points de terminaison de service ou à la gestion des certificats. Désinstallez l'installation actuelle d'AWS Load Balancer Controller, puis réinstallez AWS Load Balancer Controller avec Helm.

Remarque : Si vous supprimez AWS Load Balancer Controller, il ne supprime pas l'objet d'entrée.

Les cibles ne s'enregistrent pas pour les erreurs de Network Load Balancer ou d'Application Load Balancer

Si les cibles n'enregistrent pas l'existence d'un Network Load Balancer ou d'un Application Load Balancer, il est alors possible qu'une erreur s'affiche même si vous avez installé AWS Load Balancer Controller et que le service est déployé.

Exécutez la commande suivante pour vérifier si la liaison au groupe cible existe :

kubectl get targetgroupbinding -A

Si la liaison au groupe cible existe, vérifiez alors la configuration du réseau pour vous assurer que la communication est ouverte entre les cibles et l'ELB.

Si la liaison au groupe cible n'existe pas, créez-en alors une.

Exemple :

apiVersion: elbv2.k8s.aws/v1beta1
kind: TargetGroupBinding
metadata:
  name: red-tgb
  namespace: red-ns
spec:
  serviceRef:
    name: red-service
    port: 80
  targetGroupARN: arn:aws:elasticloadbalancing:region:account-id:targetgroup/target-group-name/target-group-id

Remarque : Remplacez region par la région AWS. Remplacez account-id par l'ID du compte AWS. Remplacez target-group-name par le nom du groupe cible. Remplacez target-group-id par l'ID du groupe cible.

Problèmes de connectivité avec le service Webhook

Erreurs de définition de ressources personnalisées

L'AWS Load Balancer Controller doit disposer des définitions de ressources personnalisées (CRD) requises pour le service Webhook. Pour plus d'informations, consultez Ressources personnalisées sur le site Web de Kubernetes. Si vous essayez de vous connecter sans les CRD requis, un message d'erreur semblable au suivant peut alors s'afficher :

« Erreur du serveur (InternalError) : erreur lors de la création de « targetgroupbinding.yaml » : Une erreur interne s'est produite : échec de l'appel au webhook « mtargetgroupbinding.elbv2.k8s.aws » :
Impossible d'appeler le webhook : Publiez « https://aws-load-balancer-webhook-service.kube-system.svc:443/mutate-elbv2-k8s-aws-v1beta1-targetgroupbinding?timeout=30s » :
net/http demande annulée pendant l'établissement de la connexion (Client.Timeout dépassé lors de l'attente des en-têtes) »

Pour résoudre ce problème, exécutez la commande suivante pour confirmer que vous avez installé des CRD dans le cluster :

kubectl get crds | grep target

Exemple de sortie :

targetgroupbindings.elbv2.k8s.aws 2023-11-29T14:40:39Z

Si la sortie est vide, cela signifie que les CRD ne sont pas correctement installés sur le cluster. Pour installer les CRD, exécutez la commande suivante :

kubectl apply -f https://raw.githubusercontent.com/aws/eks-charts/master/stable/aws-load-balancer-controller/crds/crds.yaml

Valider la connectivité interne avec le service Webhook

Il est recommandé d'autoriser la communication entre les composants master. Cependant, les groupes de sécurité peuvent avoir des règles restrictives qui empêchent la communication avec le service Webhook.

Pour que l'AWS Load Balancer Controller puisse créer et modifier des ressources, celles-ci doivent être en mesure de communiquer avec le service. Pour autoriser cette communication, vérifiez que le groupe de sécurité des composants master contient les règles suivantes.

Règles entrantes :

Port        Source                            
443         worker-node-security-group-id

Remarque : Remplacez worker-node-security-group-id par l'ID du groupe de sécurité.

Règles sortantes :

Port        Destination                            
443         worker-node-security-group-id

Remarque : Remplacez worker-node-security-group-id par l'ID du groupe de sécurité.

Valider la connectivité entre les composants master et le service ELB

Le point de terminaison d'un VPC permet la communication entre les composants master AWS Load Balancer Controller et les points de terminaison du service ELB. Si le cluster Amazon EKS privé n'a pas accès à Internet, vous devez alors configurer un point de terminaison d'un cloud privé virtuel (VPC).

Les points de terminaison d'un VPC créent également une interface réseau élastique que vous pouvez associer à un groupe de sécurité. Assurez-vous que le groupe de sécurité qui est attaché au point de terminaison d'un VPC contient la règle d'entrée suivante :

Port        Source                        
443         worker-node-security-group-id   

Remarque : Remplacez worker-node-security-group-id par l'ID du groupe de sécurité.

Erreurs de paramètre CreateTargetGroupInput.Port non valides

Par défaut, le contrôleur crée Application Load Balancer en mode Instance. Le mode Instance est compatible avec les services NodePort, mais peut entrer en conflit, car le mode Instance nécessite une allocation de port de nœud. Pour plus d'informations, consultez Annotations d'entrée sur le site Web de Kubernetes. Si l'allocation de port entraîne des échecs de création de groupes cibles, le message d'erreur suivant peut alors s'afficher :

« Échec du modèle de déploiement en raison de InvalidParameter : 1 erreur (s) de validation trouvée (s). - valeur de champ minimale de 1, CreateTargetGroupInput.Port. »

Pour résoudre ce problème, procédez comme suit pour sélectionner le mode approprié pour Application Load Balancer :

Pour le mode Instance, procédez comme suit :

1. Configurez le type comme NodePort :

   apiVersion: v1
   kind: Service
   metadata:
     name: service-name
     namespace: namespace-name
   spec:
     type: NodePort
     ports:
       - protocol: TCP
         port: 80
         targetPort: 80

   Remarque : Remplacez service-name par le nom du service et namespace-name par le nom de l'espace de noms.
2. Créez l'entrée avec le mode Instance :

   alb.ingress.kubernetes.io/target-type: instance

Pour le mode IP, procédez comme suit :

1. Configurez le type en tant que ClusterIP :

   apiVersion: v1
   kind: Service
   metadata:
     name: service-name
     namespace: namespace-name
   spec:
     type: ClusterIP
     ports:
       - protocol: TCP
         port: 80
         targetPort: 80

   Remarque : Remplacez service-name par le nom du service et namespace-name par le nom de l'espace de noms.
2. Ajoutez l'annotation suivante à l'entrée :

   alb.ingress.kubernetes.io/target-type: ip

Erreurs d'installation d'AWS Load Balancer Controller

Si vous installez AWS Load Balancer Controller et que le manifeste ne possède pas les autorisations correctes, un message d'erreur similaire au suivant peut alors s'afficher :

« Échec de l'avertissement 8s (x8 sur 88s) kubelet Erreur : le conteneur comprend runAsNonRoot et l'image sera exécutée en tant que racine (pod : « aws-load-balancer-controller-5c6c66fc48-49rm4_kube-system(924608a2-da7a-4786-ae74-051bb47ea84e) », conteneur : contrôleur) »

Pour résoudre cette erreur, procédez comme suit :

1. Exécutez la commande suivante pour modifier le déploiement d’AWS Load Balancer Controller :

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

2. Dans la configuration de déploiement, localisez la section Conteneurs, puis ajoutez les paramètres securityContext suivants.
   Exemple de configuration :

   apiVersion: apps/v1
   kind: Deployment  
   spec:
     template:
       spec:
         containers:
         - name: aws-load-balancer-controller
           image: public.ecr.aws/eks/aws-load-balancer-controller:v2.13.3
           securityContext:  
             runAsNonRoot: true  
             runAsUser: 1000

Une fois que vous avez modifié le déploiement, de nouveaux pods se lancent avec les nouvelles valeurs de configuration.