Grundlegende Problembehandlung bei aus einem AKS-Cluster ausgehenden Verbindungen

Artikel
12/18/2024

In diesem Artikel wird erläutert, wie Sie grundlegende Problembehandlung für ausgehende Verbindungen von einem Microsoft Azure Kubernetes Service (AKS)-Cluster durchführen und fehlerhafte Komponenten identifizieren.

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 Apt-get-Befehlszeilentool zum Behandeln von Paketen.
Das Client-URL-Tool (cURL) oder ein ähnliches Befehlszeilentool.
Das nslookup Befehlszeilentool (dnsutils) zum Überprüfen der DNS-Auflösung.

Szenarien für ausgehenden Datenverkehr im Azure Kubernetes-Dienst

Datenverkehr, der aus dem AKS-Cluster stammt, unabhängig davon, ob es sich um einen Pod oder einen Workerknoten handelt, wird als ausgehender Datenverkehr aus dem Cluster betrachtet. Was geschieht, wenn ein Problem im ausgehenden Fluss für einen AKS-Cluster besteht? Sehen Sie sich vor der Problembehandlung zuerst die Szenarien für den ausgehenden Datenverkehrsfluss an.

Der ausgehende Datenverkehr von einem AKS-Cluster kann in die folgenden Kategorien unterteilt werden:

Datenverkehr zu einem Pod oder Dienst im selben Cluster (interner Datenverkehr)
Datenverkehr zu einem Gerät oder Endpunkt im selben virtuellen Netzwerk oder einem anderen virtuellen Netzwerk, das virtuelle Netzwerk-Peering verwendet.
Datenverkehr zu einer lokalen Umgebung über eine VPN-Verbindung oder eine Azure ExpressRoute-Verbindung.
Datenverkehr außerhalb des AKS-Netzwerks über Azure Load Balancer (öffentlicher ausgehender Datenverkehr)
Datenverkehr außerhalb des AKS-Netzwerks über die Azure-Firewall oder einen Proxyserver (öffentlicher ausgehender Datenverkehr)

Interner Datenverkehr

Ein grundlegender Anforderungsfluss für internen Datenverkehr von einem AKS-Cluster ähnelt dem Fluss, der im folgenden Diagramm dargestellt wird.

Öffentlicher ausgehender Datenverkehr über Azure Load Balancer

Wenn der Datenverkehr für ein Ziel im Internet gilt, besteht die Standardmethode darin, den Datenverkehr über den Azure Load Balancer zu senden.

Öffentlicher ausgehender Datenverkehr über die Azure-Firewall oder einen Proxyserver

In einigen Fällen muss der Ausgehende Datenverkehr gefiltert werden, und er erfordert möglicherweise azure Firewall.

Ein Benutzer möchte möglicherweise einen Proxyserver anstelle einer Firewall hinzufügen oder ein NAT-Gateway für den Ausgehenden Datenverkehr einrichten. Der grundlegende Fluss bleibt unverändert wie im Diagramm dargestellt.

Es ist wichtig, die Art des Ausgangsflusses für Ihren Cluster zu verstehen, damit Sie mit der Problembehandlung fortfahren können.

Überlegungen bei der Problembehandlung

Überprüfen Des Ausgangsgeräts

Wenn Sie probleme mit ausgehendem Datenverkehr in AKS beheben, ist es wichtig zu wissen, was Ihr Ausgangsgerät ist (d. h. das Gerät, über das der Datenverkehr übergeht). Hier kann das Ausgangsgerät eine der folgenden Komponenten sein:

Azure-Lastenausgleich
Azure Firewall oder eine benutzerdefinierte Firewall
Ein NAT-Gateway (Network Address Translation)
Ein Proxyserver

Der Fluss kann sich auch je nach Ziel unterscheiden. Der interne Datenverkehr (d. h. innerhalb des Clusters) durchläuft z. B. nicht das Ausgangsgerät. Der interne Datenverkehr würde nur das Clusternetzwerk verwenden. Ermitteln Sie bei öffentlichem ausgehenden Datenverkehr, ob ein Übergabegerät vorhanden ist, und überprüfen Sie dieses Gerät.

Überprüfen der einzelnen Hops innerhalb des Datenverkehrsflusses

Überprüfen Sie nach dem Identifizieren des Ausgangsgeräts die folgenden Faktoren:

Die Quelle und das Ziel für die Anforderung.
Die Hops zwischen der Quelle und dem Ziel.
Der Anforderungsantwortfluss.
Die Hops, die durch zusätzliche Sicherheitsebenen verbessert werden, z. B. die folgenden Ebenen:
- Firewall
- Netzwerksicherheitsgruppe (NSG)
- Netzwerkrichtlinie

