¿Cómo puedo solucionar los objetivos con un estado insatisfactorio para los equilibradores de carga de red en Amazon EKS?

Breve descripción

A continuación se explican los motivos más habituales por los que los destinos de su equilibrador de carga de red pueden no tener un estado satisfactorio:

• La comprobación de estado está configurada de forma incorrecta.
• Hay una excepción inesperada en el pod.
• Un equilibrador de carga de red con externalTrafficPolicy configurado como local con un DNS de Amazon VPC personalizado en el conjunto de opciones de DHCP. 

Solución

Comprobación de si el grupo objetivo es una dirección IP o una instancia

Ejecute el siguiente comando:

kubectl get service service_name -o yaml

Nota: Reemplace service_name por el nombre del servicio.

Si la anotación service.beta.kubernetes.io/aws-load-balancer-nlb-target-type no está presente, el tipo de destino predeterminado es una instancia.

Verificación de si la comprobación de estado se ha configurado correctamente

Compruebe qué anotaciones de Elastic Load Balancing (ELB) se han configurado para su servicio. Para obtener más información sobre las anotaciones, consulte Servicio en el sitio web de Kubernetes.

Ejecute el siguiente comando para obtener una lista de anotaciones:

kubectl get service service_name -o yaml

Resultado del ejemplo:

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 las anotaciones están configuradas de forma incorrecta, es posible que los objetivos no estén en buen estado.

Inicio manual la comprobación de estado desde una máquina host que se ejecuta en la Amazon VPC

En el caso de los tipos de destino de instancias, ejecute el siguiente comando curl con NodePort:

curl-ivk node_IP:NodePort

Nota: Reemplace node_IP por la dirección IP del nodo.

En el caso de los tipos de destino de direcciones IP, ejecute el siguiente comando curl:

curl -ivk pod_IP:pod_port

Nota: Reemplace pod_IP por la dirección IP de su pod. Reemplace pod_port por el nombre del puerto en el que la aplicación escucha dentro del contenedor.

Comprobación de si hay alguna excepción inesperada en el pod

Tipo de destino de instancia

1. Consulte la especificación del servicio para ver las anotaciones actuales sobre la configuración de la comprobación de estado. Para obtener una lista completa, consulte las anotaciones sobre la configuración de la comprobación de estado en el sitio web de GitHub:

   kubectl get service service_name -o yaml

2. Compruebe si hay puntos de enlace para verificar si hay pods tras el servicio:

   kubectl get endpoints service_name -o yaml

3. Si no existen puntos de enlace para el servicio, compruebe que las etiquetas del pod y las de servicio coincidan:

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

   Nota: Reemplace pod_name por el nombre de pod.

4. Compruebe si los pods se encuentran en el estado En ejecución:

   kubectl get pod -o wide

5. Compruebe los estados de los pods para verificar si se pueden ejecutar sin necesidad de reiniciarlos:

   kubectl get pods -o wide

6. Si se producen reinicios, recopile los registros del pod para averiguar la causa:

   kubectl logs pod_namekubectl logs pod_name --previous

7. Inicie sesión en una máquina host en la Amazon VPC donde pueda comunicarse con el nodo. Luego, use el comando curl con NodePort para comprobar si los pods devuelven el código de estado HTTP esperado:

   curl node_IP:NodePort

   Si el comando curl no ha devuelto el código de estado HTTP esperado, los pods del backend no devolverán el código de estado HTTP esperado.

8. Utilice la misma máquina host para conectarse a la dirección IP del pod y comprobar si el pod se ha configurado correctamente:

   curl pod_IP:pod_port

   Si el comando curl no ha devuelto el código de estado HTTP esperado, significa que el pod no se ha configurado correctamente.

Nota: Si externalTrafficPolicy del servicio (del sitio web de Kubernetes) se ha definido como Local, se considerará que solo los nodos en los que se ejecutan los pods de backend del servicio son objetivos en buen estado.

Tipo de destino de dirección IP

1. Consulte la especificación del servicio para ver las anotaciones actuales sobre la configuración de la comprobación de estado. Para obtener una lista, consulte las anotaciones sobre la configuración de la comprobación de estado en el sitio web de GitHub.

   kubectl get service service_name -o yaml

2. Inicie sesión en una máquina host en la Amazon VPC y utilice el comando curl para comunicarse con la dirección IP del pod:

   curl pod_IP:pod_port

   Si el comando curl no ha devuelto el código de estado HTTP esperado, significa que el pod no se ha configurado correctamente.