Share via


Tunnelkonnektivitätsprobleme

Microsoft Azure Kubernetes Service (AKS) verwendet eine bestimmte Komponente für die getunnelte, sichere Kommunikation zwischen den Knoten und der Steuerungsebene. Der Tunnel besteht aus einem Server auf der Steuerungsebene und einem Client auf der Seite der Clusterknoten. In diesem Artikel wird erläutert, wie Sie Probleme im Zusammenhang mit der Tunnelkonnektivität in AKS beheben und beheben.

Diagramm der von Azure verwalteten AKS-Unterlage, dem kundenseitig verwalteten virtuellen Azure-Netzwerk und -Subnetz und dem Tunnel von der API zum Tunnelpod.

Hinweis

Standardmäßig und je nach Region war tunnel-frontdie Tunnelkomponente . Beim Aktualisieren auf das Feature "Service Level Agreement" (SLA) für die Betriebszeit wurde durch die Tunnelkomponente ersetzt, tunnel-front die aks-linkOpenVPN verwendet hat. AKS migriert zu Konnectivity. Dies ist eine Kubernetes-Upstream-Komponente, die sowohl als aks-linkauch tunnel-front ersetzt. Weitere Informationen zur Migration zu Konnectivity als Tunnelkomponente finden Sie in den AKS-Versionshinweisen und im Änderungsprotokoll.

Voraussetzungen

Problembeschreibung

Sie erhalten eine Fehlermeldung, die den folgenden Beispielen zu Port 10250 ähnelt:

Fehler vom Server: Abrufen von "https://< aks-node-name>:10250/containerLogs/<namespace>/<pod-name>/<container-name>": dial tcp <aks-node-ip>:10250: i/o timeout

Fehler vom Server: Fehler beim Wählen des Back-Ends: tcp <aks-node-ip>:10250: E/A-Timeout

Der Kubernetes-API-Server verwendet Port 10250, um eine Verbindung mit dem Kubelet eines Knotens herzustellen, um die Protokolle abzurufen. Wenn Port 10250 blockiert ist, funktionieren die kubectl-Protokolle und andere Features nur für Pods, die auf den Knoten ausgeführt werden, in denen die Tunnelkomponente geplant ist. Weitere Informationen finden Sie unter Kubernetes-Ports und -Protokolle: Workerknoten.

Da die Tunnelkomponenten oder die Konnektivität zwischen Server und Client nicht hergestellt werden können, funktionieren Funktionen wie die folgenden nicht wie erwartet:

  • Zugangscontroller-Webhooks

  • Möglichkeit des Protokollabrufs (mithilfe des Befehls kubectl logs )

  • Ausführen eines Befehls in einem Container oder Abrufen eines Containers (mit dem Befehl kubectl exec )

  • Weiterleiten eines oder mehrerer lokaler Ports eines Pods (mit dem Befehl kubectl port-forward )

Ursache 1: Eine Netzwerksicherheitsgruppe (NSG) blockiert Port 10250

Hinweis

Diese Ursache gilt für alle Tunnelkomponenten, die möglicherweise in Ihrem AKS-Cluster vorhanden sind.

Sie können eine Azure-Netzwerksicherheitsgruppe (NSG) verwenden, um Netzwerkdatenverkehr zu und von Azure-Ressourcen in einem virtuellen Azure-Netzwerk zu filtern. Eine Netzwerksicherheitsgruppe enthält Sicherheitsregeln, die eingehenden und ausgehenden Netzwerkdatenverkehr zwischen verschiedenen Arten von Azure-Ressourcen zulassen oder verweigern. Für jede Regel können Sie Quelle und Ziel, Port und Protokoll angeben. Weitere Informationen finden Sie unter Filtern von Netzwerkdatenverkehr durch Netzwerksicherheitsgruppen.

Wenn die NSG Port 10250 auf der Ebene des virtuellen Netzwerks blockiert, funktionieren Tunnelfunktionen (z. B. Protokolle und Codeausführung) nur für die Pods, die auf den Knoten geplant sind, auf denen Tunnelpods geplant sind. Die anderen Pods funktionieren nicht, da ihre Knoten den Tunnel nicht erreichen können und der Tunnel auf anderen Knoten geplant ist. Um diesen Zustand zu überprüfen, können Sie die Konnektivität mit netcat (nc) oder telnet-Befehlen testen. Sie können den Befehl az vmss run-command invoke ausführen, um den Konnektivitätstest durchzuführen und zu überprüfen, ob er erfolgreich ist, ein Timeout aufweist oder ein anderes Problem verursacht:

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "nc -v -w 2 <ip-of-node-that-schedules-the-tunnel-component> 10250" \
    --output tsv \
    --query 'value[0].message'

