Delen via

Een aangepaste netwerkbeveiligingsgroep blokkeert verkeer

  • Artikel

Wanneer u een toepassing opent die wordt gehost op een AKS-cluster (Azure Kubernetes Service), wordt het foutbericht 'Timed out' weergegeven. Deze fout kan zelfs optreden als de toepassing wordt uitgevoerd en de rest van de configuratie correct lijkt te zijn.

Vereisten

Symptomen

Als u de volgende kubectl get - en cURL-opdrachten uitvoert, ondervindt u 'Time-out'-fouten die lijken op de volgende console-uitvoer:

$ 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

Oorzaak

Als u elke keer dezelfde 'time-out'-fout ondervindt, betekent dit meestal dat een netwerkonderdeel het verkeer blokkeert.

Als u dit probleem wilt oplossen, kunt u beginnen met het controleren van de toegang tot de pod en vervolgens naar de client gaan in een inside-outbenadering .

Als u de pod wilt controleren, voert u de volgende kubectl get en kubectl-beschrijvingsopdrachten uit :

$ 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

Op basis van deze uitvoer lijkt de pod correct te worden uitgevoerd, zonder opnieuw opstarten.

Open een testpod om de toegang tot de toepassingspod te controleren. Voer de volgende kubectl getopdrachten , kubectl run, apt-geten cURL uit:

$ 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

De pod is rechtstreeks toegankelijk. Daarom wordt de toepassing uitgevoerd.

De gedefinieerde service is een LoadBalancer type. Dit betekent dat de aanvraagstroom van de eindclient naar de pod er als volgt uitziet:

Client >> load balancer >> AKS-knooppunttoepassingspod >>

In deze aanvraagstroom kunnen we het verkeer via de volgende onderdelen blokkeren:

  • Netwerkbeleid in het cluster
  • De netwerkbeveiligingsgroep (NSG) voor het AKS-subnet en het AKS-knooppunt

Voer de volgende kubectl get opdracht uit om het netwerkbeleid te controleren:

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

Alleen het standaardbeleid voor AKS bestaat. Daarom lijkt netwerkbeleid het verkeer niet te blokkeren.

Voer de volgende stappen uit om de NSG's en de bijbehorende regels te controleren met behulp van AKS:

  1. Zoek en selecteer virtuele-machineschaalsets in de Azure Portal.

  2. Selecteer in de lijst met schaalsetexemplaren de instantie die u gebruikt.

  3. Selecteer in het menuvenster van uw schaalsetexemplaren Networking.

De pagina Netwerken voor het exemplaar van de schaalset wordt weergegeven. Op het tabblad Regels voor binnenkomende poort worden twee sets regels weergegeven die zijn gebaseerd op de twee NSG's die werken op de schaalsetexemplaren:

  • De eerste set bestaat uit NSG-regels op subnetniveau. Deze regels worden weergegeven onder de volgende notitiekop:

    Netwerkbeveiligingsgroep <my-aks-nsg> (gekoppeld aan subnet: <my-aks-subnet>)

    Deze rangschikking is gebruikelijk als een aangepast virtueel netwerk en een aangepast subnet voor het AKS-cluster worden gebruikt. De set regels op subnetniveau kan lijken op de volgende tabel.

    Priority Naam Poort Protocol Source Destination Actie
    65000 AllowVnetInBound Alle Alle VirtualNetwork VirtualNetwork Toestaan
    65001 AllowAzureLoadBalancerInBound Alle Alle AzureLoadBalancer Alle Toestaan
    65500 DenyAllInBound Alle Alle Alle Alle Weigeren

  • De tweede set bestaat uit NSG-regels op het niveau van de netwerkadapter. Deze regels worden weergegeven onder de volgende notitiekop:

    Netwerkbeveiligingsgroep aks-agentpool-agentpool-number-nsg<> (gekoppeld aan de netwerkinterface: aks-agentpool-vm-scale-set-number-vmss<>)

    Deze NSG wordt toegepast door het AKS-cluster en wordt beheerd door AKS. De bijbehorende set regels kan lijken op de volgende tabel.

    Priority Naam Poort Protocol Source Destination Actie
    500 <guid-TCP-80-Internet> 80 TCP Internet 10.81.x.X Toestaan
    65000 AllowVnetInBound Alle Alle VirtualNetwork VirtualNetwork Toestaan
    65001 AllowAzureLoadBalancerInBound Alle Alle AzureLoadBalancer Alle Toestaan
    65500 DenyAllInBound Alle Alle Alle Alle Weigeren

Op het niveau van de netwerkadapter is er een NSG-regel voor binnenkomend verkeer voor TCP op IP-adres 10.81. x. x op poort 80 (gemarkeerd in de tabel). Er ontbreekt echter een equivalente regel in de regels voor de NSG op subnetniveau.

Waarom heeft AKS de regel niet toegepast op de aangepaste NSG? Omdat AKS geen NSG's toepast op het subnet en geen NSG's wijzigt die aan dat subnet zijn gekoppeld. AKS wijzigt de NSG's alleen op het niveau van de netwerkadapter. Zie Kan ik NSG's configureren met AKS? voor meer informatie.

Oplossing

Als de toepassing is ingeschakeld voor toegang op een bepaalde poort, moet u ervoor zorgen dat de aangepaste NSG die poort als regel Inbound toestaat. Nadat de juiste regel is toegevoegd in de aangepaste NSG op subnetniveau, is de toepassing toegankelijk.

$ 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

Contacteer ons voor hulp

Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Feedback-community van Azure.