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.
Hinweis
Standardmäßig und je nach Region war tunnel-front
die Tunnelkomponente . Beim Aktualisieren auf das Feature "Service Level Agreement" (SLA) für die Betriebszeit wurde durch die Tunnelkomponente ersetzt, tunnel-front
die aks-link
OpenVPN verwendet hat. AKS migriert zu Konnectivity. Dies ist eine Kubernetes-Upstream-Komponente, die sowohl als aks-link
auch 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:
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 tcp
ist 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:
Suchen Sie im Azure-Portal nach Kubernetes-Diensten, und wählen Sie diese Option aus.
Wählen Sie in der Liste der Kubernetes-Dienste den Namen Ihres Clusters aus.
Suchen Sie im Menübereich des Clusters die Überschrift Einstellungen , und wählen Sie dann Eigenschaften aus.
Wählen Sie den Namen aus, der unter Infrastrukturressourcengruppe aufgeführt ist.
Wählen Sie den Kubernetes-Lastenausgleich aus.
Suchen Sie im Menübereich des Lastenausgleichs die Überschrift Überwachung , und wählen Sie dann Metriken aus.
Wählen Sie als Metriktyp die Option SNAT-Verbindungsanzahl aus.
Wählen Sie Teilung anwenden aus.
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:
Suchen Sie im Azure-Portal nach Kubernetes-Diensten, und wählen Sie diese Option aus.
Wählen Sie in der Liste der Kubernetes-Dienste den Namen Ihres Clusters aus.
Wählen Sie im Menübereich des Clusters Diagnose und Problembehandlung aus.
Wählen Sie Konnektivitätsprobleme aus.
Wählen Sie unter SNAT-Verbindung und Portzuordnungdie Option Details anzeigen aus.
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.
Feedback
https://aka.ms/ContentUserFeedback.
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unterFeedback senden und anzeigen für