Datenverkehr zwischen Knotenpools wird durch eine benutzerdefinierte Netzwerksicherheitsgruppe blockiert

In diesem Artikel wird erläutert, wie Sie ein Szenario beheben, in dem eine benutzerdefinierte Netzwerksicherheitsgruppe (NSG) datenverkehr zwischen Knotenpools in einem Microsoft Azure Kubernetes Service (AKS)-Cluster blockiert.

Symptome

Die DNS-Auflösung (Domain Name System) von Pods des Benutzerknotenpools schlägt fehl.

Hintergrund

In Szenarien mit mehreren Knotenpools können die Pods im kube-system Namespace in einem Knotenpool (dem Systemknotenpool) platziert werden, während die Anwendungs pods in einem anderen Knotenpool (dem Benutzerknotenpool) platziert werden. In einigen Szenarien können Pods, die miteinander kommunizieren, in verschiedenen Knotenpools vorhanden sein.

Mit AKS können Kunden Knotenpools in verschiedenen Subnetzen haben. Dieses Feature bedeutet, dass Kunden auch unterschiedliche NSGs dem Subnetz jedes Knotenpools zuordnen können.

Ursache 1: Die NSG eines Knotenpools blockiert eingehenden Datenverkehr

Eingehender Zugriff auf die NSG eines Knotenpools blockiert Datenverkehr. Beispielsweise blockiert ein benutzerdefinierter NSG im Systemknotenpool (der die Kern-DNS-Pods hostet) eingehenden Datenverkehr im UDP-Port 53 (User Datagram Protocol) aus dem Subnetz des Benutzerknotenpools.

Lösung 1: Konfigurieren des benutzerdefinierten NSG für den Datenverkehr zwischen den Knotenpools

Stellen Sie sicher, dass Ihr benutzerdefinierter NSG den erforderlichen Datenverkehr zwischen den Knotenpools zulässt, insbesondere auf UDP-Port 53. AKS aktualisiert nicht die benutzerdefinierte NSG, die subnetzen zugeordnet ist.

Ursache 2: Ausgehender Zugriff auf die NSG eines Knotenpools blockiert Datenverkehr

Die NSG auf einem anderen Knotenpool blockiert ausgehenden Zugriff auf den Pod. Beispielsweise blockiert ein benutzerdefinierter NSG im Benutzerknotenpool ausgehenden Datenverkehr am UDP-Port 53 zum Systemknotenpool.

Lösung 2: Konfigurieren der benutzerdefinierten NSG für den Datenverkehr zwischen den Knotenpools

Siehe Lösung 1: Konfigurieren der benutzerdefinierten NSG, um Datenverkehr zwischen den Knotenpools zuzulassen.

Ursache 3: TCP-Port 10250 ist blockiert

Ein weiteres gängiges Szenario ist, dass der TCP-Port 10250 zwischen den Knotenpools blockiert wird.

In diesem Fall erhält ein Benutzer möglicherweise eine Fehlermeldung, die dem folgenden Text ähnelt:

$ kubectl logs nginx-57cdfd6dd9-xb7hk
Error from server: Get https://<node>:10250/containerLogs/default/nginx-57cdfd6dd9-xb7hk/nginx: net/http: TLS handshake timeout

Wenn die Kommunikation am TCP-Port 10250 blockiert ist, wird die Verbindung mit dem Kubelet beeinträchtigt, und die Protokolle werden nicht abgerufen.

Lösung 3: Überprüfen auf NSG-Regeln, die TCP-Port 10250 blockieren

Überprüfen Sie, ob NSG-Regeln die Kommunikation zwischen Knoten und Knoten an TCP-Port 10250 blockieren.

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.