Solución de problemas de conexión a una aplicación hospedada en un clúster de AKS

En entornos de nube dinámicos actuales, garantizar una conectividad sin problemas a las aplicaciones hospedadas en clústeres de Azure Kubernetes Service (AKS) es fundamental para mantener un rendimiento y una experiencia de usuario óptimas. En este artículo se explica cómo solucionar problemas de conectividad causados por varios factores, incluidos los problemas del lado de la aplicación, las directivas de red, las reglas del grupo de seguridad de red (NSG) u otros.

Nota:

Para solucionar problemas comunes al intentar conectarse al servidor de API de AKS, consulte Solución básica de problemas de conexión de clúster con el servidor de API.

Requisitos previos

• La herramienta Dirección URL de cliente (cURL) o una herramienta de línea de comandos similar.

• La herramienta de línea de comandos apt-get para controlar paquetes.

• La herramienta de línea de comandos Netcat (nc) para conexiones TCP.

• La herramienta kubectl de Kubernetes o una herramienta similar para conectarse al clúster. Para instalar kubectl mediante la CLI de Azure, ejecute el comando az aks install-cli .

Factores que hay que tener en cuenta

En esta sección se describen los pasos de solución de problemas que se deben seguir si tiene problemas al intentar conectarse a la aplicación hospedada en un clúster de AKS.

En cualquier escenario de red, los administradores deben tener en cuenta los siguientes factores importantes al solucionar problemas:

• ¿Cuál es el origen y el destino de una solicitud?

• ¿Cuáles son los saltos entre el origen y el destino?

• ¿Cuál es el flujo de solicitud-respuesta?

• Qué saltos tienen capas de seguridad adicionales en la parte superior, como los siguientes elementos:

  • Firewall
  • Grupo de seguridad de red (NSG)
  • Directiva de red

Al comprobar cada componente, obtenga y analice los códigos de respuesta HTTP. Estos códigos son útiles para identificar la naturaleza del problema y son especialmente útiles en escenarios en los que la aplicación responde a las solicitudes HTTP.

Si otros pasos de solución de problemas no proporcionan ningún resultado concluyente, tome capturas de paquetes del cliente y el servidor. Las capturas de paquetes también son útiles cuando el tráfico no HTTP está implicado entre el cliente y el servidor. Para obtener más información sobre cómo recopilar capturas de paquetes para el entorno de AKS, consulte los siguientes artículos en la guía de recopilación de datos:

• Capture un volcado de TCP desde un nodo de Linux en un clúster de AKS.

• Capture un volcado tcp desde un nodo de Windows en un clúster de AKS.

• Capture paquetes TCP desde un pod en un clúster de AKS.

Saber cómo obtener los códigos de respuesta HTTP y tomar capturas de paquetes facilita la solución de problemas de conectividad de red.

Flujo de red básico para aplicaciones en AKS

En general, cuando las aplicaciones se exponen mediante el tipo de servicio Azure Load Balancer, el flujo de solicitud para acceder a ellas es el siguiente:

Nombre >> DNS del cliente>>: pods de pods de AKS de dirección IP de la >> dirección >> IP del equilibrador de carga de AKS

Hay otras situaciones posibles en las que podrían estar implicados componentes adicionales. Por ejemplo:

• La entrada NGINX administrada con la característica del complemento de enrutamiento de aplicaciones está habilitada.
• La puerta de enlace de aplicaciones se usa a través del controlador de entrada de Application Gateway (AGIC) en lugar de Azure Load Balancer.
• Azure Front Door y API Management se pueden usar sobre el equilibrador de carga.
• El proceso usa un equilibrador de carga interno.
• Es posible que la conexión no finalice en el pod y la dirección URL solicitada. Esto podría depender de si el pod puede conectarse a otra entidad, como una base de datos o cualquier otro servicio del mismo clúster.

Es importante comprender el flujo de solicitudes de la aplicación.

Un flujo de solicitud básico a las aplicaciones de un clúster de AKS se parecería al flujo que se muestra en el diagrama siguiente.

Solución de problemas dentro de fuera

La solución de problemas de conectividad puede implicar muchas comprobaciones, pero el enfoque interno puede ayudar a encontrar el origen del problema e identificar el cuello de botella. En este enfoque, se inicia en el propio pod, comprobando si la aplicación responde en la dirección IP del pod. A continuación, compruebe cada componente a su vez al cliente final.

Paso 1: Compruebe si el pod se está ejecutando y la aplicación o el contenedor dentro del pod responde correctamente.

Para determinar si el pod se está ejecutando, ejecute uno de los siguientes comandos kubectl get :

# List pods in the specified namespace.
kubectl get pods -n <namespace-name>

# List pods in all namespaces.
kubectl get pods -A

¿Qué ocurre si el pod no se está ejecutando? En este caso, compruebe los eventos de pod mediante el comando kubectl describe :

kubectl describe pod <pod-name> -n <namespace-name>

