Freigeben über

Grundlegende Problembehandlung bei ausgehenden Verbindungen aus einem AKS-Cluster

  • Artikel

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

Voraussetzungen

Szenarien für ausgehenden Datenverkehr in Azure Kubernetes Service

In jedem Netzwerkszenario sollten Sie bei der Problembehandlung die folgenden Faktoren berücksichtigen:

  • Die Quelle und das Ziel für die Anforderung.

  • Die Hops zwischen der Quelle und dem Ziel.

  • Der Anforderungs-Antwort-Flow.

  • Die Hops, die durch zusätzliche Sicherheitsebenen erweitert werden, z. B. die folgenden Ebenen:

    • Firewall
    • Netzwerksicherheitsgruppe (NSG)
    • Netzwerkrichtlinie

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 antwortet.

Wenn andere Schritte zur Problembehandlung kein schlüssiges Ergebnis liefern, nehmen Sie Paketerfassungen vom Client und Server ab. Paketerfassungen sind auch nützlich, 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:

Wenn Sie wissen, wie Sie die HTTP-Antwortcodes abrufen und Paketerfassungen durchführen, ist es einfacher, ein Netzwerkkonnektivitätsproblem zu beheben.

Datenverkehr, der aus dem AKS-Cluster stammt, unabhängig davon, ob er von einem Pod oder einem Workerknoten stammt, wird als ausgehender Datenverkehr aus dem Cluster betrachtet. Was geschieht, wenn ein Problem im ausgehenden Flow für einen AKS-Cluster vorliegt? Bevor Sie die Problembehandlung durchführen, sollten Sie sich zunächst mit der Art des Anforderung-Antwort-Flows vertraut machen.

Der ausgehende Datenverkehr aus einem AKS-Cluster kann in die folgenden Kategorien klassifiziert werden:

  1. Datenverkehr zu einem Pod oder Dienst im selben Cluster (interner Datenverkehr)

  2. Datenverkehr zu einem Gerät oder Endpunkt im selben virtuellen Netzwerk oder in einem anderen virtuellen Netzwerk (das Peering virtueller Netzwerke verwendet)

  3. Datenverkehr zu einer lokalen Umgebung über eine VPN-Verbindung oder eine Azure ExpressRoute-Verbindung

  4. Datenverkehr außerhalb des AKS-Netzwerks (öffentlicher ausgehender Datenverkehr)

In diesem Dokument werden grundlegende Schritte zur Problembehandlung für Probleme behandelt, die sich auf die ausgehende Konnektivität auswirken:

  • Innerhalb des Clusters
  • Innerhalb der virtuellen Netzwerke
  • Nach außen (öffentlicher Verkehr)

Bei der Problembehandlung für ausgehenden Datenverkehr in AKS ist es auch wichtig zu wissen, was Ihr ausgehendes Gerät ist (d. h. das Gerät, über das der Datenverkehr fließt). Hier kann das Ausgangsgerät eine der folgenden Komponenten sein:

  • Azure Load Balancer
  • Azure Firewall oder eine benutzerdefinierte Firewall
  • Ein NAT-Gateway (Network Address Translation, Netzwerkadressenübersetzung)
  • Ein Proxyserver

Der Flow kann sich auch je nach Ziel unterscheiden. Beispielsweise erfolgt interner Datenverkehr (d. h. innerhalb des Clusters) nicht über das ausgehende Gerät. Der interne Datenverkehr würde nur das Clusternetzwerk verwenden.

Interner Datenverkehr

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

Diagramm eines grundlegenden Anforderungsflusses für internen Datenverkehr aus einem AKS-Cluster (Microsoft Azure Kubernetes Service).

Externer 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.

Diagramm eines Anforderungsflusses für externen Internetdatenverkehr über Azure Load Balancer aus einem AKS-Cluster (Microsoft Azure Kubernetes Service).

Externer Datenverkehr über Azure Firewall oder einen Proxyserver

In einigen Fällen muss der ausgehende Datenverkehr gefiltert werden, und dies erfordert möglicherweise Azure Firewall.

Diagramm eines Anforderungsflusses für externen Internetdatenverkehr über Azure Firewall aus einem AKS-Cluster (Microsoft Azure Kubernetes Service).

Anstelle einer Firewall möchte ein Benutzer möglicherweise einen Proxyserver hinzufügen. Oder der Benutzer möchte ein NAT-Gateway für ausgehenden Datenverkehr einrichten. Der grundlegende Flow bleibt der gleiche wie im Diagramm dargestellt.

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

Checkliste zur Problembehandlung

