Comment puis-je résoudre un problème d’échec de surveillance de l’état d’un équilibreur de charge dans Amazon EKS ?

Résolution

Pour résoudre les problèmes liés à la surveillance de l’état de l’équilibreur de charge dans Amazon EKS, procédez comme indiqué dans les sections suivantes.

Vérifier le statut du pod

Vérifiez si le pod présente le statut En cours d’exécution et si les conteneurs qui se trouvent à l’intérieur des pods sont prêts :

$ kubectl get pod -n YOUR_NAMESPACE

Remarque : remplacez YOUR_NAMESPACE par votre espace de noms Kubernetes.

Exemple de sortie :

NAME                           READY   STATUS    RESTARTS   AGEpodname                        1/1     Running   0          16s

Si le conteneur d’applications dans le statut du pod n’indique pas En cours d’exécution, la surveillance de l’état de l’équilibreur de charge n’obtient pas de réponse et échoue.

Vérifier les sélecteurs d’étiquettes de pod et de service

Pour les étiquettes de pod, exécutez la commande suivante :

$ kubectl get pod -n YOUR_NAMESPACE --show-labels

Exemple de sortie :

NAME                           READY   STATUS    RESTARTS   AGE     LABELSalb-instance-6cc5cd9b9-prnxw   1/1     Running   0          2d19h   app=alb-instance,pod-template-hash=6cc5cd9b9

Pour vous assurer que votre service Kubernetes utilise les étiquettes de pod, exécutez la commande suivante afin de vérifier que la sortie correspond aux étiquettes de pod :

$ kubectl get svc SERVICE_NAME -n YOUR_NAMESPACE -o=jsonpath='{.spec.selector}{"\n"}'

Remarque : remplacez SERVICE_NAME par votre service Kubernetes et YOUR_NAMESPACE par votre espace de noms Kubernetes.

Exemple de sortie :

{"app":"alb-instance"}

Vérifier les points de terminaison manquants

Le contrôleur Kubernetes du sélecteur de service recherche en permanence les pods correspondant à son sélecteur, puis publie des mises à jour sur un objet de point de terminaison. Si vous avez sélectionné une étiquette incorrecte, aucun point de terminaison n’apparaît.

Exécutez la commande suivante :

$ kubectl describe svc SERVICE_NAME -n YOUR_NAMESPACE

Exemple de sortie :

Name:                     alb-instanceNamespace:                default
Labels:                   <none>
Annotations:              <none>
Selector:                 app=alb-instance-1      
Type:                     NodePort
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.100.44.151
IPs:                      10.100.44.151
Port:                     http  80/TCP
TargetPort:               80/TCP
NodePort:                 http  32663/TCP
Endpoints:                <none>                 
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

Vérifiez s’il manque un point de terminaison :

$ kubectl get endpoints SERVICE_NAME -n YOUR_NAMESPACE

Exemple de sortie :

NAME           ENDPOINTS                                AGEalb-instance   <none>                                   2d20h

Vérifier la politique de trafic de service et les groupes de sécurité de cluster pour détecter les problèmes liés aux Application Load Balancers

L’apparition de cibles défectueuses dans les groupes cibles des Application Load Balancers peut se produire pour deux raisons :

• La politique de trafic de service spec.externalTrafficPolicy est définie sur Local au lieu de Cluster.
• Différents groupes de sécurité de cluster sont associés aux groupes de nœuds d’un cluster, et le trafic ne peut pas circuler librement entre les groupes de nœuds.

Vérifiez que la politique de trafic est configurée correctement :

$ kubectl get svc SERVICE_NAME -n YOUR_NAMESPACE -o=jsonpath='{.spec.externalTrafficPolicy}{"\n"}'

Exemple de sortie :

Local

Définissez le paramètre sur ** Cluster ** :

$ kubectl edit svc SERVICE_NAME -n YOUR_NAMESPACE

Vérifier les groupes de sécurité de cluster

Procédez comme suit :

1. Ouvrez la console Amazon EC2.
2. Sélectionnez l’instance saine.
3. Choisissez l’onglet Sécurité, puis vérifiez les règles d’entrée des groupes de sécurité.
4. Sélectionnez l’instance défectueuse.
5. Choisissez l’onglet Sécurité, puis vérifiez les règles d’entrée des groupes de sécurité.
   Si le groupe de sécurité de chaque instance est différent, vous devez modifier la règle d’entrée de sécurité dans la console de groupe de sécurité :
   Dans l’onglet Sécurité, sélectionnez l’ID du groupe de sécurité.
   Choisissez Modifier les règles entrantes pour modifier les règles d’entrée.
   Ajoutez des règles entrantes pour autoriser le trafic provenant des autres groupes de nœuds dans le cluster.

