Een aangepaste netwerkbeveiligingsgroep blokkeert verkeer

Artikel
11/20/2024

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

Voorwaarden

Het Kubernetes kubectl-hulpprogramma , of een vergelijkbaar hulpprogramma, om verbinding te maken met het cluster. Als u kubectl wilt installeren met behulp van Azure CLI, voert u de opdracht az aks install-cli uit.
Het hulpprogramma Client-URL (cURL) of een vergelijkbaar opdrachtregelprogramma.
Het apt-get-opdrachtregelprogramma voor het verwerken van pakketten.

Symptomen

Als u de volgende kubectl get - en cURL-opdrachten uitvoert, ondervindt u time-outfouten 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 foutmelding 'Time-out' ondervindt, betekent dit meestal dat een netwerkonderdeel het verkeer blokkeert.

Om dit probleem op te lossen, kunt u beginnen met het controleren van de toegang tot de pod en vervolgens verdergaan met de client in een interne benadering.

Voer de volgende kubectl get en kubectl-beschrijvende opdrachten uit om de pod te controleren:

$ 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 getkubectl-run- apt-geten cURL-opdrachten 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 als volgt is:

AKS-knooppunttoepassingspod >> voor client >> load balancer >>

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 het netwerkbeleid het verkeer niet te blokkeren.

Volg deze stappen om de NSG's en de bijbehorende regels te controleren met behulp van AKS:

Zoek en selecteer virtuele-machineschaalsets in Azure Portal.
Selecteer in de lijst met schaalsetexemplaren het exemplaar dat u gebruikt.
Selecteer Networkingin het menuvenster van uw exemplaar van de schaalset.

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

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 aangepast subnet voor het AKS-cluster worden gebruikt. De set regels op subnetniveau lijkt mogelijk op de volgende tabel.

Prioriteit	Name	Poort	Protocol	Bron	Doel	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 netwerkadapterniveau. 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 lijkt mogelijk op de volgende tabel.

Prioriteit	Name	Poort	Protocol	Bron	Doel	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 netwerkadapterniveau is er een inkomende NSG-regel 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 er geen NSG's worden gewijzigd die aan dat subnet zijn gekoppeld. AKS wijzigt de NSG's alleen op netwerkadapterniveau. 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 deze poort als regel Inbound toestaat. Nadat de juiste regel is toegevoegd aan 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 Azure-feedbackcommunity.

Delen via