Führen Sie für die grundlegende Problembehandlung für ausgehenden Datenverkehr aus einem AKS-Cluster die folgenden Schritte aus:

  1. Stellen Sie sicher, dass die DNS-Auflösung (Domain Name System) für den Endpunkt ordnungsgemäß funktioniert.

  2. Stellen Sie sicher, dass Sie den Endpunkt über eine IP-Adresse erreichen können.

  3. Stellen Sie sicher, dass Sie den Endpunkt aus einer anderen Quelle erreichen können.

  4. Stellen Sie sicher, dass der Endpunkt funktioniert.

  5. Überprüfen Sie, ob der Cluster einen anderen externen Endpunkt erreichen kann.

  6. Überprüfen Sie, ob eine Netzwerkrichtlinie den Datenverkehr blockiert.

  7. Überprüfen Sie, ob eine NSG den Datenverkehr blockiert.

  8. Überprüfen Sie, ob eine Firewall oder ein Proxy den Datenverkehr blockiert.

  9. Ü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.

Überprüfen, ob die DNS-Auflösung für den Endpunkt erfolgreich ist

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 gleichen Namespace wie der problematische Pod starten und dann die Tests ausführen.

Hinweis

Wenn Sie aufgrund der DNS-Auflösung oder des ausgehenden Datenverkehrs die erforderlichen Netzwerkpakete nicht installieren können, können Sie das rishasi/ubuntu-netutil:1.0 Docker-Image verwenden. In diesem Image sind die erforderlichen Pakete bereits installiert.

Hier ist ein Beispiel für die Überprüfung der DNS-Auflösung:

  1. Starten Sie einen Testpod im gleichen Namespace wie der problematische Pod:

    kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable

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

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

    apt-get update -y
apt-get install dnsutils -y
apt-get install curl -y
apt-get install netcat -y

  3. 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
Server:         10.0.0.10
Address:        10.0.0.10#53
...
...
Name:   microsoft.com
Address: 20.53.203.50

  4. Probieren Sie die DNS-Auflösung direkt vom Upstream-DNS-Server 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

  5. Führen Sie den host Befehl aus, um zu überprüfen, ob die DNS-Anforderungen an den Upstreamserver weitergeleitet werden:

    $ host -a microsoft.com
Trying "microsoft.com.default.svc.cluster.local"
Trying "microsoft.com.svc.cluster.local"
Trying "microsoft.com.cluster.local"
Trying "microsoft.com.00idcnmrrm4edot5s2or1onxsc.bx.internal.cloudapp.net"
Trying "microsoft.com"
Trying "microsoft.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62884
;; flags: qr rd ra; QUERY: 1, ANSWER: 27, AUTHORITY: 0, ADDITIONAL: 5

;; QUESTION SECTION:
;microsoft.com.                 IN      ANY

;; ANSWER SECTION:
microsoft.com.          30      IN      NS      ns1-39.azure-dns.com.
...
...
ns4-39.azure-dns.info.  30      IN      A       13.107.206.39

Received 2121 bytes from 10.0.0.10#53 in 232 ms

  6. 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:1809' --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "windows"}}}' -- powershell "Start-Sleep -s 3600"

  7. Führen Sie den Befehl kubectl exec aus, um mithilfe von PowerShell eine Verbindung mit dem Pod herzustellen:

    kubectl exec -it dnsutil-win powershell

  8. 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

Sie sollten auch überprüfen, ob der Endpunkt vom Knoten aus erreichbar ist. Überprüfen Sie dann die DNS-Einstellungen im Knoten. Gehen Sie folgendermaßen vor:

  1. Stellen Sie zur Wartung oder Problembehandlung eine Verbindung mit AKS-Clusterknoten (Azure Kubernetes Service) her.

  2. Testen Sie die DNS-Auflösung für 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

  3. Ü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

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 sollten Sie dns-Auflösungsfehler innerhalb des Pods, aber nicht vom Workerknoten aus überprüfen. Wenn Sie die DNS-Auflösung für einen Endpunkt im gesamten Cluster überprüfen möchten, können Sie den DNS-Auflösungsstatus im gesamten Cluster ü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.

Überprüfen, ob der Cluster den Endpunkt über das Netzwerk erreichen kann

Führen Sie die folgenden Schritte aus, um zu bestimmen, ob Sie den Endpunkt über das Netzwerk von Ihrem Cluster aus erreichen können:

  1. Überprüfen Sie die Route zum Endpunkt, um zu ermitteln, ob bei einem bestimmten Vorgang ein Timeout auftritt:

    kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable
apt-get install -y traceroute && apt-get install netcat -y
traceroute -T microsoft.com -m 50 -p 443

  2. Überprüfen Sie, ob der gewünschte Port auf dem Remotehost geöffnet ist:

    nc -z -v microsoft.com 443

  3. Überprüfen Sie den HTTP-Antwortcode:

    curl -Iv https://microsoft.com

  4. Überprüfen Sie, ob Sie eine Verbindung mit einem anderen Endpunkt herstellen können:

    curl -Iv https://kubernetes.io

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.