TCP-Timeouts, wenn kubectl oder andere Drittanbietertools eine Verbindung mit dem API-Server herstellen

In diesem Artikel wird erläutert, wie Sie probleme mit TCP-Timeouts beheben, die auftreten, wenn Kubectl oder andere Tools von Drittanbietern verwendet werden, um eine Verbindung mit dem API-Server in Microsoft Azure Kubernetes Service (AKS) herzustellen. Um sicherzustellen, dass ihre Ziele auf Serviceebene (SLOs) und Vereinbarungen auf Service-Level-Ebene (Service Level Agreements, SLAs) von AKS verwendet werden, verwendet AKS Kontrollebenen, die vertikal und horizontal skaliert werden, basierend auf der Anzahl der Kerne.

Symptome

Es treten wiederholte Verbindungstimeouts auf.

Ursache 1: Pods, die für die Kommunikation zwischen Knoten-zu-Steuerungsebenen verantwortlich sind, werden nicht ausgeführt

Wenn nur einige Ihrer API-Befehle konsistent ablaufen, befinden sich die folgenden Pods möglicherweise nicht in einem ausgeführten Zustand:

• konnectivity-agent
• tunnelfront
• aks-link

Notiz

In neueren AKS-Versionen tunnelfront und aks-link werden durch konnectivity-agentersetzt, sodass sie nur angezeigt konnectivity-agentwerden.

Diese Pods sind für die Kommunikation zwischen einem Knoten und der Steuerungsebene verantwortlich.

Lösung: Reduzieren der Auslastung oder Stress der Knotenhosts

Stellen Sie sicher, dass die Knoten, die diese Pods hosten, nicht übermäßig genutzt oder unter Stress stehen. Erwägen Sie, die Knoten in ihren eigenen Systemknotenpool zu verschieben.

Führen Sie die folgenden Befehle aus, um zu überprüfen, auf welchem Knoten der konnectivity-agent Pod gehostet wird, und die Verwendung des Knotens:

# Check which node the konnectivity-agent pod is hosted on
$ kubectl get pod -n kube-system -o wide
    
# Check the usage of the node hosting the pod
$ kubectl top node

Ursache 2: Der Zugriff wird für einige erforderliche Ports, FQDNs und IP-Adressen blockiert.

Wenn die erforderlichen Ports, vollqualifizierte Domänennamen (FQDNs) und IP-Adressen nicht alle geöffnet sind, können mehrere Befehlsaufrufe fehlschlagen. Sichere, tunnelierte Kommunikation auf AKS zwischen dem API-Server und dem Kubelet (über den konnectivity-agent Pod) erfordert, dass einige dieser Elemente erfolgreich funktionieren.

Lösung: Öffnen der erforderlichen Ports, FQDNs und IP-Adressen

Weitere Informationen dazu, welche Ports, FQDNs und IP-Adressen geöffnet werden müssen, finden Sie unter "Ausgehende Netzwerk- und FQDN-Regeln für Azure Kubernetes Service (AKS)-Cluster.For more information about what ports, FQDNs, and IP addresses need to be opened, see Outbound network and FQDN rules for Azure Kubernetes Service (AKS)cluster.

Ursache 3: Die TLS-Erweiterung des Application-Layer-Protokolls wird blockiert.

Um eine Verbindung zwischen der Steuerungsebene und knoten herzustellen, benötigt der konnectivity-agent Pod die TLS-Erweiterung (Transport Layer Security) für die Application-Layer Protocol Negotiation (ALPN). Möglicherweise haben Sie diese Erweiterung zuvor blockiert.

Lösung: Aktivieren der ALPN-Erweiterung

Aktivieren Sie die ALPN-Erweiterung auf dem konnectivity-agent Pod, um TCP-Timeouts zu verhindern.

Ursache 4: Die IP-autorisierten BEREICHE des API-Servers decken Ihre aktuelle IP-Adresse nicht ab.

Wenn Sie autorisierte IP-Adressbereiche auf Ihrem API-Server verwenden, werden Ihre API-Aufrufe blockiert, wenn Ihre IP nicht in den autorisierten Bereichen enthalten ist.

Lösung: Ändern der autorisierten IP-Adressbereiche, sodass sie Ihre IP-Adresse abdeckt

