Een aangepaste netwerkbeveiligingsgroep blokkeert verkeer
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
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 opdrachtregelprogramma apt-get voor het verwerken van pakketten.
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:
Zoek en selecteer virtuele-machineschaalsets in de Azure Portal.
Selecteer in de lijst met schaalsetexemplaren de instantie die u gebruikt.
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.
Feedback
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie: https://aka.ms/ContentUserFeedback.
Feedback verzenden en weergeven voor