Lösung 1: Hinzufügen einer NSG-Regel zum Zulassen des Zugriffs auf Port 10250

Wenn Sie eine NSG verwenden und bestimmte Einschränkungen haben, stellen Sie sicher, dass Sie eine Sicherheitsregel hinzufügen, die Datenverkehr für Port 10250 auf der Ebene des virtuellen Netzwerks zulässt. Die folgende Azure-Portal Abbildung zeigt eine Beispielsicherheitsregel:

Screenshot des Bereichs

Wenn Sie restriktiver sein möchten, können Sie den Zugriff auf Port 10250 nur auf Subnetzebene zulassen.

Hinweis

  • Das Feld Priorität muss entsprechend angepasst werden. Wenn Sie beispielsweise über eine Regel verfügen, die mehrere Ports (einschließlich Port 10250) verweigert, sollte die in der Abbildung gezeigte Regel eine niedrigere Prioritätsnummer aufweisen (niedrigere Zahlen haben eine höhere Priorität). Weitere Informationen zur Priorität finden Sie unter Sicherheitsregeln.

  • Wenn nach dem Anwenden dieser Lösung keine Verhaltensänderung angezeigt wird, können Sie die Pods der Tunnelkomponente neu erstellen. Das Löschen dieser Pods führt dazu, dass sie neu erstellt werden.

Ursache 2: Das Tool Unkomplizierte Firewall (UFW) blockiert Port 10250

Hinweis

Diese Ursache gilt für jede Tunnelkomponente, die in Ihrem AKS-Cluster vorhanden ist.

Die unkomplizierte Firewall (UFW) ist ein Befehlszeilenprogramm zum Verwalten einer Netfilter-Firewall . AKS-Knoten verwenden Ubuntu. Daher wird UFW standardmäßig auf AKS-Knoten installiert, aber UFW ist deaktiviert.

Wenn UFW aktiviert ist, wird standardmäßig der Zugriff auf alle Ports blockiert, einschließlich Port 10250. In diesem Fall ist es unwahrscheinlich, dass Sie Secure Shell (SSH) verwenden können, um eine Verbindung mit AKS-Clusterknoten für die Problembehandlung herzustellen. Dies liegt daran, dass UFW möglicherweise auch Port 22 blockiert. Zur Problembehandlung können Sie den Befehl az vmss run-command invoke ausführen, um einen ufw-Befehl aufzurufen, der überprüft, ob UFW aktiviert ist:

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "ufw status" \
    --output tsv \
    --query 'value[0].message'

Was geschieht, wenn die Ergebnisse angeben, dass UFW aktiviert ist und Port 10250 nicht ausdrücklich zulässt? In diesem Fall funktionieren Tunnelfunktionen (z. B. Protokolle und Codeausführung) nicht für die Pods, die auf den Knoten geplant sind, auf denen UFW aktiviert ist. Wenden Sie eine der folgenden Lösungen auf UFW an, um das Problem zu beheben.

Wichtig

Bevor Sie dieses Tool verwenden, um Änderungen vorzunehmen, sollten Sie die AKS-Supportrichtlinie (insbesondere Knotenwartung und -zugriff) überprüfen, um zu verhindern, dass Ihr Cluster in ein nicht unterstütztes Szenario eintritt.

Hinweis

Wenn nach dem Anwenden einer Lösung keine Verhaltensänderung angezeigt wird, können Sie die Pods der Tunnelkomponente neu erstellen. Das Löschen dieser Pods führt dazu, dass sie neu erstellt werden.

Lösung 2a: Unkomplizierte Firewall deaktivieren

Führen Sie den folgenden az vmss run-command invoke Befehl aus, um UFW zu deaktivieren:

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "ufw disable" \
    --output tsv \
    --query 'value[0].message'

Lösung 2b: Konfigurieren der unkomplizierten Firewall, um den Zugriff auf Port 10250 zuzulassen

