¿Cómo soluciono los problemas de objetivos en mal estado de Network Load Balancer en Amazon EKS?

Descripción corta

Los siguientes son motivos habituales por los que los destinos de Network Load Balancer no están en buen estado:

• La comprobación de estado está configurada incorrectamente. Para resolver este problema, inicie manualmente la comprobación de estado desde una máquina host que se ejecute en Amazon Virtual Private Cloud (Amazon VPC).
• Hay una excepción inesperada en el pod. Para resolver este problema, siga los pasos de solución de problemas en la sección de resolución Comprobar si hay una excepción inesperada del pod en la sección.
• Network Load Balancer con externalTrafficPolicy establecido en Local (desde el sitio web de Kubernetes), con un DNS de Amazon VPC personalizado en el conjunto de opciones de DHCP. Para resolver este problema, aplique un parche a kube-proxy con el marcador de anulación de nombre de host.

Nota: Para determinar si el tipo de grupo de destino es una dirección IP o una instancia, consulte si existe la anotación de servicio service.beta.kubernetes.io/aws-load-balancer-nlb-target-type.

Resolución

Comprobar si el grupo de destino 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.

Verificar que la comprobación de estado está configurada correctamente

Compruebe qué anotaciones de Elastic Load Balancing (ELB) del sitio web de Kubernetes están configuradas para su servicio:

`kubectl get service service_name -o yaml`

Salida de 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.

Si las anotaciones anteriores están configuradas incorrectamente, los destinos pueden estar en mal estado.

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

Para los tipos de destino de instancia, ejecute el siguiente comando curl con NodePort:

curl-ivk node_IP:NodePort

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

Para 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 del pod y pod_port por el puerto del pod.

Comprobar si hay una excepción inesperada del pod

Tipo de destino de instancia

Verifique la especificación del servicio para las anotaciones de configuración de comprobación de estado actuales (desde el sitio web de GitHub):

kubectl get service service_name -o yaml

Compruebe si hay puntos de conexión para verificar que hay pods detrás del servicio:

kubectl get endpoints service_name -o yaml

Si no existen puntos de conexión para el servicio, compruebe que las etiquetas del pod y las etiquetas del servicio coincidan:

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

Nota: Reemplace pod_name por el nombre de su pod.

Compruebe si los pods están en estado En ejecución:

kubectl get pod -o wide

Comprueba los estados de los pods para verificar que los pods se estén ejecutando sin ningún reinicio:

kubectl get pods -o wide

Si hay reinicios, recopile los registros del pod para determinar la causa:

kubectl logs pod_name
kubectl logs pod_name --previous

Inicie sesión en una máquina host en Amazon VPC donde pueda comunicarse con el nodo.

Utilice 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 devuelve el código de estado HTTP esperado, los pods del backend tampoco devuelven el código de estado HTTP esperado.

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

curl pod_IP:pod_port

Si el comando curl no devuelve el código de estado HTTP esperado, significa que el pod no está configurado correctamente.

Nota: Si externalTrafficPolicy del servicio (desde el sitio web de Kubernetes) se establece en Local, solo los nodos en los que se ejecutan los pods del backend del servicio se consideran objetivos en buen estado.

Tipo de destino de dirección IP

Verifique la especificación del servicio para las anotaciones de configuración de comprobación de estado actuales (desde el sitio web de GitHub):

kubectl get service service_name -o yaml

Inicie sesión en una máquina host en 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 devuelve el código de estado HTTP esperado, significa que el pod no está configurado correctamente.

Parchear kube-proxy con el marcador de anulación del nombre de host

Modifica el comando, los argumentos y el entorno la de especificación de daemonset kube-proxy con:

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

Para los tipos de destino de instancia, si externalTrafficPolicy se establece en Cluster o Local, la configuración de entrada predeterminada del grupo de seguridad del nodo para NodePort es 0.0.0.0/0. Además, cuando externalTrafficPolicy se establece en Local, se configura un NodePort de comprobación de estado adicional para permitir intervalos de direcciones IP de CIDR de subred.

Para controlar la dirección IP de origen en el grupo de seguridad de nodos para NodePort, agregue loadBalancerSourceRanges en la especificación e incluya los rangos:

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

Nota: Si .spec.loadBalancerSourceRanges no está configurado, Kubernetes permite el tráfico desde 0.0.0.0/0 a los grupos de seguridad del nodo. Si los nodos tienen direcciones IP públicas, el tráfico que no sea de Network Load Balancer también puede llegar a todas las instancias de los grupos de seguridad modificados.

---