Condividi tramite

Un gruppo di sicurezza di rete personalizzato blocca il traffico

  • Articolo

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.

  • 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 di 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 di timeout ogni volta, in genere si suggerisce che un componente di rete blocca il traffico.

Per risolvere questo problema, è possibile iniziare controllando l'accesso al pod e quindi passare al client con un approccio inside-out .

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. Di conseguenza, 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 >> servizio Azure Kubernetes del servizio Azure Kubernetes del servizio Di bilanciamento >> del carico client >>

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

Esistono solo i criteri predefiniti del servizio Azure Kubernetes. Pertanto, i criteri di rete non sembrano bloccare il traffico.

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

  1. Nel portale di Azure cercare e selezionare Set di scalabilità di macchine virtuali.

  2. Nell'elenco delle istanze del set di scalabilità selezionare quello in uso.

  3. 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 basate 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 Origine Destinazione Azione
    65000 AllowVnetInBound Qualsiasi Qualsiasi VirtualNetwork VirtualNetwork Consenti
    65001 AllowAzureLoadBalancerInBound Qualsiasi Qualsiasi AzureLoadBalancer Qualsiasi Consenti
    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 Origine Destinazione Azione
    500 <guid-TCP-80-Internet> 80 TCP Internet 10.81.x.X Consenti
    65000 AllowVnetInBound Qualsiasi Qualsiasi VirtualNetwork VirtualNetwork Consenti
    65001 AllowAzureLoadBalancerInBound Qualsiasi Qualsiasi AzureLoadBalancer Qualsiasi Consenti
    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, nelle regole per il gruppo di sicurezza di rete a livello di subnet manca una regola equivalente.

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 nessuno dei gruppi di sicurezza di rete associati 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.