Un gruppo di sicurezza di rete personalizzato blocca il traffico

Articolo
11/20/2024

Quando si accede a un'applicazione ospitata in un cluster servizio Azure Kubernetes (servizio Azure Kubernetes), viene visualizzato un messaggio di errore "Timeout". Questo errore può verificarsi anche se l'applicazione è in esecuzione e il resto della configurazione sembra essere corretto.

Prerequisiti

Lo strumento Kubernetes kubectl , o uno strumento simile, per connettersi al cluster. Per installare kubectl usando l'interfaccia della riga di comando di Azure, eseguire il comando az aks install-cli .
Lo strumento URL client (cURL) o uno strumento da riga di comando simile.
Lo strumento da riga di comando apt-get per la gestione dei pacchetti.

Sintomi

Se si eseguono i comandi kubectl get e cURL seguenti, si verificano errori "Timeout" simili all'output della console seguente:

$ 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

Se si verifica lo stesso errore "Timeout" ogni volta, ciò suggerisce in genere che un componente di rete blocca il traffico.

Per risolvere questo problema, è possibile iniziare controllando l'accesso al pod e quindi passando al client in un approccio interno.To troubleshoot this issue, you can start by check access to the pod, and then move on to the client in an inside-out approach.

Per controllare il pod, eseguire i comandi seguenti kubectl get e 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

In base a questo output, il pod sembra essere in esecuzione correttamente, senza alcun riavvio.

Aprire un pod di test per controllare l'accesso al pod dell'applicazione. Eseguire i comandi , kubectl run, apt-gete cURL seguentikubectl get:

$ 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

Il pod è accessibile direttamente. Pertanto, l'applicazione è in esecuzione.

Il servizio definito è un LoadBalancer tipo. Ciò significa che il flusso della richiesta dal client finale al pod sarà il seguente:

Pod applicazione del nodo >> del servizio di bilanciamento del carico client >> del servizio Azure Kubernetes >>

In questo flusso di richiesta è possibile bloccare il traffico attraverso i componenti seguenti:

Criteri di rete nel cluster
Gruppo di sicurezza di rete (NSG) per la subnet del servizio Azure Kubernetes e il nodo del servizio Azure Kubernetes

Per controllare i criteri di rete, eseguire il comando seguente kubectl get :

$ kubectl get networkpolicy --all-namespaces
NAMESPACE     NAME                 POD-SELECTOR             AGE
kube-system   konnectivity-agent   app=konnectivity-agent   3h8m

Esiste solo il criterio predefinito del servizio Azure Kubernetes. Pertanto, i criteri di rete non sembrano bloccare il traffico.

Per controllare i gruppi di sicurezza di rete e le relative regole associate tramite il servizio Azure Kubernetes, seguire questa procedura:

Nella portale di Azure cercare e selezionare Set di scalabilità di macchine virtuali.
Nell'elenco delle istanze del set di scalabilità selezionare quella in uso.
Nel riquadro dei menu dell'istanza del set di scalabilità selezionare Networking.

Viene visualizzata la pagina Rete per l'istanza del set di scalabilità. Nella scheda Regole porta in ingresso vengono visualizzati due set di regole basati sui due gruppi di sicurezza di rete che agiscono sull'istanza del set di scalabilità:

Il primo set è costituito da regole del gruppo di sicurezza di rete a livello di subnet. Queste regole vengono visualizzate sotto l'intestazione di nota seguente:

Gruppo di sicurezza di rete my-aks-nsg> (collegato alla subnet:< my-aks-subnet>)<

Questa disposizione è comune se vengono usate una rete virtuale personalizzata e una subnet personalizzata per il cluster del servizio Azure Kubernetes. Il set di regole a livello di subnet potrebbe essere simile alla tabella seguente.

Priorità	Nome	Porta	Protocollo	Source (Sorgente)	Destination	Azione
65000	AllowVnetInBound	Qualsiasi	Qualsiasi	VirtualNetwork	VirtualNetwork	Allow
65001	AllowAzureLoadBalancerInBound	Qualsiasi	Qualsiasi	AzureLoadBalancer	Any	Consentire
65500	DenyAllInBound	Qualsiasi	Qualsiasi	Qualsiasi	Qualsiasi	Nega

Il secondo set è costituito da regole del gruppo di sicurezza di rete a livello di scheda di rete. Queste regole vengono visualizzate sotto l'intestazione di nota seguente:

Gruppo di sicurezza di rete aks-agentpool-agentpool-number-nsg<> (collegato all'interfaccia di rete: aks-agentpool-vm-scale-set-number-vmss)<>

Questo gruppo di sicurezza di rete viene applicato dal cluster del servizio Azure Kubernetes ed è gestito dal servizio Azure Kubernetes. Il set di regole corrispondente potrebbe essere simile alla tabella seguente.

Priorità	Nome	Porta	Protocollo	Source (Sorgente)	Destination	Azione
500	<guid-TCP-80-Internet>	80	TCP	Internet	10.81.x.x	Consenti
65000	AllowVnetInBound	Qualsiasi	Qualsiasi	VirtualNetwork	VirtualNetwork	Allow
65001	AllowAzureLoadBalancerInBound	Qualsiasi	Qualsiasi	AzureLoadBalancer	Any	Consentire
65500	DenyAllInBound	Qualsiasi	Qualsiasi	Qualsiasi	Qualsiasi	Nega

A livello di scheda di rete è presente una regola in ingresso del gruppo di sicurezza di rete per TCP all'indirizzo IP 10.81.x.x sulla porta 80 (evidenziata nella tabella). Tuttavia, una regola equivalente non è presente nelle regole per il gruppo di sicurezza di rete a livello di subnet.

Perché il servizio Azure Kubernetes non ha applicato la regola al gruppo di sicurezza di rete personalizzato? Poiché il servizio Azure Kubernetes non applica gruppi di sicurezza di rete alla subnet e non modifica alcun gruppo di sicurezza di rete associato a tale subnet. Il servizio Azure Kubernetes modificherà i gruppi di sicurezza di rete solo a livello di scheda di rete. Per altre informazioni, vedere È possibile configurare gruppi di sicurezza di rete con il servizio Azure Kubernetes?.

Soluzione

Se l'applicazione è abilitata per l'accesso su una determinata porta, è necessario assicurarsi che il gruppo di sicurezza di rete personalizzato consenta tale porta come Inbound regola. Dopo aver aggiunto la regola appropriata nel gruppo di sicurezza di rete personalizzato a livello di subnet, l'applicazione è accessibile.

$ 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

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.

Condividi tramite