Führen Sie den folgenden az vmss run-command invoke Befehl aus, um zu erzwingen, dass UFW den Zugriff auf Port 10250 zulässt:

az vmss run-command invoke --resource-group <infra-or-MC-resource-group> \
    --name <virtual-machine-scale-set-name> \
    --command-id RunShellScript \
    --instance-id <instance-id> \
    --scripts "ufw allow 10250" \
    --output tsv \
    --query 'value[0].message'

Ursache 3: Das iptables-Tool blockiert Port 10250

Hinweis

Diese Ursache gilt für jede Tunnelkomponente, die in Ihrem AKS-Cluster vorhanden ist.

Mit dem Tool iptables kann ein Systemadministrator die IP-Paketfilterregeln einer Linux-Firewall konfigurieren. Sie können die Regeln so konfigurieren, dass die iptables Kommunikation über Port 10250 blockiert wird.

Sie können die Regeln für Ihre Knoten anzeigen, um zu überprüfen, ob Port 10250 blockiert ist oder die zugehörigen Pakete verworfen werden. Führen Sie dazu den folgenden iptables Befehl aus:

iptables --list --line-numbers

In der Ausgabe werden die Daten in mehrere Ketten gruppiert, einschließlich der INPUT Kette. Jede Kette enthält eine Regeltabelle unter den folgenden Spaltenüberschriften:

  • num (Regelnummer)
  • target
  • prot (Protokoll)
  • opt
  • source
  • destination

Enthält die INPUT Kette eine Regel, in der das Ziel ist DROP, das Protokoll tcpist und das Ziel ist tcp dpt:10250? Wenn dies der Fall ist, iptables blockiert den Zugriff auf Den Zielport 10250.

Lösung 3: Löschen der iptables-Regel, die den Zugriff auf Port 10250 blockiert

Führen Sie einen der folgenden Befehle aus, um die Regel zu löschen, die iptables den Zugriff auf Port 10250 verhindert:

iptables --delete INPUT --jump DROP --protocol tcp --source <ip-number> --destination-port 10250
iptables --delete INPUT <input-rule-number>

Um Ihr genaues oder potenzielles Szenario zu beheben, empfehlen wir Ihnen, das iptables-Handbuch zu überprüfen, indem Sie den iptables --help Befehl ausführen.

Wichtig

Bevor Sie dieses Tool verwenden, um Änderungen vorzunehmen, sollten Sie die AKS-Supportrichtlinie (insbesondere Knotenwartung und -zugriff) überprüfen, um zu verhindern, dass Ihr Cluster in ein nicht unterstütztes Szenario eintritt.

Ursache 4: Ausgehender Port 1194 oder 9000 ist nicht geöffnet

Hinweis

Diese Ursache gilt nur für die tunnel-front Pods und aks-link .

Gibt es Einschränkungen für ausgehenden Datenverkehr, z. B. von einer AKS-Firewall? Falls vorhanden, ist Port 9000 erforderlich, um die korrekte Funktionalität des tunnel-front Pods zu aktivieren. Ebenso ist Port 1194 für den aks-link Pod erforderlich.

Konnectivity basiert auf Port 443. Dieser Port ist standardmäßig geöffnet. Daher müssen Sie sich keine Gedanken über Konnektivitätsprobleme an diesem Port machen.

Lösung 4: Port 1194 oder 9000 öffnen

Stellen Sie sicher, dass der virtuelle Anwendung zugriff auf Port 1194 oder Port 9000 zulässt. Weitere Informationen zu den erforderlichen Regeln und Abhängigkeiten finden Sie unter Globale erforderliche Netzwerkregeln für Azure.

Ursache 5: SNAT-Portauslastung (Source Network Address Translation)

Hinweis

Diese Ursache gilt für jede Tunnelkomponente, die in Ihrem AKS-Cluster vorhanden ist. Sie gilt jedoch nicht für private AKS-Cluster. Die SNAT-Portauslastung (Source Network Address Translation) kann nur für die öffentliche Kommunikation auftreten. Bei privaten AKS-Clustern befindet sich der API-Server innerhalb des virtuellen Netzwerks oder Subnetzes von AKS.