Um einen problematischen Hop zu identifizieren, überprüfen Sie die Antwortcodes vor und nach ihr. Um zu überprüfen, ob die Pakete in einem bestimmten Hop ordnungsgemäß ankommen, können Sie mit Paketerfassungen fortfahren.

Überprüfen von HTTP-Antwortcodes

Wenn Sie jede Komponente überprüfen, rufen Sie HTTP-Antwortcodes ab und analysieren sie. Diese Codes sind nützlich, um die Art des Problems zu identifizieren. Die Codes sind besonders hilfreich in Szenarien, in denen die Anwendung auf HTTP-Anforderungen reagiert.

Erfassen von Paketen vom Client und Server

Wenn andere Schritte zur Problembehandlung kein abschließendes Ergebnis liefern, nehmen Sie Paketerfassungen vom Client und Server ab. Paketerfassungen sind auch hilfreich, wenn nicht-HTTP-Datenverkehr zwischen Client und Server beteiligt ist. Weitere Informationen zum Sammeln von Paketerfassungen für die AKS-Umgebung finden Sie in den folgenden Artikeln im Leitfaden zur Datensammlung:

Problembehandlung von Checklisten

Führen Sie die folgenden Schritte aus, um grundlegende Problembehandlung für den Datenverkehr von einem AKS-Cluster zu erhalten:

Stellen Sie sicher, dass die DNS-Auflösung (Domain Name System) für den Endpunkt ordnungsgemäß funktioniert.
Stellen Sie sicher, dass Sie den Endpunkt über eine IP-Adresse erreichen können.
Stellen Sie sicher, dass Sie den Endpunkt aus einer anderen Quelle erreichen können.
Stellen Sie sicher, dass der Endpunkt funktioniert.
Überprüfen Sie, ob der Cluster einen anderen externen Endpunkt erreichen kann.
Überprüfen Sie, ob eine Netzwerkrichtlinie den Datenverkehr blockiert.
Überprüfen Sie, ob eine NSG den Datenverkehr blockiert.
Überprüfen Sie, ob eine Firewall oder ein Proxy den Datenverkehr blockiert.
Überprüfen Sie, ob der AKS-Dienstprinzipal oder die verwaltete Identität über die erforderlichen AKS-Dienstberechtigungen verfügt, um die Netzwerkänderungen an Azure-Ressourcen vorzunehmen.

Notiz

Geht davon aus, dass kein Dienstgitter vorhanden ist, wenn Sie grundlegende Problembehandlung ausführen. Wenn Sie ein Dienstgitter wie Istio verwenden, erzeugt es ungewöhnliche Ergebnisse für TCP-basierten Datenverkehr.

Überprüfen, ob der Pod und der Knoten den Endpunkt erreichen können

Innerhalb des Pods können Sie eine DNS-Suche für den Endpunkt ausführen.

Was geschieht, wenn Sie den Befehl kubectl exec nicht ausführen können, um eine Verbindung mit dem Pod herzustellen und das DNS Utils-Paket zu installieren? In diesem Fall können Sie einen Testpod im selben Namespace wie der problematische Pod starten und dann die Tests ausführen.

Hinweis

Wenn die DNS-Auflösung oder der ausgehende Datenverkehr die Installation der erforderlichen Netzwerkpakete verhindert, können Sie das Docker-Image rishasi/ubuntu-netutil:1.0 verwenden. In diesem Image sind die erforderlichen Pakete bereits installiert.

Beispiel für die Überprüfung der DNS-Auflösung eines Linux-Pods

Starten Sie einen Testpod im selben Namespace wie der problematische Pod:

kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "linux"}}}'

Sobald der Testpod ausgeführt wird, erhalten Sie Zugriff auf den Pod.

Führen Sie die folgenden apt-get-Befehle aus, um andere Toolpakete zu installieren:

# Update and install tool packages
apt-get update && apt-get install -y dnsutils curl

Führen Sie nach der Installation der Pakete den Befehl nslookup aus, um die DNS-Auflösung für den Endpunkt zu testen:

$ nslookup microsoft.com # Microsoft.com is used as an example
Server:         <server>
Address:        <server IP address>#53
...
...
Name:   microsoft.com
Address: 20.53.203.50

Probieren Sie die DNS-Auflösung vom Upstream-DNS-Server direkt aus. In diesem Beispiel wird Azure DNS verwendet:

$ nslookup microsoft.com 168.63.129.16
Server:         168.63.129.16
Address:        168.63.129.16#53
...
...
Address: 20.81.111.85

