Eine benutzerdefinierte Netzwerksicherheitsgruppe blockiert den Datenverkehr
Wenn Sie auf eine Anwendung zugreifen, die auf einem Azure Kubernetes Service (AKS)-Cluster gehostet wird, erhalten Sie eine Fehlermeldung "Timed out". Dieser Fehler kann auch dann auftreten, wenn die Anwendung ausgeführt wird, und die restliche Konfiguration scheint korrekt zu sein.
Voraussetzungen
Das Kubernetes-Kubectl-Tool oder ein ähnliches Tool zum Herstellen einer Verbindung mit dem Cluster. Führen Sie zum Installieren von Kubectl mithilfe der Azure CLI den Befehl "az aks install-cli " aus.
Das Client-URL-Tool (cURL) oder ein ähnliches Befehlszeilentool.
Das Apt-get-Befehlszeilentool zum Behandeln von Paketen.
Symptome
Wenn Sie die folgenden Kubectl-Get - und cURL-Befehle ausführen, treten Fehler beim Timedout 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 derselbe Timeoutfehler auftritt, schlägt dies in der Regel vor, dass eine Netzwerkkomponente den Datenverkehr blockiert.
Um dieses Problem zu beheben, können Sie beginnen, indem Sie den Zugriff auf den Pod überprüfen und dann in einem inside-out-Ansatz mit dem Client fortfahren.
Um den Pod zu überprüfen, führen Sie die folgenden kubectl get Befehle aus, und kubectl beschreiben Befehle:
$ 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 ohne Neustarts ordnungsgemäß ausgeführt zu werden.
Öffnen Sie einen Test pod, um den Zugriff auf den Anwendungs-Pod zu überprüfen. Führen Sie die folgenden kubectl getBefehle , kubectl run, apt-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: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
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 lautet:
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 (Network Security Group, NSG) für den AKS-Subnetz- und 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 im Azure-Portal nach Skalierungssätzen für virtuelle Computer, und wählen Sie sie aus.
Wählen Sie in der Liste der Skalierungssatzinstanzen die von Ihnen verwendete Instanz aus.
Wählen Sie im Menübereich Ihrer Skalierungssatzinstanz die Option
Networkingaus.
Die Seite Netzwerk für die Skalierungsgruppeninstanz 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 reagieren:
Der erste Satz besteht aus NSG-Regeln auf Subnetzebene. Diese Regeln werden unter der folgenden Notizüberschrift angezeigt:
Netzwerksicherheitsgruppe <my-aks-nsg> (angefügt an Subnetz: <my-aks-subnet>)
Diese Anordnung ist üblich, wenn ein benutzerdefiniertes virtuelles Netzwerk und ein benutzerdefiniertes Subnetz für den AKS-Cluster verwendet werden. Der Satz von Regeln auf Subnetzebene ähnelt möglicherweise der folgenden Tabelle.
Priority Name Port Protokoll Quelle Ziel Aktion 65000 AllowVnetInBound Any Any VirtualNetwork VirtualNetwork Allow 65001 AllowAzureLoadBalancerInBound Any Any AzureLoadBalancer Any Allow 65500 DenyAllInBound Any Any Any Any 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<> (angefügt an die Netzwerkschnittstelle: aks-agentpool-vm-scale-set-number-vmss)<>
Diese NSG wird vom AKS-Cluster angewendet und von AKS verwaltet. Die entsprechenden Regelsätze können der folgenden Tabelle ähneln.
Priority Name Port Protokoll Quelle Ziel Aktion 500 <guid-TCP-80-Internet> 80 TCP Internet 10.81.x.x Zulassen 65000 AllowVnetInBound Any Any VirtualNetwork VirtualNetwork Allow 65001 AllowAzureLoadBalancerInBound Any Any AzureLoadBalancer Any Allow 65500 DenyAllInBound Any Any Any Any Verweigern
Auf Netzwerkadapterebene gibt es eine NSG-Eingehende Regel für TCP unter IP-Adresse 10.81.x.x am 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 das 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 als 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
Kontaktieren Sie uns für Hilfe
Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.