Compartir a través de

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

  • Artículo

Los problemas de conexión con un clúster de Microsoft Azure Kubernetes Service (AKS) pueden significar cosas diferentes. En algunos casos, podría significar que la conexión al servidor de API se ve afectada (por ejemplo, mediante kubectl). En otros casos, podría significar que los problemas comunes de conexión afectan a una aplicación hospedada en el clúster de AKS. En este artículo se describe cómo solucionar problemas de conexión de clúster de AKS.

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 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 se deben tener en cuenta

En esta sección se tratan los pasos para solucionar 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, realice capturas de paquetes desde el 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:

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

Flujo de red básico para aplicaciones en AKS

En general, el flujo de solicitudes para acceder a las aplicaciones hospedadas en un clúster de AKS es el siguiente:

Nombre DNS de cliente>>: dirección >> IP del equilibrador de carga de AKS Nodos >> de AKS >> Pods

Hay otras situaciones posibles en las que pueden estar implicados componentes adicionales. Por ejemplo:

  • 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 pueden usarse 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 en 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 sería similar al flujo que se muestra en el diagrama siguiente.

Diagrama de un flujo de solicitud básico a las aplicaciones de un clúster de Azure Kubernetes Service (A K S).

Solución de problemas internos

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 hasta el cliente final.

Paso 1: Comprobar si el pod se está ejecutando y la aplicación o el contenedor dentro del pod responden 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

¿Y 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 ha reiniciado muchas veces, compruebe la kubectl describe salida. Los eventos revelará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 pods y los contenedores que están dentro de ellos. Ejecute la siguiente serie de comandos de registros de 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

# 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 las herramientas pertinentes dentro del pod de prueba y, a continuación, comprobar la conectividad con el pod de aplicación.

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

Paso 2: Comprobar si se puede acceder a la aplicación desde el servicio

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

¿Se expone el pod como servicio? En este caso, compruebe los eventos del servicio. Además, compruebe si la dirección IP del pod y el puerto de la 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 un 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 del pod correcta, compruebe y LabelsSelectors para el pod y el servicio.

¿Son correctos los puntos de conexión del servicio? Si es así, acceda al servicio y compruebe si la aplicación es accesible.

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:

Diagrama del uso de un pod de prueba en un clúster de Azure Kubernetes Service (A K S) para acceder a la dirección I P del clúster. 

# 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
  
# After the packages are installed, test the connectivity to the service:
curl -Iv http://<service-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.

Diagrama de un usuario de prueba que accede a la dirección I P del equilibrador de carga desde fuera de un clúster de Azure Kubernetes Service (A K S). 

curl -Iv http://<service-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 Depuración de servicios.

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 dirección >> IP de puerta de enlace de aplicaciones Pods de entrada dentro del servicio o pods del clúster >>

Diagrama del flujo de tráfico de red cuando una aplicación dentro de un clúster de Azure Kubernetes Service (A K S) se expone mediante un recurso de entrada.

También puede aplicar el enfoque de solución de problemas internos aquí. También puede comprobar los detalles del controlador de entrada y 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 que se menciona 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 hay 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 estar bloqueando 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 (como la entrada de 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. Dicha información de contacto puede cambiar sin notificación previa. Microsoft no garantiza la precisión de esta información de contacto de terceros.