Comment dépanner les cibles défectueuses pour les Network Load Balancers dans Amazon EKS ?

Brève description

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

• La surveillance de l’état n'est pas correctement configurée. Pour résoudre ce problème, lancez manuellement la surveillance de l’état à partir d'une machine hôte qui s'exécute dans Amazon Virtual Private Cloud (Amazon VPC).
• Il y a une exception inattendue dans le pod. Pour résoudre ce problème, suivez les étapes de dépannage de la section de Résolution : Vérifiez s'il y a une exception inattendue dans de le pod.
• Un Network Load Balancer avec l’option externalTrafficPolicy est réglé sur Local (à partir du site web Kubernetes), avec un DNS Amazon VPC personnalisé sur les options DHCP définies. Pour résoudre ce problème, corrigez kube-proxy avec l'indicateur de remplacement du nom d'hôte.

Remarque : vous pouvez déterminer si le type de groupe cible est une adresse IP ou une instance en vérifiant si le service d'annotation service.beta.kubernetes.io/aws-load-balancer-nlb-target-type existe.

Résolution

Vérifier 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érifier que la surveillance de l’état est correctement configurée

Vérifiez quelles annotations Elastic Load Balancing (ELB) (à partir du site web de Kubernetes) sont configurées pour votre service :

`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.

Si les annotations précédentes ne sont pas correctement configurées, les cibles peuvent être défectueuses.

Lancer manuellement la surveillance de l’état à 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'adresse IP, exécutez la commande curl suivante :

curl -ivk pod_IP:pod_port

Remarque : remplacez pod_IP par l'adresse IP de votre pod, et pod_port par le port de votre pod.

Vérifier s'il y a une exception inattendue dans le pod

Type de cible d'instance

Vérifiez la spécification de service pour les annotations de configuration de la surveillance de l'état actuelles (sur le site web GitHub) :

kubectl get service service_name -o yaml

Assurez-vous s'il y a des points de terminaison pour vérifier qu’il existe des pods sous-jacents au service :

kubectl get endpoints service_name -o yaml

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

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

Remarque : remplacez pod_name par le nom de votre pod.

Vérifiez si les pods ont le statut En cours d'exécution :

kubectl get pod -o wide

Vérifiez le statut des pods pour vous assurer qu'ils sont en cours d'exécution sans aucun redémarrage :

kubectl get pods -o wide

S'il y a des redémarrages, collectez les journaux de l'espace pour en déterminer la cause :

kubectl logs pod_name
kubectl logs pod_name --previous

Connectez-vous à une machine hôte d'Amazon VPC sur laquelle vous pouvez communiquer avec le nœud.

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 de statut HTTP attendu, les pods backend ne renvoient pas non plus le code de statut HTTP attendu.

Utilisez la même machine hôte pour vous connecter à l'adresse IP du pod, et vérifiez si le pod 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’option externalTrafficPolicy du service (du site web Kubernetes) est définie sur Local, seuls les nœuds sur lesquels les pods backend du service sont exécutés sont considérés comme des cibles saines.

Type de cible d'adresse IP

Vérifiez la spécification de service pour les annotations de configuration de la surveillance de l'état actuelles (sur le site web GitHub) :

kubectl get service service_name -o yaml

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é.

Corriger kube-proxy avec l'indicateur de remplacement du nom d'hôte

Modifiez la commande de spécification du démon kube-proxy, args et env, avec :

---
spec:
  template:
    spec:
      containers:
      - name: kube-proxy
        command: [ "/bin/sh" ]
        args:
        - -c
        - |
          kube-proxy --v=2 --hostname-override=$(NODE_NAME) --config=/var/lib/kube-proxy-config/config
        env:
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: spec.nodeName

Pour les types de cibles d’instance, si l’option externalTrafficPolicy est définie sur Cluster ou Local, le paramètre d'entrée par défaut du groupe de sécurité du nœud pour NodePort est 0.0.0.0/0. En outre, lorsque l’option externalTrafficPolicy est définie sur Local, un NodePort de surveillance de l'état supplémentaire est configuré pour autoriser les plages d'adresses IP CIDR du sous-réseau.

Pour contrôler l'adresse IP source sur le groupe de sécurité du nœud pour NodePort, ajoutez loadBalancerSourceRanges dans la spécification et incluez les plages :

spec:
loadBalancerSourceRanges:
- "143.231.0.0/16"
- "xx.yy.zz.zz/24"

Remarque : si .spec.loadBalancerSourceRanges n'est pas défini, Kubernetes autorise le trafic de 0.0.0.0/0 vers les groupes de sécurité du nœud. Si les nœuds ont des adresses IP publiques, le trafic hors Network Load Balancer peut également atteindre toutes les instances des groupes de sécurité modifiés.

---