En anpassad nätverkssäkerhetsgrupp blockerar trafik

Artikel
11/20/2024

När du får åtkomst till ett program som finns i ett AKS-kluster (Azure Kubernetes Service) får du felmeddelandet "Tidsgränsen har överskridit tidsgränsen". 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 får du "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 get, kubectl run- apt-getoch cURL-kommandon:

$ 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 klientbelastningsbalanserare >> >> 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 för att 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:er 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äkerhetsgrupp my-aks-nsg> (ansluten till undernätet: <my-aks-subnet>)<

Det här arrangemanget ä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	Källa	Mål	Action
65000	AllowVnetInBound	Valfri	Valfri	VirtualNetwork	VirtualNetwork	Tillåt
65001	AllowAzureLoadBalancerInBound	Valfri	Valfri	AzureLoadBalancer	Alla	Tillåt
65500	DenyAllInBound	Valfri	Valfri	Valfri	Valfri	Neka

Den andra uppsättningen består av NSG-regler på nätverkskortsnivå. Dessa regler visas under följande anteckningsrubrik:

Nätverkssäkerhetsgrupp 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	Källa	Mål	Action
500	<guid-TCP-80-Internet>	80	TCP	Internet	10.81.x.x	Tillåt
65000	AllowVnetInBound	Valfri	Valfri	VirtualNetwork	VirtualNetwork	Tillåt
65001	AllowAzureLoadBalancerInBound	Valfri	Valfri	AzureLoadBalancer	Alla	Tillåt
65500	DenyAllInBound	Valfri	Valfri	Valfri	Valfri	Neka

På nätverkskortsnivå finns det en NSG-regel för inkommande trafik 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å dess undernät och inte ändrar någon av de NSG:er som är associerade med det undernätet. AKS ändrar endast NSG:erna på nätverkskortsnivå. Mer information finns i Kan jag konfigurera NSG:er 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 lämplig 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.

Dela via