Vérifier que votre service est configuré pour targetPort

Votre targetPort doit correspondre au containerPort du pod vers lequel le service envoie le trafic.

Pour vérifier la configuration de votre targetPort, exécutez la commande suivante :

$ kubectl get svc  SERVICE_NAME -n YOUR_NAMESPACE -o=jsonpath="{.items[*]}{.metadata.name}{'\t'}{.spec.ports[].targetPort}{'\t'}{.spec.ports[].protocol}{'\n'}"

Exemple de sortie :

alb-instance    8080    TCP

Dans l’exemple de sortie, le targetPort est configuré sur 8080. Cependant, comme le containerPort est défini sur 80, vous devez configurer le targetPort sur 80.

Vérifier que votre AWS Load Balancer Controller dispose des autorisations requises

L’AWS Load Balancer Controller doit disposer des autorisations requises pour mettre à jour les groupes de sécurité afin d’autoriser le trafic de l’équilibreur de charge vers des instances ou des pods. Si le contrôleur ne dispose pas des autorisations requises, des erreurs apparaissent.

Vérifiez s’il y a des erreurs dans les journaux de déploiement de l’AWS Load Balancer Controller :

$ kubectl logs deploy/aws-load-balancer-controller -n kube-system

Vérifiez s’il y a des erreurs dans les journaux de chaque pod de contrôleur :

$ kubectl logs CONTROLLER_POD_NAME -n YOUR_NAMESPACE

Remarque : remplacez CONTROLLER_POD_NAME par le nom de votre pod de contrôleur et YOUR_NAMESPACE par votre espace de noms Kubernetes.

Vérifier les annotations d’entrée pour détecter les problèmes liés aux Application Load Balancer

En cas de problème avec l’Application Load Balancer, consultez les annotations d’entrée de Kubernetes :

$ kubectl describe ing INGRESS_NAME -n YOUR_NAMESPACE

Remarque : remplacez INGRESS_NAME par le nom de votre service Kubernetes Ingress et YOUR_NAMESPACE par votre espace de noms Kubernetes.

Exemple de sortie :

Name:             alb-instance-ingressNamespace:        default
Address:          k8s-default-albinsta-fcb010af73-2014729787.ap-southeast-2.elb.amazonaws.com
Default backend:  alb-instance:80 (192.168.81.137:8080)
Rules:
  Host          Path  Backends
  ----          ----  --------
  awssite.cyou
                /   alb-instance:80 (192.168.81.137:8080)
Annotations:    alb.ingress.kubernetes.io/scheme: internet-facing        
                kubernetes.io/ingress.class: alb                         
Events:
  Type    Reason                  Age                  From     Message
  ----    ------                  ----                 ----     -------
  Normal  SuccessfullyReconciled  25m (x7 over 2d21h)  ingress  Successfully reconciled

Pour trouver les annotations d’entrée spécifiques à votre cas d’utilisation, consultez la page Ingress annotations du site Web Kubernetes.

Vérifier les annotations Kubernetes Service pour détecter les problèmes liés aux Network Load Balancers

En cas de problème avec le Network Load Balancer, vérifiez les annotations Kubernetes Service :

$ kubectl describe svc SERVICE_NAME -n YOUR_NAMESPACE

Exemple de sortie :

Name:                     nlb-ipNamespace:                default
Labels:                   <none>
Annotations:              service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip              
                          service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing          
                          service.beta.kubernetes.io/aws-load-balancer-type: external                   
Selector:                 app=nlb-ip
Type:                     LoadBalancer
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.100.161.91
IPs:                      10.100.161.91
LoadBalancer Ingress:     k8s-default-nlbip-fff2442e46-ae4f8cf4a182dc4d.elb.ap-southeast-2.amazonaws.com
Port:                     http  80/TCP
TargetPort:               80/TCP
NodePort:                 http  31806/TCP
Endpoints:                192.168.93.144:80
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

Remarque : notez la valeur APPLICATION_POD_IP pour exécuter une commande de surveillance de l’état à une étape ultérieure.

Pour trouver les annotations Kubernetes Service spécifiques à votre cas d’utilisation, consultez la page Service annotations du site Web Kubernetes.

Tester la surveillance de l’état manuellement

Vérifiez l’adresse IP de votre pod d’application :

