Solución de problemas de conexiones salientes básicos de un clúster de AKS

Artículo
12/18/2024

En este artículo se describe cómo realizar una solución básica de problemas de conexiones salientes desde un clúster de Microsoft Azure Kubernetes Service (AKS) e identificar los componentes defectuosos.

Requisitos previos

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 .
La herramienta de línea de comandos apt-get para controlar paquetes.
La herramienta Dirección URL de cliente (cURL) o una herramienta de línea de comandos similar.
Herramienta nslookup de línea de comandos (dnsutils) para comprobar la resolución dns.

Escenarios para el tráfico saliente en Azure Kubernetes Service

El tráfico que se origina desde el clúster de AKS, ya sea desde un pod o un nodo de trabajo, se considera el tráfico saliente del clúster. ¿Qué ocurre si hay un problema en el flujo de salida de un clúster de AKS? Antes de solucionar problemas, examine primero los escenarios para el flujo de tráfico saliente.

El tráfico saliente de un clúster de AKS se puede clasificar en las siguientes categorías:

Tráfico a un pod o servicio en el mismo clúster (tráfico interno).
Tráfico a un dispositivo o punto de conexión de la misma red virtual o a una red virtual diferente que usa el emparejamiento de redes virtuales.
Tráfico a un entorno local a través de una conexión VPN o una conexión de Azure ExpressRoute.
Tráfico fuera de la red de AKS a través de Azure Load Balancer (tráfico saliente público).
Tráfico fuera de la red de AKS a través de Azure Firewall o un servidor proxy (tráfico saliente público).

Tráfico interno

Un flujo de solicitud básico para el tráfico interno desde un clúster de AKS es similar al flujo que se muestra en el diagrama siguiente.

Tráfico saliente público a través de Azure Load Balancer

Si el tráfico es para un destino en Internet, el método predeterminado es enviar el tráfico a través de Azure Load Balancer.

Tráfico saliente público a través de Azure Firewall o un servidor proxy

En algunos casos, el tráfico de salida debe filtrarse y podría requerir Azure Firewall.

Es posible que un usuario quiera agregar un servidor proxy en lugar de un firewall o configurar una puerta de enlace NAT para el tráfico de salida. El flujo básico sigue siendo el mismo que se muestra en el diagrama.

Es importante comprender la naturaleza del flujo de salida del clúster para poder continuar con la solución de problemas.

Consideraciones al solucionar problemas

Comprobación del dispositivo de salida

Al solucionar problemas de tráfico saliente en AKS, es importante saber cuál es el dispositivo de salida (es decir, el dispositivo a través del que pasa el tráfico). Aquí, el dispositivo de salida podría ser uno de los siguientes componentes:

Equilibrador de carga de Azure
Azure Firewall o un firewall personalizado
Puerta de enlace de traducción de direcciones de red (NAT)
Un servidor proxy

El flujo también podría diferir en función del destino. Por ejemplo, el tráfico interno (es decir, dentro del clúster) no pasa por el dispositivo de salida. El tráfico interno solo usaría la red del clúster. Para el tráfico saliente público, determine si hay un dispositivo de salida que pasa y comprueba ese dispositivo.

Comprobación de cada salto dentro del flujo de tráfico

Después de identificar el dispositivo de salida, compruebe los siguientes factores:

Origen y destino de la solicitud.
Saltos entre el origen y el destino.
Flujo de solicitud-respuesta.
Saltos mejorados por capas de seguridad adicionales, como las siguientes:
- Firewall
- Grupo de seguridad de red (NSG)
- Directiva de red

Para identificar un salto problemático, compruebe los códigos de respuesta antes y después de él. Para comprobar si los paquetes llegan correctamente en un salto específico, puede continuar con las capturas de paquetes.

Comprobación de códigos de respuesta HTTP

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

Tomar capturas de paquetes del cliente y el servidor

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:

Lista de comprobación de solución de problemas

Para solucionar problemas básicos del tráfico de salida desde un clúster de AKS, siga estos pasos:

Asegúrese de que la resolución del Sistema de nombres de dominio (DNS) para el punto de conexión funciona correctamente.
Asegúrese de que puede llegar al punto final a través de una dirección IP.
Asegúrese de que puede acceder al punto de conexión desde otro origen.
Asegúrese de que el punto de conexión funciona.
Compruebe si el clúster puede llegar a cualquier otro punto de conexión externo.
Compruebe si una política de red está bloqueando el tráfico.
Comprobación de si un grupo de seguridad de red está bloqueando el tráfico.
Compruebe si un cortafuegos o proxy está bloqueando el tráfico.
Compruebe si la entidad de seguridad del servicio AKS o la identidad gestionada tiene los permisos de servicio AKS necesarios para realizar los cambios de red en los recursos de Azure.

Nota:

Supone que no hay ninguna malla de servicio cuando se realiza una solución de problemas básica. Si usa una malla de servicio como Istio, genera resultados inusuales para el tráfico basado en TCP.

Compruebe si el pod y el nodo pueden llegar al punto de conexión.

Desde el pod, puede ejecutar una búsqueda DNS en el punto de conexión.