Manchmal gibt es ein Problem mit dem Endpunkt selbst und nicht mit einem Cluster-DNS. Berücksichtigen Sie in solchen Fällen die folgenden Prüfungen:

Überprüfen Sie, ob der gewünschte Port auf dem Remotehost geöffnet ist:
```
curl -Ivm5 telnet://microsoft.com:443
```
Überprüfen Sie den HTTP-Antwortcode:
```
curl -Ivm5 https://microsoft.com
```
Überprüfen Sie, ob Sie eine Verbindung mit einem anderen Endpunkt herstellen können:
```
curl -Ivm5 https://kubernetes.io
```

Führen Sie die folgenden Schritte aus, um zu überprüfen, ob der Endpunkt vom Knoten aus erreichbar ist, in dem sich der problematische Pod befindet, und dann die DNS-Einstellungen überprüfen:

Geben Sie den Knoten ein, in dem sich der problematische Pod im Debug-Pod befindet. Weitere Informationen dazu finden Sie unter Herstellen einer Verbindung mit Azure Kubernetes Service (AKS)-Clusterknoten zur Wartung oder Problembehandlung.

Testen Sie die DNS-Auflösung an den Endpunkt:

$ nslookup  microsoft.com
Server:         168.63.129.16
Address:        168.63.129.16#53

Non-authoritative answer:
Name:   microsoft.com
Address: 20.112.52.29
Name:   microsoft.com
Address: 20.81.111.85
Name:   microsoft.com
Address: 20.84.181.62
Name:   microsoft.com
Address: 20.103.85.33
Name:   microsoft.com
Address: 20.53.203.50

Überprüfen Sie die Datei resolv.conf , um zu ermitteln, ob die erwarteten Namenserver hinzugefügt werden:
```
cat /etc/resolv.conf
cat /run/systemd/resolve/resolv.conf
```

Beispiel für die Überprüfung der DNS-Auflösung eines Windows-Pods

Führen Sie einen Testpod im Windows-Knotenpool aus:

# For a Windows environment, use the Resolve-DnsName cmdlet.
kubectl run dnsutil-win --image='mcr.microsoft.com/windows/servercore:ltsc2022' --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "windows"}}}' -- powershell "Start-Sleep -s 3600"

Führen Sie den Befehl kubectl exec aus, um mithilfe von PowerShell eine Verbindung mit dem Pod herzustellen:
```
kubectl exec -it dnsutil-win -- powershell
```

Führen Sie das Cmdlet Resolve-DnsName in PowerShell aus, um zu überprüfen, ob die DNS-Auflösung für den Endpunkt funktioniert:

PS C:\> Resolve-DnsName www.microsoft.com 

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
www.microsoft.com              CNAME  20    Answer     www.microsoft.com-c-3.edgekey.net
www.microsoft.com-c-3.edgekey. CNAME  20    Answer     www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net
net
www.microsoft.com-c-3.edgekey. CNAME  20    Answer     e13678.dscb.akamaiedge.net
net.globalredir.akadns.net

Name       : e13678.dscb.akamaiedge.net 
QueryType  : AAAA
TTL        : 20
Section    : Answer
IP6Address : 2600:1408:c400:484::356e   


Name       : e13678.dscb.akamaiedge.net 
QueryType  : AAAA
TTL        : 20
Section    : Answer
IP6Address : 2600:1408:c400:496::356e 


Name       : e13678.dscb.akamaiedge.net
QueryType  : A
TTL        : 12
Section    : Answer
IP4Address : 23.200.197.152

In einem ungewöhnlichen Szenario, das die DNS-Auflösung umfasst, erhalten die DNS-Abfragen eine richtige Antwort vom Knoten, schlagen jedoch vom Pod fehl. In diesem Szenario empfiehlt es sich , DNS-Auflösungsfehler innerhalb des Pods, aber nicht vom Workerknoten zu überprüfen. Wenn Sie die DNS-Auflösung für einen Endpunkt im gesamten Cluster überprüfen möchten, können Sie erwägen , den DNS-Auflösungsstatus im gesamten Cluster zu überprüfen.

Wenn die DNS-Auflösung erfolgreich ist, fahren Sie mit den Netzwerktests fort. Überprüfen Sie andernfalls die DNS-Konfiguration für den Cluster.

Haftungsausschluss für Kontaktinformationen von Drittanbietern

Die Kontaktinformationen zu den in diesem Artikel erwähnten Drittanbietern sollen Ihnen helfen, zusätzliche Informationen zu diesem Thema zu finden. Diese Kontaktinformationen können ohne vorherige Ankündigung geändert werden. Sie werden von Microsoft ohne jede Gewähr weitergegeben.

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.

Freigeben über