Comment résoudre un échec de surveillance de l'état d'un équilibreur de charge dans Amazon EKS ?

Brève description

Pour résoudre les problèmes de surveillance de l'état liés à l'équilibreur de charge dans votre Amazon EKS, suivez les étapes décrites dans les sections ci-dessous :

• Vérifiez l'état du pod
• Vérifiez les sélecteurs d'étiquettes de pod et de service
• Vérifiez les points de terminaison manquants
• Vérifiez la politique de trafic de service et les groupes de sécurité du cluster pour les Application Load Balancers
• Vérifiez que votre EKS est configuré pour leport cible
• Vérifiez que votre contrôleur AWS Load Balancer dispose des autorisations appropriées
• Vérifiez si les annotations d'entrée présentent des problèmes liés aux Application Load Balancers
• Vérifiez les annotations du service Kubernetes pour détecter les problèmes liés aux Network Load Balancers
• Testez manuellement une surveillance de l'état
• Vérifiez les réseaux
• Redémarrez le kube-proxy

Résolution

Vérifiez l'état du pod

Vérifiez si le pod est en état de fonctionnement et si les conteneurs situés dans les 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   AGE
podname                        1/1     Running   0          16s

Remarque : la surveillance de l'état de l'équilibreur de charge ne reçoit pas de réponse et échoue si le conteneur d'applications du pod ne fonctionne pas.

Vérifiez 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     LABELS
alb-instance-6cc5cd9b9-prnxw   1/1     Running   0          2d19h   app=alb-instance,pod-template-hash=6cc5cd9b9

Pour vérifier que votre service Kubernetes utilise les étiquettes de pod, exécutez la commande suivante afin de vérifier que sa 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érifiez les points de terminaison manquants

Le contrôleur Kubernetes pour le sélecteur de service recherche en permanence les pods correspondant à son sélecteur, puis publie les mises à jour d'un objet de point de terminaison. Aucun point de terminaison n'apparaît si vous sélectionnez une étiquette incorrecte.

Exécutez la commande suivante :

$ kubectl describe svc SERVICE_NAME -n YOUR_NAMESPACE

Exemple de sortie :

Name:                     alb-instance
Namespace:                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 si le point de terminaison est manquant :

$ kubectl get endpoints SERVICE_NAME -n YOUR_NAMESPACE

Exemple de sortie :

NAME           ENDPOINTS                                AGE
alb-instance   <none>                                   2d20h

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

Les cibles défectueuses des groupes cibles de l'Application Load Balancer se produisent pour deux raisons. Soit la politique de trafic de service, Spec.ExternalTrafficPolicy, est définie sur Local au lieu de Cluster. Soit, les groupes de nœuds d'un cluster sont associés à différents groupes de sécurité de cluster et le trafic ne peut pas circuler librement entre les groupes de nœuds.

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

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

Exemple de sortie :

Local

Changez le paramètre en Cluster :

$ kubectl edit svc SERVICE_NAME -n YOUR_NAMESPACE

Vérifiez les groupes de sécurité du cluster

1.    Ouvrez la console Amazon EC2.

2.    Sélectionnez l'instance saine.

3.    Cliquez sur l'onglet Sécurité et vérifiez les règles d'entrée du groupe de sécurité.

4.    Sélectionnez l'instance défectueuse.

5.    Cliquez sur l'onglet Sécurité et vérifiez les règles d'entrée du groupe de sécurité.

Si le groupe de sécurité de chaque instance est différent, vous devez alors modifier la règle d'entrée de sécurité dans la console du groupe de sécurité :

1.    Dans l'onglet Sécurité, sélectionnez l'ID du groupe de sécurité.

2.    Cliquez sur le bouton Modifier les règles de trafic entrant pour modifier les règles d'entrée.

3.    Ajoutez des règles de trafic entrant pour autoriser le trafic provenant des autres groupes de nœuds du cluster.

Vérifiez que votre service est configuré pour le port cible

Votre port cible doit correspondre au port conteneur du pod vers lequel le service envoie du trafic.

Pour vérifier la configuration de votre port cible, 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 précédent, le port cible est configuré sur 8080. Toutefois, puisque le port conteneur est défini sur 80, vous devez configurer le port cible sur 80.

