TCP-time-outs wanneer kubectl of andere hulpprogramma's van derden verbinding maken met de API-server

Artikel
11/19/2024

In dit artikel wordt beschreven hoe u problemen met TCP-time-outs oplost die optreden wanneer kubectl of andere hulpprogramma's van derden worden gebruikt om verbinding te maken met de API-server in Microsoft Azure Kubernetes Service (AKS). Om ervoor te zorgen dat de serviceniveaudoelstellingen (SLO's) en service level agreements (SLA's) worden door AKS besturingsvlakken met hoge beschikbaarheid (HA) gebruikt die verticaal en horizontaal worden geschaald op basis van het aantal kernen.

Symptomen

U ondervindt herhaalde verbindingstime-outs.

Oorzaak 1: Pods die verantwoordelijk zijn voor communicatie tussen knooppunten en besturingsvlakken worden niet uitgevoerd

Als er slechts een paar van uw API-opdrachten consistent een time-out hebben, hebben de volgende pods mogelijk geen actieve status:

konnectivity-agent
tunnelfront
aks-link

Notitie

In nieuwere AKS-versies en tunnelfront aks-link worden vervangen door konnectivity-agent, dus u ziet konnectivity-agentalleen .

Deze pods zijn verantwoordelijk voor communicatie tussen een knooppunt en het besturingsvlak.

Oplossing: verminder het gebruik of de stress van de knooppunthosts

Zorg ervoor dat de knooppunten die deze pods hosten, niet te veel worden gebruikt of onder stress staan. Overweeg om de knooppunten naar hun eigen systeemknooppuntgroep te verplaatsen.

Voer de volgende opdrachten uit om te controleren op welk knooppunt de konnectivity-agent pod wordt gehost en het gebruik van het knooppunt:

# 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

Oorzaak 2: De toegang wordt geblokkeerd op sommige vereiste poorten, FQDN's en IP-adressen

Als de vereiste poorten, FQDN's (Fully Qualified Domain Names) en IP-adressen niet allemaal worden geopend, kunnen verschillende opdrachtoproepen mislukken. Beveiligde, tunneled communicatie op AKS tussen de API-server en de kubelet (via de konnectivity-agent pod) vereist dat sommige van deze items correct werken.

Oplossing: Open de benodigde poorten, FQDN's en IP-adressen

Zie Regels voor uitgaand netwerk en FQDN voor Azure Kubernetes Service-clusters (AKS) voor meer informatie over welke poorten, FQDN's en IP-adressen moeten worden geopend.

Oorzaak 3: De TLS-extensie application-layer protocolonderhandeling is geblokkeerd

Voor het tot stand brengen van een verbinding tussen het besturingsvlak en knooppunten vereist de konnectivity-agent pod de TLS-extensie (Transport Layer Security) voor Application-Layer Protocol Negotiation (ALPN). Mogelijk hebt u deze extensie eerder geblokkeerd.

Oplossing: De ALPN-extensie inschakelen

Schakel de ALPN-extensie op de konnectivity-agent pod in om TCP-time-outs te voorkomen.

Oorzaak 4: De IP-adresbereiken van de API-server hebben geen betrekking op uw huidige IP-adres

Als u geautoriseerde IP-adresbereiken op uw API-server gebruikt, worden uw API-aanroepen geblokkeerd als uw IP-adres niet is opgenomen in de geautoriseerde bereiken.

Oplossing: Wijzig de geautoriseerde IP-adresbereiken zodat deze uw IP-adres bedekt

Wijzig de geautoriseerde IP-adresbereiken zodat uw IP-adres wordt gedekt. Zie De geautoriseerde IP-bereiken van een clusterserver bijwerken voor meer informatie.

Oorzaak 5: Een client of toepassing lekt aanroepen naar de API-server

Frequente GET-aanroepen kunnen de API-server verzamelen en overbelasten.

Oplossing: Gebruik horloges in plaats van GET-aanroepen, maar zorg ervoor dat de toepassing deze aanroepen niet lekt

Zorg ervoor dat u horloges gebruikt in plaats van frequente GET-aanroepen naar de API-server. U moet er ook voor zorgen dat uw toepassingen van derden geen horlogeverbindingen of GET-oproepen lekken. In de Istio-microservicearchitectuur maakt een bug in de mixertoepassing bijvoorbeeld een nieuwe API-server-watchverbinding wanneer intern een geheim wordt gelezen. Omdat dit gedrag regelmatig gebeurt, worden de horlogeverbindingen snel verzameld. Deze verbindingen veroorzaken uiteindelijk dat de API-server overbelast raakt, ongeacht het schaalpatroon.

Oorzaak 6: Te veel releases in uw Helm-implementaties

Als u te veel releases gebruikt in uw implementaties van Helm (de Kubernetes-pakketbeheerder), gaan de knooppunten te veel geheugen verbruiken. Het resulteert ook in een grote hoeveelheid ConfigMap (configuratiegegevens) objecten, wat onnodige gebruikspieken op de API-server kan veroorzaken.

Oplossing: beperk het maximum aantal revisies voor elke release

Omdat het maximum aantal revisies voor elke release oneindig is, moet u een opdracht uitvoeren om dit maximumaantal in te stellen op een redelijke waarde. Voor Helm 2 is de opdracht helm init. Voor Helm 3 is de opdracht helm-upgrade. Stel de --history-max <value> parameter in wanneer u de opdracht uitvoert.

Versie	Opdracht
Helm 2	`helm init --history-max <maximum-number-of-revisions-per-release> ...`
Helm 3	`helm upgrade ... --history-max <maximum-number-of-revisions-per-release> ...`

Oorzaak 7: Intern verkeer tussen knooppunten wordt geblokkeerd

Mogelijk zijn er interne verkeersblokkeringen tussen knooppunten in uw AKS-cluster.

Oplossing: Problemen met de fout 'Tcp-Node_IP<>:10250: i/o time-out' oplossen

Zie Problemen met TCP-time-outs oplossen, zoals 'dial tcp <Node_IP>:10250: i/o timeout'.

Oorzaak 8: Uw cluster is privé

Uw cluster is een privécluster, maar de client van waaruit u toegang probeert te krijgen tot de API-server bevindt zich in een openbaar of ander netwerk dat geen verbinding kan maken met het subnet dat door AKS wordt gebruikt.

Oplossing: Een client gebruiken die toegang heeft tot het AKS-subnet

Omdat uw cluster privé is en het besturingsvlak zich in het AKS-subnet bevindt, kan het niet worden verbonden met de API-server, tenzij het zich in een netwerk bevindt dat verbinding kan maken met het AKS-subnet. Het is een verwacht gedrag.

In dit geval probeert u toegang te krijgen tot de API-server vanaf een client in een netwerk dat kan communiceren met het AKS-subnet. Controleer ook of netwerkbeveiligingsgroepen (NSG's) of andere apparaten tussen netwerken geen pakketten blokkeren.

Disclaimerinformatie van derden

De producten van derden die in dit artikel worden vermeld, worden vervaardigd door bedrijven die onafhankelijk zijn van Microsoft. Microsoft verleent dan ook geen enkele garantie, impliciet noch anderszins, omtrent de prestaties of de betrouwbaarheid van deze producten.

Contacteer ons voor hulp

Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Azure-feedbackcommunity.

Delen via