Wenn eine SNAT-Portauslastung auftritt (fehlerhafte SNAT-Ports), können die Knoten keine Verbindung mit dem API-Server herstellen. Der Tunnelcontainer befindet sich auf der API-Serverseite. Daher wird keine Tunnelkonnektivität hergestellt.

Wenn die SNAT-Portressourcen erschöpft sind, schlagen die ausgehenden Flows fehl, bis die vorhandenen Flows einige SNAT-Ports freigeben. Azure Load Balancer gibt die SNAT-Ports zurück, wenn der Flow geschlossen wird. Es verwendet ein Vier-Minuten-Leerlauftimeout, um die SNAT-Ports aus den Leerlaufflüssen freizugeben.

Sie können die SNAT-Ports entweder aus den AKS Load Balancer-Metriken oder dem Dienst Diagnose anzeigen, wie in den folgenden Abschnitten beschrieben. Weitere Informationen zum Anzeigen von SNAT-Ports finden Sie unter Gewusst wie Überprüfen meiner Statistiken für ausgehende Verbindungen?.

AKS-Lastenausgleichsmetriken

Führen Sie die folgenden Schritte aus, um die AKS-Lastenausgleichsmetriken zum Anzeigen der SNAT-Ports zu verwenden:

  1. Suchen Sie im Azure-Portal nach Kubernetes-Diensten, und wählen Sie diese Option aus.

  2. Wählen Sie in der Liste der Kubernetes-Dienste den Namen Ihres Clusters aus.

  3. Suchen Sie im Menübereich des Clusters die Überschrift Einstellungen , und wählen Sie dann Eigenschaften aus.

  4. Wählen Sie den Namen aus, der unter Infrastrukturressourcengruppe aufgeführt ist.

  5. Wählen Sie den Kubernetes-Lastenausgleich aus.

  6. Suchen Sie im Menübereich des Lastenausgleichs die Überschrift Überwachung , und wählen Sie dann Metriken aus.

  7. Wählen Sie als Metriktyp die Option SNAT-Verbindungsanzahl aus.

  8. Wählen Sie Teilung anwenden aus.

  9. Legen Sie Split by auf Connection State (Verbindungsstatus) fest.

Dienst Diagnose

Führen Sie die folgenden Schritte aus, um dienst Diagnose zum Anzeigen der SNAT-Ports zu verwenden:

  1. Suchen Sie im Azure-Portal nach Kubernetes-Diensten, und wählen Sie diese Option aus.

  2. Wählen Sie in der Liste der Kubernetes-Dienste den Namen Ihres Clusters aus.

  3. Wählen Sie im Menübereich des Clusters Diagnose und Problembehandlung aus.

  4. Wählen Sie Konnektivitätsprobleme aus.

  5. Wählen Sie unter SNAT-Verbindung und Portzuordnungdie Option Details anzeigen aus.

  6. Verwenden Sie bei Bedarf die Schaltfläche Zeitbereich , um den Zeitrahmen anzupassen.

Lösung 5a: Stellen Sie sicher, dass die Anwendung Verbindungspooling verwendet.

Dieses Verhalten kann auftreten, weil eine Anwendung vorhandene Verbindungen nicht wiederverwendet. Es wird empfohlen, keine ausgehende Verbindung pro Anforderung zu erstellen. Eine solche Konfiguration kann zu einer Überlastung der Verbindung führen. Überprüfen Sie, ob der Anwendungscode bewährte Methoden befolgt und Verbindungspooling verwendet. Die meisten Bibliotheken unterstützen Verbindungspooling. Daher sollten Sie nicht pro Anforderung eine neue ausgehende Verbindung erstellen müssen.

Lösung 5b: Anpassen der zugeordneten ausgehenden Ports

Wenn in der Anwendung alles in Ordnung ist, müssen Sie die zugeordneten ausgehenden Ports anpassen. Weitere Informationen zur Zuordnung ausgehender Ports finden Sie unter Konfigurieren der zugeordneten ausgehenden Ports.

Lösung 5c: Verwenden eines NAT-Gateways (Managed Network Address Translation) beim Erstellen eines Clusters

Sie können einen neuen Cluster einrichten, um ein NAT-Gateway (Managed Network Address Translation) für ausgehende Verbindungen zu verwenden. Weitere Informationen finden Sie unter Erstellen eines AKS-Clusters mit einem verwalteten NAT-Gateway.

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.