¿Qué ocurre si no puede ejecutar el comando kubectl exec para conectarse al pod e instalar el paquete DNS Utils? En esta situación, puede iniciar un pod de prueba en el mismo espacio de nombres que el pod problemático y, a continuación, ejecutar las pruebas.

Nota:

Si el tráfico de salida o resolución DNS no permite instalar los paquetes de red necesarios, puede usar la imagen de Docker de rishasi/ubuntu-netutil:1.0. En esta imagen, los paquetes necesarios ya están instalados.

Procedimiento de ejemplo para comprobar la resolución DNS de un pod de Linux

Inicie un pod de prueba en el mismo espacio de nombres que el pod problemático:

kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "linux"}}}'

Después de ejecutar el pod de prueba, obtendrá acceso al pod.

Ejecute los siguientes comandos apt-get para instalar otros paquetes de herramientas:

# Update and install tool packages
apt-get update && apt-get install -y dnsutils curl

Una vez instalados los paquetes, ejecute el comando nslookup para probar la resolución DNS en el punto de conexión:

$ nslookup microsoft.com # Microsoft.com is used as an example
Server:         <server>
Address:        <server IP address>#53
...
...
Name:   microsoft.com
Address: 20.53.203.50

Pruebe la resolución DNS desde el servidor DNS ascendente directamente. En este ejemplo se usa Azure DNS:

$ nslookup microsoft.com 168.63.129.16
Server:         168.63.129.16
Address:        168.63.129.16#53
...
...
Address: 20.81.111.85

A veces, hay un problema con el propio punto de conexión en lugar de un DNS de clúster. En tales casos, tenga en cuenta las siguientes comprobaciones:

Compruebe si el puerto deseado está abierto en el host remoto:
```
curl -Ivm5 telnet://microsoft.com:443
```
Compruebe el código de respuesta HTTP:
```
curl -Ivm5 https://microsoft.com
```
Compruebe si puede conectarse a cualquier otro punto de conexión:
```
curl -Ivm5 https://kubernetes.io
```

Para comprobar que el punto de conexión es accesible desde el nodo en el que se encuentra el pod problemático y, a continuación, compruebe la configuración de DNS, siga estos pasos:

Escriba el nodo en el que se encuentra el pod problemático a través del pod de depuración. Para más información sobre cómo hacerlo, consulte Conexión a nodos de clúster de Azure Kubernetes Service (AKS) para el mantenimiento o la solución de problemas.

Pruebe la resolución DNS en el punto de conexión:

$ nslookup  microsoft.com
Server:         168.63.129.16
Address:        168.63.129.16#53

Non-authoritative answer:
Name:   microsoft.com
Address: 20.112.52.29
Name:   microsoft.com
Address: 20.81.111.85
Name:   microsoft.com
Address: 20.84.181.62
Name:   microsoft.com
Address: 20.103.85.33
Name:   microsoft.com
Address: 20.53.203.50

Compruebe el archivo resolv.conf para determinar si se agregan los servidores de nombres esperados:
```
cat /etc/resolv.conf
cat /run/systemd/resolve/resolv.conf
```

Procedimiento de ejemplo para comprobar la resolución DNS de un pod de Windows

Ejecute un pod de prueba en el grupo de nodos de Windows:

# For a Windows environment, use the Resolve-DnsName cmdlet.
kubectl run dnsutil-win --image='mcr.microsoft.com/windows/servercore:ltsc2022' --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "windows"}}}' -- powershell "Start-Sleep -s 3600"

Ejecute el comando kubectl exec para conectarse al pod mediante PowerShell:
```
kubectl exec -it dnsutil-win -- powershell
```

Ejecute el cmdlet Resolve-DnsName en PowerShell para comprobar si la resolución DNS funciona para el punto de conexión:

PS C:\> Resolve-DnsName www.microsoft.com 

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
www.microsoft.com              CNAME  20    Answer     www.microsoft.com-c-3.edgekey.net
www.microsoft.com-c-3.edgekey. CNAME  20    Answer     www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net
net
www.microsoft.com-c-3.edgekey. CNAME  20    Answer     e13678.dscb.akamaiedge.net
net.globalredir.akadns.net

Name       : e13678.dscb.akamaiedge.net 
QueryType  : AAAA
TTL        : 20
Section    : Answer
IP6Address : 2600:1408:c400:484::356e   


Name       : e13678.dscb.akamaiedge.net 
QueryType  : AAAA
TTL        : 20
Section    : Answer
IP6Address : 2600:1408:c400:496::356e 


Name       : e13678.dscb.akamaiedge.net
QueryType  : A
TTL        : 12
Section    : Answer
IP4Address : 23.200.197.152

En un escenario inusual que implica la resolución DNS, las consultas DNS obtienen una respuesta correcta del nodo, pero producen un error en el pod. En este escenario, puede considerar la posibilidad de comprobar los errores de resolución dns desde el pod, pero no desde el nodo de trabajo. Si desea inspeccionar la resolución DNS de un punto de conexión en todo el clúster, puede considerar la posibilidad de comprobar el estado de la resolución DNS en todo el clúster.

Si la resolución DNS se realiza correctamente, continúe con las pruebas de red. De lo contrario, compruebe la configuración de DNS para el clúster.

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.

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.

Compartir a través de