Ändern Sie die autorisierten IP-Adressbereiche so, dass Ihre IP-Adresse abgedeckt ist. Weitere Informationen finden Sie unter Aktualisieren des API-Servers eines Clusters autorisierte IP-Bereiche.

Ursache 5: Aufrufe eines Clients oder einer Anwendung an den API-Server gehen verloren

Häufige GET-Aufrufe können den API-Server ansammeln und überladen.

Lösung: Verwenden Sie Watches anstelle von GET-Aufrufen, stellen Sie jedoch sicher, dass die Anwendung diese Anrufe nicht ausleckt.

Stellen Sie sicher, dass Sie Monitore anstelle häufiger GET-Aufrufe an den API-Server verwenden. Außerdem müssen Sie sicherstellen, dass Ihre Drittanbieteranwendungen keine Überwachungsverbindungen oder GET-Anrufe verloren gehen. In der Istio Microservice-Architektur erstellt ein Fehler in der Mixeranwendung beispielsweise eine neue API-Serverüberwachungsverbindung, wenn ein geheimer Schlüssel intern gelesen wird. Da dieses Verhalten in regelmäßigen Abständen auftritt, sammeln sich die Überwachungsverbindungen schnell an. Diese Verbindungen führen schließlich dazu, dass der API-Server unabhängig vom Skalierungsmuster überlastet wird.

Ursache 6: Zu viele Versionen in Ihren Helm-Bereitstellungen

Wenn Sie zu viele Versionen in Ihren Bereitstellungen von Helm (dem Kubernetes-Paket-Manager) verwenden, verbrauchen die Knoten zu viel Arbeitsspeicher. Es führt auch zu einer großen Menge ConfigMap von (Konfigurationsdaten)-Objekten, die zu unnötigen Verwendungsspitzen auf dem API-Server führen können.

Lösung: Maximale Anzahl von Überarbeitungen für jede Version einschränken

Da die maximale Anzahl von Überarbeitungen für jede Version standardmäßig unbegrenzt ist, müssen Sie einen Befehl ausführen, um diese maximale Zahl auf einen angemessenen Wert festzulegen. Für Helm 2 ist der Befehl helm init. Für Helm 3 ist der Befehl das Helmupgrade. Legen Sie den --history-max <value> Parameter fest, wenn Sie den Befehl ausführen.

Version	Get-Help
Helm 2	helm init --history-max <maximum-number-of-revisions-per-release> ...
Helm 3	helm upgrade ... --history-max <maximum-number-of-revisions-per-release> ...

Ursache 7: Interner Datenverkehr zwischen Knoten wird blockiert

Möglicherweise gibt es interne Datenverkehrsblockagen zwischen Knoten in Ihrem AKS-Cluster.

Lösung: Beheben des Fehlers "Dial tcp <Node_IP>:10250: i/o timeout"

Siehe Problembehandlung bei TCP-Timeouts, z. B . "Dial tcp <Node_IP>:10250: i/o timeout".

Ursache 8: Ihr Cluster ist privat

Ihr Cluster ist ein privater Cluster, aber der Client, von dem Aus Sie auf den API-Server zugreifen möchten, befindet sich in einem öffentlichen oder anderen Netzwerk, das keine Verbindung mit dem subnetz herstellen kann, das von AKS verwendet wird.

Lösung: Verwenden eines Clients, der auf das AKS-Subnetz zugreifen kann

Da ihr Cluster privat ist und seine Kontrollebene sich im AKS-Subnetz befindet, kann er nicht mit dem API-Server verbunden werden, es sei denn, er befindet sich in einem Netzwerk, das eine Verbindung mit dem AKS-Subnetz herstellen kann. Es ist ein erwartetes Verhalten.

Versuchen Sie in diesem Fall, von einem Client in einem Netzwerk aus auf den API-Server zuzugreifen, der mit dem AKS-Subnetz kommunizieren kann. Überprüfen Sie außerdem, ob Netzwerksicherheitsgruppen (NSGs) oder andere Appliances zwischen Netzwerken keine Pakete blockieren.

Informationen zum Haftungsausschluss von Drittanbietern

Die in diesem Artikel genannten Drittanbieterprodukte stammen von Herstellern, die von Microsoft unabhängig sind. Microsoft gewährt keine implizite oder sonstige Garantie in Bezug auf die Leistung oder Zuverlässigkeit dieser Produkte.

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.