Un grupo de seguridad de red personalizado bloquea el tráfico
Al acceder a una aplicación hospedada en un clúster de Azure Kubernetes Service (AKS), recibirá un mensaje de error "Tiempo de espera". Este error puede producirse incluso si la aplicación se está ejecutando y el resto de la configuración parece ser correcto.
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 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.
Síntomas
Si ejecuta los siguientes comandos kubectl get y cURL, experimentará errores de tiempo de espera similares a la siguiente salida de la consola:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
my-deployment-66648877fc-v78jm 1/1 Running 0 5m53s
$ kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-loadbalancer-service LoadBalancer 10.0.107.79 10.81.x.x 80:31048/TCP 4m14s
$ curl -Iv http://10.81.124.39 # Use an IP address that fits the "EXTERNAL-IP" pattern.
* Trying 10.81.x.x:80...
* connect to 10.81.x.x port 80 failed: Timed out
* Failed to connect to 10.81.x.x port 80 after 21033 ms: Timed out
* Closing connection 0
curl: (28) Failed to connect to 10.81.x.x port 80 after 21033 ms: Timed out
Causa
Si experimenta el mismo error "Tiempo de espera" cada vez, esto suele sugerir que un componente de red está bloqueando el tráfico.
Para solucionar este problema, puede empezar comprobando el acceso al pod y, a continuación, pasar al cliente en un enfoque interno.
Para comprobar el pod, ejecute los siguientes kubectl get comandos y kubectl describe :
$ kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
my-deployment-66648877fc-v78jm 1/1 Running 0 53s 172.25.0.93 aks-agentpool-42617579-vmss000000
$ kubectl describe pod my-deployment-66648877fc-v78jm # Specify the pod name from the previous command.
...
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 117s default-scheduler Successfully assigned default/my-deployment-66648877fc-v78jm to aks-agentpool-42617579-vmss000000
Normal Pulling 116s kubelet Pulling image "httpd"
Normal Pulled 116s kubelet Successfully pulled image "httpd" in 183.532816ms
Normal Created 116s kubelet Created container webserver
Normal Started 116s kubelet Started container webserver
En función de esta salida, el pod parece estar ejecutándose correctamente, sin reinicios.
Abra un pod de prueba para comprobar el acceso al pod de la aplicación. Ejecute los siguientes kubectl getcomandos , kubectl run, apt-gety cURL:
$ kubectl get pods -o wide # Get the pod IP address.
NAME READY STATUS RESTARTS AGE IP NODE
my-deployment-66648877fc-v78jm 1/1 Running 0 7m45s 172.25.0.93 aks-agentpool-42617579-vmss000000
$ kubectl run -it --rm aks-ssh --image=debian:stable # Launch the test pod.
If you don't see a command prompt, try pressing enter.
$ root@aks-ssh:
$ # Install packages inside the test pod.
$ root@aks-ssh: apt-get update -y && apt-get install dnsutils -y && apt-get install curl -y
Get:1 http://deb.debian.org/debian bullseye InRelease [116 kB]
Get:2 http://deb.debian.org/debian bullseye-updates InRelease [39.4 kB]
...
...
Running hooks in /etc/ca-certificates/update.d...
done.
$ # Try to check access to the pod using the pod IP address from the "kubectl get" output.
$ curl -Iv http://172.25.0.93
* Trying 172.25.0.93:80...
* Connected to 172.25.0.93 (172.25.0.93) port 80 (#0)
...
...
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
...
...
* Connection #0 to host 172.25.0.93 left intact
El pod es accesible directamente. Por lo tanto, la aplicación se está ejecutando.
El servicio definido es un LoadBalancer tipo. Esto significa que el flujo de solicitud del cliente final al pod será el siguiente:
Pod de aplicación del nodo akS del equilibrador >> >> de carga de cliente >>
En este flujo de solicitud, podemos bloquear el tráfico a través de los siguientes componentes:
- Directivas de red en el clúster
- El grupo de seguridad de red (NSG) para la subred de AKS y el nodo de AKS
Para comprobar la directiva de red, ejecute el siguiente kubectl get comando:
$ kubectl get networkpolicy --all-namespaces
NAMESPACE NAME POD-SELECTOR AGE
kube-system konnectivity-agent app=konnectivity-agent 3h8m
Solo existe la directiva predeterminada de AKS. Por lo tanto, la directiva de red no parece estar bloqueando el tráfico.
Para comprobar los NSG y sus reglas asociadas mediante AKS, siga estos pasos:
En Azure Portal, busque y seleccione Conjuntos de escalado de máquinas virtuales.
En la lista de instancias del conjunto de escalado, seleccione la que está usando.
En el panel de menús de la instancia del conjunto de escalado, seleccione
Networking.
Aparece la página Redes de la instancia del conjunto de escalado. En la pestaña Reglas de puerto de entrada, se muestran dos conjuntos de reglas que se basan en los dos grupos de seguridad de red que actúan en la instancia del conjunto de escalado:
El primer conjunto se compone de reglas de NSG en el nivel de subred. Estas reglas se muestran bajo el siguiente encabezado de nota:
Grupo de seguridad de red my-aks-nsg> (conectado a la subred:< my-aks-subnet>)<
Esta disposición es común si se usa una red virtual personalizada y una subred personalizada para el clúster de AKS. El conjunto de reglas en el nivel de subred podría parecerse a la tabla siguiente.
Priority Nombre Puerto Protocolo Origen Destino Acción 65000 AllowVnetInBound Any Any VirtualNetwork VirtualNetwork Allow 65001 AllowAzureLoadBalancerInBound Any Any AzureLoadBalancer Any Allow 65500 DenyAllInBound Any Any Any Any Denegar El segundo conjunto se compone de reglas de NSG en el nivel de adaptador de red. Estas reglas se muestran bajo el siguiente encabezado de nota:
Grupo de seguridad de red aks-agentpool-agentpool-number-nsg<> (conectado a la interfaz de red: aks-agentpool-vm-scale-set-number-vmss)<>
El clúster de AKS aplica este grupo de seguridad de red y se administra mediante AKS. El conjunto de reglas correspondiente podría parecerse a la tabla siguiente.
Priority Nombre Puerto Protocolo Origen Destino Acción 500 <guid-TCP-80-Internet> 80 TCP Internet 10.81.x.x Permitir 65000 AllowVnetInBound Any Any VirtualNetwork VirtualNetwork Allow 65001 AllowAzureLoadBalancerInBound Any Any AzureLoadBalancer Any Allow 65500 DenyAllInBound Any Any Any Any Denegar
En el nivel de adaptador de red, hay una regla de entrada de NSG para TCP en la dirección IP 10.81.x.x en el puerto 80 (resaltado en la tabla). Sin embargo, falta una regla equivalente de las reglas del grupo de seguridad de red en el nivel de subred.
¿Por qué AKS no aplicó la regla al grupo de seguridad de red personalizado? Dado que AKS no aplica NSG a su subred y no modificará ninguno de los NSG asociados a esa subred. AKS modificará los NSG solo en el nivel de adaptador de red. Para obtener más información, consulte ¿Puedo configurar grupos de seguridad de red con AKS?.
Solución
Si la aplicación está habilitada para el acceso en un puerto determinado, debe asegurarse de que el NSG personalizado permite ese puerto como regla Inbound . Una vez agregada la regla adecuada en el grupo de seguridad de red personalizado en el nivel de subred, se puede acceder a la aplicación.
$ curl -Iv http://10.81.x.x
* Trying 10.81.x.x:80...
* Connected to 10.81.x.x (10.81.x.x) port 80 (#0)
...
...
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
...
...
* Connection #0 to host 10.81.x.x left intact
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.