Vérifiez que votre contrôleur AWS Load Balancer dispose des autorisations appropriées

Le contrôleur AWS Load Balancer doit disposer des autorisations appropriées pour mettre à jour les groupes de sécurité afin d'autoriser le trafic de l'équilibreur de charge vers les instances ou les pods. Des erreurs s'affichent si le contrôleur ne dispose pas des autorisations appropriées.

Vérifiez l'absence d'erreurs dans les journaux de déploiement du contrôleur AWS Load Balancer :

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

Vérifiez l'absence d'erreurs dans les journaux de pods de contrôleurs individuels :

$ 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érifiez si les annotations d'entrée présentent des problèmes liés aux Application Load Balancers

Pour les problèmes liés à l'Application Load Balancer, consultez les annotations d'entrée Kubernetes :

$ kubectl describe ing INGRESS_NAME -n YOUR_NAMESPACE

Remarque : Remplacez INGRESS_NAME par le nom de votre entrée Kubernetes et YOUR_NAMESPACE par votre espace de noms Kubernetes.

Exemple de sortie :

Name:             alb-instance-ingress
Namespace:        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 Annotations d'entrée (sur le site Web de Kubernetes).

Vérifiez les annotations du service Kubernetes pour détecter les problèmes liés aux Network Load Balancers

Pour les problèmes liés au Network Load Balancer, consultez les annotations du service Kubernetes :

$ kubectl describe svc SERVICE_NAME -n YOUR_NAMESPACE

Exemple de sortie :

Name:                     nlb-ip
Namespace:                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 : Prêtez attention au paramètre APPLICATION_POD_IP. Vous en aurez besoin pour exécuter une commande de surveillance de l'état.

Pour trouver les annotations de service Kubernetes spécifiques à votre cas d'utilisation, consultez Annotations de service (sur le site Web de Kubernetes).

Testez manuellement une surveillance de l'état

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

$ kubectl get pod -n YOUR_NAMESPACE -o wide

Exécutez un pod de test afin de tester manuellement une surveillance de l'état au sein du cluster des surveillances de l'état HTTP :

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

Pour les surveillances de l'état HTTP :

# curl -Iv APPLICATION_POD_IP/HEALTH_CHECK_PATH

Remarque : Remplacez APPLICATION_POD_IP par l'adresse IP de votre pod d'application et HEALTH_CHECK_PATH par le chemin de surveillance de l'état du groupe cible ALB.

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 d'état de la réponse HTTP. Si le code d'état de la réponse est 200 OK, cela signifie que votre application répond correctement sur le chemin de surveillance de l'état.

Si le code d'état de la réponse HTTP est 3xx ou 4xx, vous pouvez alors modifier votre chemin de surveillance de l'état. L'annotation suivante peut répondre avec 200 OK :

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

-ou-

Vous pouvez utiliser l'annotation suivante sur la ressource d'entrée pour ajouter une plage de codes d'état de la réponse à la surveillance de l'état réussie :

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 votre port 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érifiez les réseaux

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

• Les nombreux groupes de nœuds du cluster EKS peuvent communiquer librement entre eux
• La liste de contrôle d'accès 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 d'adresses CIDR du sous-réseau d'équilibreur de charge
• L'ACL réseau associée à votre sous-réseau d'équilibreur de charge doit autoriser le trafic retour sur la plage de ports éphémères à partir du sous-réseau sur lequel les pods s'exécutent
• La table de routage autorise le trafic local à partir de la plage d'adresses CIDR du VPC

Redémarrez le kube-proxy

La mise à jour des règles iptables des services et points de terminaison peut échouer si le comportement du kube-proxy s'exécutant sur chaque nœud est irrégulier. Redémarrez le kube-proxy pour le forcer à revérifier 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 faire pour configurer un Application Load Balancer à l'aide du contrôleur AWS Load Balancer sur un groupe de nœuds Amazon EC2 dans Amazon EKS ?

Comment puis-je dépanner les équilibreurs de charge de service pour Amazon EKS ?

Comment baliser les sous-réseaux Amazon VPC dans mon cluster Amazon EKS pour la découverte automatique de sous-réseau par des équilibreurs de charge ou des contrôleurs d'entrée ?

---