$ kubectl get pod -n YOUR_NAMESPACE -o wide

Exécutez un pod test pour tester manuellement la surveillance de l’état au sein du cluster :

$ kubectl run -n YOUR_NAMESPACE troubleshoot -it --rm --image=amazonlinux -- /bin/bash

Exécutez ensuite la surveillance de l’état HTTP : 

# curl -Iv APPLICATION_POD_IP/HEALTH_CHECK_PATH

Remarque : remplacez APPLICATION_POD_IP par votre adresse IP de pod d’application et HEALTH_CHECK_PATH par le chemin de surveillance de l’état du groupe cible de l’Application Load Balancer.

Exemple de commande :

# curl -Iv 192.168.81.137

Exemple de sortie :

* Trying 192.168.81.137:80...* Connected to 192.168.81.137 (192.168.81.137) port 80 (#0)
> HEAD / HTTP/1.1
> Host: 192.168.81.137
> User-Agent: curl/7.78.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Server: nginx/1.21.3
Server: nginx/1.21.3
< Date: Tue, 26 Oct 2021 05:10:17 GMT
Date: Tue, 26 Oct 2021 05:10:17 GMT
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 615
Content-Length: 615
< Last-Modified: Tue, 07 Sep 2021 15:21:03 GMT
Last-Modified: Tue, 07 Sep 2021 15:21:03 GMT
< Connection: keep-alive
Connection: keep-alive
< ETag: "6137835f-267"
ETag: "6137835f-267"
< Accept-Ranges: bytes
Accept-Ranges: bytes

<
* Connection #0 to host 192.168.81.137 left intact

Vérifiez le code de statut de la réponse HTTP. Si le code de statut de la réponse est 200 OK, cela signifie que votre application répond correctement au chemin de surveillance de l’état.

Si le code de statut de la réponse HTTP est 3xx ou 4xx, modifiez le chemin de la surveillance de l’état. L’annotation suivante envoie la réponse 200 OK :

alb.ingress.kubernetes.io/healthcheck-path: /ping

-ou-

Utilisez l’annotation suivante sur la ressource d’entrée pour ajouter une plage de codes de statut de réponse réussie à la surveillance de l’état :

alb.ingress.kubernetes.io/success-codes: 200-399

Pour les surveillances de l’état TCP, utilisez la commande suivante pour installer la commande netcat :

# yum update -y && yum install -y nc

Testez les surveillances de l’état TCP :

# nc -z -v APPLICATION_POD_IP CONTAINER_PORT_NUMBER

Remarque : remplacez APPLICATION_POD_IP par l’adresse IP de votre pod d’application et CONTAINER_PORT_NUMBER par le port de votre conteneur.

Exemple de commande :

# nc -z -v 192.168.81.137 80

Exemple de sortie :

Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 192.168.81.137:80.Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.

Vérifier la mise en réseau

Pour les problèmes de mise en réseau, vérifiez les points suivants :

• Les différents groupes de nœuds du cluster EKS peuvent communiquer librement entre eux.
• La liste de contrôle d’accès au réseau (ACL réseau) associée au sous-réseau sur lequel s’exécutent vos pods autorise le trafic provenant de la plage CIDR du sous-réseau de l’équilibreur de charge.
• L’ACL réseau associée à votre sous-réseau d’équilibreur de charge permet de renvoyer le trafic sur la plage de ports éphémères depuis le sous-réseau sur lequel les pods s’exécutent.
• La table de routage autorise le trafic local depuis l’intérieur de la plage CIDR du VPC.

Redémarrer le kube-proxy

Si le kube-proxy qui s’exécute sur chaque nœud ne fonctionne pas correctement, il se peut que le kube-proxy ne mette pas à jour les règles iptables pour le service et les points de terminaison. Redémarrez le kube-proxy pour le forcer à effectuer une nouvelle vérification et à mettre à jour les règles iptables :

kubectl rollout restart daemonset.apps/kube-proxy -n kube-system

Exemple de sortie :

daemonset.apps/kube-proxy restarted

Informations connexes

Comment puis-je configurer un Application Load Balancer via l’AWS Load Balancer Controller sur un groupe de nœuds Amazon EC2 dans Amazon EKS ?

Comment puis-je résoudre les problèmes liés aux équilibreurs de charge créés par le contrôleur de service Kubernetes dans Amazon EKS ?

Comment puis-je découvrir automatiquement les sous-réseaux utilisés par mon Application Load Balancer dans Amazon EKS ?