Si el pod no está en un Ready estado o Running o se reinicia muchas veces, compruebe la kubectl describe salida. Los eventos mostrarán cualquier problema que impida que pueda iniciar el pod. O bien, si el pod se ha iniciado, es posible que se haya producido un error en la aplicación dentro del pod, lo que hace que se reinicie el pod. Solucione los problemas del pod en consecuencia para asegurarse de que está en un estado adecuado.

Si el pod se está ejecutando, también puede ser útil comprobar los registros de los contenedores que están dentro del pod. Ejecute la siguiente serie de comandos de registros kubectl:

kubectl logs <pod-name> -n <namespace-name>

# Check logs for an individual container in a multicontainer pod.
kubectl logs <pod-name> -n <namespace-name> -c <container-name>

# Dump pod logs (stdout) for a previous container instance.
kubectl logs <pod-name> --previous                      

# Dump pod container logs (stdout, multicontainer case) for a previous container instance.
kubectl logs <pod-name> -c <container-name> --previous      

¿Se está ejecutando el pod? En este caso, pruebe la conectividad iniciando un pod de prueba en el clúster. Desde el pod de prueba, puede acceder directamente a la dirección IP del pod de la aplicación y comprobar si la aplicación responde correctamente. Ejecute los comandos kubectl run, apt-gety cURL como se indica a continuación:

# Start a test pod in the cluster:
kubectl run -it --rm aks-ssh --image=debian:stable

# After the test pod is running, you will gain access to the pod.
# Then you can run the following commands:
apt-get update -y && apt-get install dnsutils -y && apt-get install curl -y && apt-get install netcat-traditional -y

# After the packages are installed, test the connectivity to the application pod:
curl -Iv http://<pod-ip-address>:<port>

En el caso de las aplicaciones que escuchan en otros protocolos, puede instalar herramientas pertinentes dentro del pod de prueba como la herramienta netcat y, a continuación, comprobar la conectividad con el pod de la aplicación ejecutando el siguiente comando:

# After the packages are installed, test the connectivity to the application pod using netcat/nc command:
nc -z -v <pod-ip-address> <port>

Para obtener más comandos para solucionar problemas de pods, consulte Depuración de pods en ejecución.

Paso 2: Comprobar si la aplicación es accesible desde el servicio

En los escenarios en los que se ejecuta la aplicación dentro del pod, puede centrarse principalmente en la solución de problemas de cómo se expone el pod.

¿El pod se expone como servicio? En este caso, compruebe los eventos del servicio. Además, compruebe si la dirección IP del pod y el puerto de aplicación están disponibles como punto de conexión en la descripción del servicio:

# Check the service details.
kubectl get svc -n <namespace-name>

# Describe the service.
kubectl describe svc <service-name> -n <namespace-name>

Compruebe si la dirección IP del pod está presente como punto de conexión en el servicio, como en el ejemplo siguiente:

$ kubectl get pods -o wide  # Check the pod's IP address.
NAME            READY   STATUS        RESTARTS   AGE   IP            NODE                                
my-pod          1/1     Running       0          12m   10.244.0.15   aks-agentpool-000000-vmss000000  

$ kubectl describe service my-cluster-ip-service  # Check the endpoints in the service.
Name:              my-cluster-ip-service
Namespace:         default
Selector:          app=my-pod
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.0.174.133
IPs:               10.0.174.133
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.244.0.15:80     # <--- Here

$ kubectl get endpoints  # Check the endpoints directly for verification.
NAME                      ENDPOINTS           AGE
my-cluster-ip-service     10.244.0.15:80      14m

Si los puntos de conexión no apuntan a la dirección IP correcta del pod, compruebe y Labels Selectors para el pod y el servicio.

¿Los puntos de conexión son correctos en el servicio? Si es así, acceda al servicio y compruebe si se puede acceder a la aplicación.

Acceso al servicio ClusterIP

Para el ClusterIP servicio, puede iniciar un pod de prueba en el clúster y acceder a la dirección IP del servicio:

# Start a test pod in the cluster:
kubectl run -it --rm aks-ssh --image=debian:stable
  
# After the test pod is running, you will gain access to the pod.
# Then, you can run the following commands:
apt-get update -y && apt-get install dnsutils -y && apt-get install curl -y && apt-get install netcat-traditional -y
  
# After the packages are installed, test the connectivity to the service:
curl -Iv http://<service-ip-address>:<port>

En el caso de las aplicaciones que escuchan en otros protocolos, puede instalar herramientas pertinentes dentro del pod de prueba como la herramienta netcat y, a continuación, comprobar la conectividad con el pod de la aplicación ejecutando el siguiente comando:

# After the packages are installed, test the connectivity to the application pod using netcat/nc command:
nc -z -v <pod-ip-address> <port>

Si el comando anterior no devuelve una respuesta adecuada, compruebe si hay errores en los eventos del servicio.

Acceso al servicio LoadBalancer

Para el LoadBalancer servicio, puede acceder a la dirección IP del equilibrador de carga desde fuera del clúster.

curl -Iv http://<service-ip-address>:<port>

En el caso de las aplicaciones que escuchan en otros protocolos, puede instalar herramientas pertinentes dentro del pod de prueba como la herramienta netcat y, a continuación, comprobar la conectividad con el pod de la aplicación ejecutando el siguiente comando:

