En anpassad nätverkssäkerhetsgrupp blockerar trafik
När du får åtkomst till ett program som finns i ett Azure Kubernetes Service -kluster (AKS) får du felmeddelandet "Tidsgränsen har överskridits". Det här felet kan inträffa även om programmet körs och resten av konfigurationen verkar vara korrekt.
Förutsättningar
Kubernetes kubectl-verktyget eller ett liknande verktyg för att ansluta till klustret. Om du vill installera kubectl med hjälp av Azure CLI kör du kommandot az aks install-cli .
Verktyget Klient-URL (cURL) eller ett liknande kommandoradsverktyg.
Kommandoradsverktyget apt-get för hantering av paket.
Symptom
Om du kör följande kubectl get - och cURL-kommandon uppstår "Timeout"-fel som liknar följande konsolutdata:
$ 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
Orsak
Om du får samma "timeout"-fel varje gång tyder det vanligtvis på att en nätverkskomponent blockerar trafiken.
Om du vill felsöka det här problemet kan du börja med att kontrollera åtkomsten till podden och sedan gå vidare till klienten i en inifrån och ut-metod .
Kontrollera podden genom att köra följande kubectl get kommandon och 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
Baserat på dessa utdata verkar podden köras korrekt, utan några omstarter.
Öppna en testpodd för att kontrollera åtkomsten till programpodden. Kör följande kubectl getkommandon , kubectl run, apt-getoch cURL:
$ 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
Podden är tillgänglig direkt. Därför körs programmet.
Den definierade tjänsten är en LoadBalancer typ. Det innebär att begärandeflödet från slutklienten till podden blir följande:
AKS-nod >> för klientlastbalanserare >>>> Programpodd
I det här begärandeflödet kan vi blockera trafiken via följande komponenter:
- Nätverksprinciper i klustret
- Nätverkssäkerhetsgruppen (NSG) för AKS-undernätet och AKS-noden
Kontrollera nätverksprincipen genom att köra följande kubectl get kommando:
$ kubectl get networkpolicy --all-namespaces
NAMESPACE NAME POD-SELECTOR AGE
kube-system konnectivity-agent app=konnectivity-agent 3h8m
Endast AKS-standardprincipen finns. Därför verkar inte nätverksprincipen blockera trafiken.
Följ dessa steg om du vill kontrollera NSG:erna och deras associerade regler med hjälp av AKS:
I Azure Portal söker du efter och väljer Vm-skalningsuppsättningar.
I listan över skalningsuppsättningsinstanser väljer du den som du använder.
I menyfönstret i din skalningsuppsättningsinstans väljer du
Networking.
Sidan Nätverk för skalningsuppsättningsinstansen visas. På fliken Regler för inkommande portar visas två uppsättningar regler som baseras på de två NSG:erna som fungerar på skalningsuppsättningsinstansen:
Den första uppsättningen består av NSG-regler på undernätsnivå. Dessa regler visas under följande anteckningsrubrik:
Nätverkssäkerhetsgruppen <my-aks-nsg> (ansluten till undernätet: <my-aks-subnet>)
Det här är vanligt om ett anpassat virtuellt nätverk och ett anpassat undernät för AKS-klustret används. Regeluppsättningen på undernätsnivå kan likna följande tabell.
Prioritet Namn Port Protokoll Source Destination Åtgärd 65000 AllowVnetInBound ANY ANY VirtualNetwork VirtualNetwork Tillåt 65001 AllowAzureLoadBalancerInBound ANY ANY AzureLoadBalancer ANY Tillåt 65500 DenyAllInBound ANY ANY ANY ANY Förneka Den andra uppsättningen består av NSG-regler på nätverkskortsnivå. Dessa regler visas under följande anteckningsrubrik:
Nätverkssäkerhetsgruppen aks-agentpool-agentpool-number-nsg<> (ansluten till nätverksgränssnittet: aks-agentpool-vm-scale-set-number-vmss<>)
Den här NSG:n tillämpas av AKS-klustret och hanteras av AKS. Motsvarande regeluppsättning kan likna följande tabell.
Prioritet Namn Port Protokoll Source Destination Åtgärd 500 <guid-TCP-80-Internet> 80 TCP Internet 10.81.x.X Tillåt 65000 AllowVnetInBound ANY ANY VirtualNetwork VirtualNetwork Tillåt 65001 AllowAzureLoadBalancerInBound ANY ANY AzureLoadBalancer ANY Tillåt 65500 DenyAllInBound ANY ANY ANY ANY Förneka
På nätverkskortsnivå finns det en inkommande NSG-regel för TCP på IP-adress 10.81. x. x på port 80 (markerad i tabellen). En motsvarande regel saknas dock i reglerna för NSG på undernätsnivå.
Varför tillämpade inte AKS regeln på den anpassade NSG:n? Eftersom AKS inte tillämpar NSG:er på sitt undernät och det inte ändrar någon av de NSG:er som är associerade med det undernätet. AKS ändrar endast nätverkssäkerhetsgrupperna på nätverkskortsnivå. Mer information finns i Kan jag konfigurera nätverkssäkerhetsgrupper med AKS?.
Lösning
Om programmet är aktiverat för åtkomst på en viss port måste du se till att den anpassade NSG:n tillåter den porten som regel Inbound . När rätt regel har lagts till i den anpassade NSG:n på undernätsnivå är programmet tillgängligt.
$ 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
Kontakta oss för att få hjälp
Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för