¿Cómo resuelvo una comprobación de estado fallida para un equilibrador de carga en Amazon EKS?

Descripción corta

Para solucionar problemas de comprobación de estado con el equilibrador de carga en su Amazon EKS, complete los pasos de las siguientes secciones:

• Verificar el estado del pod
• Verificar los selectores de etiquetas de servicio y pod
• Verificar si faltan puntos de conexión
• Verificar la política de tráfico de servicios y los grupos de seguridad del clúster para Application Load Balancers
• Verificar que su EKS esté configurado para targetPort
• Verificar que el controlador del equilibrador de carga de AWS tenga los permisos correctos
• Verificar las anotaciones de entrada en busca de problemas con Application Load Balancers
• Verificar las anotaciones del servicio de Kubernetes para ver si hay problemas con Network Load Balancers
• Probar una comprobación de estado de forma manual
• Verificar las redes
• Reiniciar el kube-proxy

Resolución

Verificar el estado del pod

Verifique si el pod está en estado Running (Ejecutando) y los contenedores de los pods están listos:

$ kubectl get pod -n YOUR_NAMESPACE

Nota: Sustituya YOUR_NAMESPACE por su espacio de nombres de Kubernetes.

Salida de ejemplo:

NAME                           READY   STATUS    RESTARTS   AGE
podname                        1/1     Running   0          16s

Nota: Si el contenedor de aplicaciones del pod no se está ejecutando, la comprobación de estado del equilibrador de carga no se responde y falla.

Verificar los selectores de etiquetas de servicio y pod

Para las etiquetas de pod, ejecute el siguiente comando:

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

Salida de ejemplo:

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

Para verificar que el servicio de Kubernetes utiliza las etiquetas de los pods, ejecute el siguiente comando para comprobar que el resultado coincide con las etiquetas de los pods:

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

Nota: Reemplace SERVICE_NAME por el servicio de Kubernetes y YOUR_NAMESPACE por el espacio de nombres de Kubernetes.

Salida de ejemplo:

{"app":"alb-instance"}

Verificar si faltan puntos de conexión

El controlador de Kubernetes para el selector de servicios busca continuamente pods que coincidan con su selector y, a continuación, publica actualizaciones en un objeto de punto de conexión. Si seleccionó una etiqueta incorrecta, no aparecerá ningún punto de conexión.

Ejecute el siguiente comando:

$ kubectl describe svc SERVICE_NAME -n YOUR_NAMESPACE

Salida de ejemplo:

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>

Verifique si falta el punto de conexión:

$ kubectl get endpoints SERVICE_NAME -n YOUR_NAMESPACE

Salida de ejemplo:

NAME           ENDPOINTS                                AGE
alb-instance   <none>                                   2d20h

Verificar la política de tráfico del servicio y los grupos de seguridad del clúster para detectar problemas con Application Load Balancers

Los objetivos en mal estado en los grupos de destino de Application Load Balancer ocurren por dos motivos. La política de tráfico del servicio,spec.externalTrafficPolicy, se establece en Local en lugar de en Clúster. O bien, los grupos de nodos de un clúster tienen diferentes grupos de seguridad de clúster asociados y el tráfico no puede fluir libremente entre los grupos de nodos.

Verifique que la política de tráfico esté configurada correctamente:

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

Salida de ejemplo:

Local

Cambie la configuración a Clúster:

$ kubectl edit svc SERVICE_NAME -n YOUR_NAMESPACE

Verificar los grupos de seguridad del clúster

1.    Abra la consola de Amazon EC2.

2.    Seleccione la instancia en buen estado.

3.    Elija la pestaña Security (Seguridad) y verifique las reglas de entrada del grupo de seguridad.

4.    Seleccione la instancia en mal estado.

5.    Elija la pestaña Security (Seguridad) y verifique las reglas de entrada del grupo de seguridad.

Si el grupo de seguridad de cada instancia es diferente, entonces debe modificar la regla de entrada de seguridad en la consola del grupo de seguridad:

1.    En la pestaña Security (Seguridad), seleccione el ID del grupo de seguridad.

2.    Pulse el botón Edit inbound rules (Editar reglas de entrada) para modificar las reglas de entrada.

3.    Agregue reglas de entrada para permitir el tráfico de los otros grupos de nodos del clúster.

Verificar que el servicio esté configurado para targetPort

targetPort debe coincidir con el containerPort del pod al que el servicio envía tráfico.

Para verificar para qué está configurado targetPort, ejecute el siguiente comando:

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

Salida de ejemplo:

alb-instance 8080 TCP

En el resultado del ejemplo anterior,targetPort está configurado en 8080. Sin embargo, dado que containerPort está establecido en 80, debe configurar targetPort en 80.

Verificar que el controlador del equilibrador de carga de AWS tenga los permisos correctos

El controlador de equilibrador de carga de AWS debe tener los permisos correctos para actualizar los grupos de seguridad y permitir el tráfico desde el equilibrador de carga a instancias o pods. Si el controlador no tiene los permisos correctos, entonces recibirá errores.

