Eine benutzerdefinierte Netzwerksicherheitsgruppe blockiert Datenverkehr
Wenn Sie auf eine Anwendung zugreifen, die auf einem Azure Kubernetes Service (AKS)-Cluster gehostet wird, wird die Fehlermeldung "Timeout" angezeigt. Dieser Fehler kann auch auftreten, wenn die Anwendung ausgeführt wird und der Rest der Konfiguration korrekt zu sein scheint.
Voraussetzungen
Das Kubernetes-Kubectl-Tool oder ein ähnliches Tool, um eine Verbindung mit dem Cluster herzustellen. Um kubectl mithilfe von Azure CLI zu installieren, führen Sie den az aks install-cli-Befehl aus.
Das Client-URL-Tool (cURL) oder ein ähnliches Befehlszeilentool.
Das apt-get-Befehlszeilentool für die Behandlung von Paketen.
Problembeschreibung
Wenn Sie die folgenden kubectl get - und cURL-Befehle ausführen, treten "Timeout"-Fehler auf, die der folgenden Konsolenausgabe ähneln:
$ 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
Ursache
Wenn jedes Mal der gleiche "Timeout"-Fehler auftritt, deutet dies in der Regel darauf hin, dass eine Netzwerkkomponente den Datenverkehr blockiert.
Um dieses Problem zu beheben, können Sie zunächst den Zugriff auf den Pod überprüfen und dann mit einem Inside-Out-Ansatz zum Client wechseln.
Führen Sie zum Überprüfen des Pod die folgenden kubectl get Befehle aus, und beschreiben Sie kubectl :
$ 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
Basierend auf dieser Ausgabe scheint der Pod ordnungsgemäß ausgeführt zu werden, ohne neustarts.
Öffnen Sie einen Test-Pod, um den Zugriff auf den Anwendungs-Pod zu überprüfen. Führen Sie die folgenden kubectl getBefehle , kubectl runapt-get und cURL aus:
$ 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 # 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
Der Pod ist direkt zugänglich. Daher wird die Anwendung ausgeführt.
Der definierte Dienst ist ein LoadBalancer Typ. Dies bedeutet, dass der Anforderungsfluss vom Endclient zum Pod wie folgt aussieht:
Client >> Load balancer >> AKS node >> Application pod
In diesem Anforderungsfluss können wir den Datenverkehr über die folgenden Komponenten blockieren:
- Netzwerkrichtlinien im Cluster
- Die Netzwerksicherheitsgruppe (NSG) für das AKS-Subnetz und den AKS-Knoten
Führen Sie zum Überprüfen der Netzwerkrichtlinie den folgenden kubectl get Befehl aus:
$ kubectl get networkpolicy --all-namespaces
NAMESPACE NAME POD-SELECTOR AGE
kube-system konnectivity-agent app=konnectivity-agent 3h8m
Nur die AKS-Standardrichtlinie ist vorhanden. Daher scheint die Netzwerkrichtlinie den Datenverkehr nicht zu blockieren.
Führen Sie die folgenden Schritte aus, um die NSGs und die zugehörigen Regeln mithilfe von AKS zu überprüfen:
Suchen Sie in der Azure-Portal nach virtuellen Computermaßstabsätzen, und wählen Sie sie aus.
Wählen Sie in der Liste der Instanzen für Skalierungssätze die instanzen aus, die Sie verwenden.
Wählen Sie im Menübereich Ihrer Skalierungssatzinstanz die Option
Networkingaus.
Die Seite "Netzwerk" für die Skalierungssatzinstanz wird angezeigt. Auf der Registerkarte " Regeln für eingehende Portierung " werden zwei Regelsätze angezeigt, die auf den beiden NSGs basieren, die auf der Skalierungssatzinstanz agieren:
Der erste Satz besteht aus NSG-Regeln auf Subnetzebene. Diese Regeln werden unter der folgenden Notizüberschrift angezeigt:
Netzwerksicherheitsgruppe <my-aks-nsg> (an Subnetz angefügt: <my-aks-subnet>)
Diese Anordnung ist üblich, wenn ein benutzerdefiniertes virtuelles Netzwerk und ein benutzerdefiniertes Subnetz für den AKS-Cluster verwendet werden. Der Regelsatz auf Subnetzebene kann der folgenden Tabelle ähneln.
Priorität Name Port Protokoll Source Ziel Aktion 65000 AllowVnetInBound Beliebig Beliebig VirtualNetwork VirtualNetwork Zulassen 65001 AllowAzureLoadBalancerInBound Beliebig Beliebig AzureLoadBalancer Beliebig Zulassen 65500 DenyAllInBound Beliebig Beliebig Beliebig Beliebig Verweigern Der zweite Satz besteht aus NSG-Regeln auf Netzwerkadapterebene. Diese Regeln werden unter der folgenden Notizüberschrift angezeigt:
Netzwerksicherheitsgruppe aks-agentpool-<agentpool-number>-nsg (an Netzwerkschnittstelle angefügt: aks-agentpool-<vm-scale-set-number>-vmss)
Diese NSG wird vom AKS-Cluster angewendet und von AKS verwaltet. Der entsprechende Regelsatz kann der folgenden Tabelle ähneln.
Priorität Name Port Protokoll Source Ziel Aktion 500 <guid>-TCP-80-Internet 80 TCP Internet 10.81.x.x Zulassen 65000 AllowVnetInBound Any Beliebig VirtualNetwork VirtualNetwork Zulassen 65001 AllowAzureLoadBalancerInBound Beliebig Beliebig AzureLoadBalancer Beliebig Zulassen 65500 DenyAllInBound Beliebig Beliebig Any Any Verweigern
Auf Netzwerkadapterebene gibt es eine NSG-Eingangsregel für TCP unter ip-Adresse 10.81. x. x an Port 80 (in der Tabelle hervorgehoben). Eine entsprechende Regel fehlt jedoch in den Regeln für die NSG auf Subnetzebene.
Warum hat AKS die Regel nicht auf die benutzerdefinierte NSG angewendet? Da AKS keine NSGs auf sein Subnetz anwendet und keine der NSGs ändert, die diesem Subnetz zugeordnet sind. AKS ändert die NSGs nur auf Netzwerkadapterebene. Weitere Informationen finden Sie unter "Kann ich NSGs mit AKS konfigurieren?".
Lösung
Wenn die Anwendung für den Zugriff auf einen bestimmten Port aktiviert ist, müssen Sie sicherstellen, dass der benutzerdefinierte NSG diesen Port in der Inbound Regel zulässt. Nachdem die entsprechende Regel in der benutzerdefinierten NSG auf Subnetzebene hinzugefügt wurde, kann auf die Anwendung zugegriffen werden.
$ 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