Comment résoudre les problèmes liés aux cibles défectueuses pour les Network Load Balancers dans Amazon EKS ?

Brève description

Les raisons courantes pour lesquelles les cibles de votre Network Load Balancer ne sont pas saines sont les suivantes :

• La surveillance de l’état n'est pas configurée correctement.
• Il y a une exception inattendue dans le pod.
• Un Network Load Balancer dont le paramètre ExternalTrafficPolicy est défini sur local avec un DNS Amazon VPC personnalisé dans les options DHCP définies. 

Résolution

Vérifiez si le groupe cible est une adresse IP ou une instance

Exécutez la commande suivante :

kubectl get service service_name -o yaml

Remarque : Remplacez service_name par le nom de votre service.

Si l'annotation service.beta.kubernetes.io/aws-load-balancer-nlb-target-type n'est pas présente, le type de cible par défaut est une instance.

Vérifiez que la surveillance de l’état est correctement configurée

Vérifiez quelles annotations Elastic Load Balancing (ELB) sont configurées pour votre service. Pour plus d'informations sur les annotations, consultez la section Service sur le site Web de Kubernetes.

Exécutez la commande suivante pour obtenir la liste des annotations :

kubectl get service service_name -o yaml

Exemple de sortie :

service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold: "2"# The number of successive successful health checks required for a backend to be considered healthy for traffic. Defaults to 2, must be between 2 and 10

service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold: "3"
# The number of unsuccessful health checks required for a backend to be considered unhealthy for traffic. Defaults to 6, must be between 2 and 10

service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "20"
# The approximate interval, in seconds, between health checks of an individual instance. Defaults to 10, must be between 5 and 300

service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: "5"
# The amount of time, in seconds, during which no response means a failed health check. This value must be less than the service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval value. Defaults to 5, must be between 2 and 60

service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol: TCP
service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: traffic-port
# can be integer or traffic-port

service.beta.kubernetes.io/aws-load-balancer-healthcheck-path: "/"
# health check path for HTTP(S) protocols

Si les annotations ne sont pas correctement configurées, les cibles peuvent ne pas être saines.

Lancez manuellement la surveillance de santé à partir d'une machine hôte qui s'exécute dans Amazon VPC

Pour les types de cibles d'instance, exécutez la commande curl suivante avec NodePort :

curl-ivk node_IP:NodePort

Remarque : Remplacez node_IP par l'adresse IP de votre nœud.

Pour les types de cibles d'adresses IP, exécutez la commande curl suivante :

curl -ivk pod_IP:pod_port

Remarque : Remplacez pod_IP par l'adresse IP de votre pod. Remplacez pod_port par le nom du port sur lequel l'application écoute à l'intérieur du conteneur.

Vérifier la présence d'une exception inattendue dans le pod

Type de cible d'instance

1. Consultez les spécifications du service pour les annotations de configuration actuelles de la surveillance de l’état. Pour une liste complète, consultez les annotations de configuration de la surveillance de l’état sur le site Web GitHub :

   kubectl get service service_name -o yaml

2. Vérifier s'il existe des points de terminaison pour vérifier qu'il existe des pods derrière le service :

   kubectl get endpoints service_name -o yaml

3. S'il n'existe aucun point de terminaison pour le service, vérifiez que les étiquettes des pods et des services correspondent :

   kubectl describe servicekubectl describe pod pod_name or kubectl get pod --show-labels

   Remarque : Remplacez pod_name par le nom de votre pod.

4. Vérifiez si les pods ont le statut En cours d’exécution :

   kubectl get pod -o wide

5. Vérifiez le statut des pods pour vous assurer qu'ils peuvent fonctionner sans aucun redémarrage :

   kubectl get pods -o wide

6. S'il y a des redémarrages, collectez les journaux du pod pour en déterminer la cause :

   kubectl logs pod_namekubectl logs pod_name --previous

7. Connectez-vous à une machine hôte dans Amazon VPC où vous pouvez communiquer avec le nœud. Ensuite, utilisez la commande curl avec NodePort pour vérifier si les pods renvoient le code de statut HTTP attendu :

   curl node_IP:NodePort

   Si la commande curl n'a pas renvoyé le code des statut HTTP attendu, les pods dorsaux ne renvoient pas le code de statut HTTP attendu.

8. Utilisez la même machine hôte pour vous connecter à l'adresse IP du pod et vérifier si celui-ci est correctement configuré :

   curl pod_IP:pod_port

   Si la commande curl n'a pas renvoyé le code de statut HTTP attendu, cela signifie que le pod n'est pas correctement configuré.

Remarque : Si l’optionexternalTrafficPolicy du service (depuis le site Web de Kubernetes) est définie sur Local, seuls les nœuds sur lesquels s'exécutent les pods dorsaux du service sont considérés comme des cibles saines.

Type de cible d'adresse IP

1. Consultez les spécifications du service pour les annotations de configuration actuelles de la surveillance de l’état. Pour obtenir une liste, consultez les annotations de configuration de la surveillance de l’état sur le site Web GitHub.

   kubectl get service service_name -o yaml

2. Connectez-vous à une machine hôte dans Amazon VPC et utilisez la commande curl pour communiquer avec l'adresse IP du pod :

   curl pod_IP:pod_port

   Si la commande curl n'a pas renvoyé le code de statut HTTP attendu, cela signifie que le pod n'est pas correctement configuré.