nc -z -v <pod-ip-address> <port>

¿Devuelve la dirección IP del LoadBalancer servicio una respuesta correcta? Si no es así, siga estos pasos:

1. Compruebe los eventos del servicio.

2. Compruebe que los grupos de seguridad de red (NSG) asociados a los nodos de AKS y la subred de AKS permiten el tráfico entrante en el puerto de servicio.

Para obtener más comandos para solucionar problemas de servicios, consulte Servicios de depuración.

Escenarios que usan una entrada en lugar de un servicio

En escenarios en los que la aplicación se expone mediante un Ingress recurso, el flujo de tráfico es similar a la siguiente progresión:

Nombre >> DNS de cliente >> Equilibrador de carga o pods del controlador de entrada de la dirección >> IP de application Gateway dentro del servicio de clúster >> o pods

También puede aplicar el enfoque de solución de problemas dentro de fuera aquí. También puede comprobar los detalles del recurso de kubernetes de entrada y del controlador de entrada para obtener más información:

$ kubectl get ing -n <namespace-of-ingress>  # Checking the ingress details and events.
NAME                         CLASS    HOSTS                ADDRESS       PORTS     AGE
hello-world-ingress          <none>   myapp.com            20.84.x.x     80, 443   7d22h

$ kubectl describe ing -n <namespace-of-ingress> hello-world-ingress
Name:             hello-world-ingress
Namespace:        <namespace-of-ingress>
Address:          20.84.x.x
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
TLS:
  tls-secret terminates myapp.com
Rules:
  Host                Path  Backends
  ----                ----  --------
  myapp.com
                      /blog   blog-service:80 (10.244.0.35:80)
                      /store  store-service:80 (10.244.0.33:80)

Annotations:          cert-manager.io/cluster-issuer: letsencrypt
                      kubernetes.io/ingress.class: nginx
                      nginx.ingress.kubernetes.io/rewrite-target: /$1
                      nginx.ingress.kubernetes.io/use-regex: true
Events:
  Type    Reason  Age    From                      Message
  ----    ------  ----   ----                      -------
  Normal  Sync    5m41s  nginx-ingress-controller  Scheduled for sync
  Normal  Sync    5m41s  nginx-ingress-controller  Scheduled for sync

Este ejemplo contiene un Ingress recurso que:

• Escucha en el myapp.com host.
• Tiene dos Path cadenas configuradas.
• Rutas a dos Services en el back-end.

Compruebe que los servicios back-end se están ejecutando y responda al puerto mencionado en la descripción de entrada:

$ kubectl get svc -n <namespace-of-ingress>
NAMESPACE       NAME                                     TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                      
ingress-basic   blog-service                             ClusterIP      10.0.155.154   <none>        80/TCP                       
ingress-basic   store-service                            ClusterIP      10.0.61.185    <none>        80/TCP             
ingress-basic   nginx-ingress-ingress-nginx-controller   LoadBalancer   10.0.122.148   20.84.x.x     80:30217/TCP,443:32464/TCP   

Compruebe los registros de los pods del controlador de entrada si se produce un error:

$ kubectl get pods -n <namespace-of-ingress>  # Get the ingress controller pods.
NAME                                                     READY   STATUS    RESTARTS   AGE
aks-helloworld-one-56c7b8d79d-6zktl                      1/1     Running   0          31h
aks-helloworld-two-58bbb47f58-rrcv7                      1/1     Running   0          31h
nginx-ingress-ingress-nginx-controller-9d8d5c57d-9vn8q   1/1     Running   0          31h
nginx-ingress-ingress-nginx-controller-9d8d5c57d-grzdr   1/1     Running   0          31h

$ # Check logs from the pods.
$ kubectl logs -n ingress-basic nginx-ingress-ingress-nginx-controller-9d8d5c57d-9vn8q

¿Qué ocurre si el cliente realiza solicitudes al nombre de host de entrada o a la dirección IP, pero no se ven entradas en los registros del pod del controlador de entrada? En este caso, es posible que las solicitudes no lleguen al clúster y que el usuario reciba un Connection Timed Out mensaje de error.

Otra posibilidad es que los componentes de los pods de entrada, como Load Balancer o Application Gateway, no enrutan correctamente las solicitudes al clúster. Si esto es cierto, puede comprobar la configuración de back-end de estos recursos.

Si recibe un Connection Timed Out mensaje de error, compruebe el grupo de seguridad de red asociado a los nodos de AKS. Además, compruebe la subred de AKS. Podría bloquear el tráfico desde el equilibrador de carga o la puerta de enlace de aplicaciones a los nodos de AKS.

Para obtener más información sobre cómo solucionar problemas de entrada (por ejemplo, Entrada nginx), consulte solución de problemas de entrada-nginx.

Ponte en contacto con nosotros para obtener ayuda

Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.

Aviso de declinación de responsabilidades sobre la información de contacto de terceros

Microsoft proporciona información de contacto de otros proveedores para ayudarle a encontrar información adicional sobre este tema. Esta información de contacto puede cambiar sin previo aviso. Microsoft no garantiza la precisión de esta información de contacto de terceros.