Verifique si hay errores en los registros de implementación de AWS Load Balancer Controller:

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

Verifique si hay errores en los registros individuales del pod del controlador:

$ kubectl logs CONTROLLER_POD_NAME -n YOUR_NAMESPACE

Nota: Reemplace CONTROLLER_POD_NAME por el nombre del pod del controlador y YOUR_NAMESPACE por su espacio de nombres de Kubernetes.

Verificar las anotaciones de entrada en busca de problemas con Application Load Balancers

Para problemas con Application Load Balancer, consulte las anotaciones de entrada de Kubernetes:

$ kubectl describe ing INGRESS_NAME -n YOUR_NAMESPACE

Nota: Reemplace INGRESS_NAME por el nombre de Ingress de Kubernetes y YOUR_NAMESPACE por su espacio de nombres de Kubernetes.

Salida de ejemplo:

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

Para encontrar anotaciones de entrada que sean específicas para el caso de uso, consulte Anotaciones de entrada (en el sitio web de Kubernetes).

Verificar las anotaciones del servicio de Kubernetes para ver si hay problemas con Network Load Balancers

Para problemas con Network Load Balancer, consulte las anotaciones del servicio de Kubernetes:

$ kubectl describe svc SERVICE_NAME -n YOUR_NAMESPACE

Salida de ejemplo:

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>

Nota: Tome nota de APPLICATION_POD_IP. Lo necesitará para ejecutar un comando de comprobación de estado.

Para encontrar anotaciones de servicio de Kubernetes que sean específicas para el caso de uso, consulte Anotaciones de servicio (en el sitio web de Kubernetes).

Probar una comprobación de estado de forma manual

Verifique la dirección IP del pod de la aplicación:

$ kubectl get pod -n YOUR_NAMESPACE -o wide

Ejecute un pod de prueba para evaluar manualmente una comprobación de estado dentro del clúster para las comprobaciones de estado HTTP:

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

Para las comprobaciones de estado HTTP:

# curl -Iv APPLICATION_POD_IP/HEALTH_CHECK_PATH

Nota: Reemplace APPLICATION_POD_IP por la IP del pod de la aplicación y HEALTH_CHECK_PATH con la ruta de comprobación de estado del grupo de objetivo ALB.

Comando de ejemplo:

# curl -Iv 192.168.81.137

Salida de ejemplo:

* 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

Verifique el código de estado de respuesta HTTP. Si el código de estado de respuesta es 200 OK, significa que la aplicación responde correctamente en la ruta de comprobación de estado.

Si el código de estado de respuesta HTTP es 3xx o 4xx, puede cambiar la ruta de comprobación de estado. La siguiente anotación puede responder con 200 OK:

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

-o bien-

Puede utilizar la siguiente anotación en el recurso de entrada para agregar un rango de códigos de estado de respuesta de comprobación de estado correcta:

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

Para las comprobaciones de estado de TCP, utilice el siguiente comando para instalar el comando netcat:

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

Pruebe las comprobaciones de estado de TCP:

# nc -z -v APPLICATION_POD_IP CONTAINER_PORT_NUMBER

Nota: Reemplace APPLICATION_POD_IP por la IP del pod de la aplicación y CONTAINER_PORT_NUMBER por el puerto del contenedor.

Comando de ejemplo:

# nc -z -v 192.168.81.137 80

Salida de ejemplo:

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.

Verificar las redes

Para problemas de redes, verifique lo siguiente:

• Los grupos de nodos múltiples del clúster de EKS pueden comunicarse libremente entre sí
• La lista de control de acceso a la red (ACL de red) que está asociada a la subred en la que se ejecutan los pods permite el tráfico del rango de CIDR de la subred del equilibrador de carga
• La ACL de red que está asociada a su subred del equilibrador de carga debe permitir el tráfico de retorno en el rango de puertos efímeros desde la subred en la que se ejecutan los pods.
• La tabla de enrutamiento permite el tráfico local dentro del rango de CIDR de la VPC

Reiniciar el kube-proxy

Si el kube-proxy que se ejecuta en cada nodo no se comporta correctamente, es posible que no actualice las reglas de iptables para el servicio y los puntos de conexión. Reinicie el kube-proxy para obligarlo a volver a comprobar y actualizar las reglas de iptables:

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

Salida de ejemplo:

daemonset.apps/kube-proxy restarted

Información relacionada

¿Cómo configuro un Application Load Balancer mediante el controlador del balanceador de carga de AWS en un grupo de nodos de Amazon EC2 en Amazon EKS?

¿Cómo soluciono los problemas de los balanceadores de carga en Amazon EKS?

¿Cómo puedo etiquetar las subredes de Amazon VPC en mi clúster de Amazon EKS para el descubrimiento automático de subredes por el equilibrador de carga o controladores de ingreso?

---