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

Artículo
04/12/2024

En este artículo se describe cómo solucionar problemas básicos de conexiones salientes desde un clúster de Microsoft Azure Kubernetes Service (AKS).

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 de línea de comandos de host para las búsquedas dns.
Herramienta de línea de comandos de Netcat (nc) para conexiones TCP.
Herramienta de línea de comandos traceroute para imprimir el seguimiento de paquetes de enrutamiento en el host de red.

Escenarios para el tráfico saliente en Azure Kubernetes Service

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

Origen y destino de la solicitud.
Saltos entre el origen y el destino.
Flujo de solicitud-respuesta.
Los saltos que se mejoran con capas de seguridad adicionales, como las siguientes capas:
- 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. Los códigos 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:

Si sabe cómo obtener los códigos de respuesta HTTP y tomar capturas de paquetes, es más fácil solucionar un problema de conectividad de red.

El tráfico que se origina desde dentro del 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 para un clúster de AKS? Antes de solucionar problemas, primero comprenda la naturaleza del flujo de solicitud-respuesta.

El tráfico saliente de un clúster de AKS se puede clasificar dentro de 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 otra red virtual (que usa emparejamiento de red virtual)
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 (tráfico de salida público)

En este documento, se tratan los pasos básicos de solución de problemas que afectan a la conectividad saliente:

Dentro del clúster
Dentro de las redes virtuales
Al mundo exterior (tráfico público)

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

Azure Load Balancer
Azure Firewall o un firewall personalizado
Una 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 las redes del clúster.

Tráfico interno

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

Tráfico externo 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 la Azure Load Balancer.

Tráfico externo 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.

En lugar de un firewall, es posible que un usuario quiera agregar un servidor proxy. O bien, es posible que el usuario quiera 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 que pueda continuar con la solución de problemas.

Lista de comprobación para la 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 de conexión a través de una dirección IP.
Asegúrese de que puede llegar 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 directiva de red está bloqueando el tráfico.
Compruebe si un grupo de seguridad de red está bloqueando el tráfico.
Compruebe si un firewall o proxy está bloqueando el tráfico.
Compruebe si la entidad de servicio de AKS o la identidad administrada tienen los permisos de servicio de AKS necesarios para realizar los cambios de red en los recursos de Azure.

Compruebe si la resolución DNS es correcta para el punto de conexión.

Desde dentro del 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 le permite instalar los paquetes de red necesarios, puede usar la imagen de rishasi/ubuntu-netutil:1.0 Docker. En esta imagen, los paquetes necesarios ya están instalados.

Este es un procedimiento de ejemplo para comprobar la resolución DNS:

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
```
Una vez que se ejecute el pod de prueba, obtendrá acceso al pod.

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

apt-get update -y
apt-get install dnsutils -y
apt-get install curl -y
apt-get install netcat -y

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

$ nslookup microsoft.com
Server:         10.0.0.10
Address:        10.0.0.10#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

Ejecute el host comando para comprobar si las solicitudes DNS se enrutan al servidor ascendente:

$ host -a microsoft.com
Trying "microsoft.com.default.svc.cluster.local"
Trying "microsoft.com.svc.cluster.local"
Trying "microsoft.com.cluster.local"
Trying "microsoft.com.00idcnmrrm4edot5s2or1onxsc.bx.internal.cloudapp.net"
Trying "microsoft.com"
Trying "microsoft.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62884
;; flags: qr rd ra; QUERY: 1, ANSWER: 27, AUTHORITY: 0, ADDITIONAL: 5

;; QUESTION SECTION:
;microsoft.com.                 IN      ANY

;; ANSWER SECTION:
microsoft.com.          30      IN      NS      ns1-39.azure-dns.com.
...
...
ns4-39.azure-dns.info.  30      IN      A       13.107.206.39

Received 2121 bytes from 10.0.0.10#53 in 232 ms

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:1809' --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

También debe comprobar si el punto de conexión es accesible desde el nodo. A continuación, compruebe la configuración de DNS en el nodo. Siga estos pasos:

Conéctese a nodos de clúster de Azure Kubernetes Service (AKS) para mantenimiento o 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
```

En un escenario inusual que implica la resolución DNS, las consultas DNS obtienen una respuesta correcta del nodo, pero el pod produce un error. En este escenario, podría considerar la posibilidad de comprobar los errores de resolución DNS desde dentro del pod, pero no desde el nodo de trabajo.

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.

Compruebe si el clúster puede llegar al punto de conexión a través de la red.

Para determinar si puede llegar al punto de conexión a través de la red desde el clúster, siga estos pasos:

Compruebe la ruta al punto de conexión para determinar si hay un tiempo de espera en una operación específica:

kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable
apt-get install -y traceroute && apt-get install netcat -y
traceroute -T microsoft.com -m 50 -p 443

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

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.

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