TCP-tidsgränser när kubectl eller andra verktyg från tredje part ansluter till API-servern

Artikel
11/19/2024

I den här artikeln beskrivs hur du felsöker TCP-timeouter som inträffar när kubectl eller andra verktyg från tredje part används för att ansluta till API-servern i Microsoft Azure Kubernetes Service (AKS). För att säkerställa sina servicenivåmål (SLA) och serviceavtal (SLA) använder AKS kontrollplan med hög tillgänglighet (HA) som skalas vertikalt och horisontellt, baserat på antalet kärnor.

Symptom

Du får upprepade tidsgränser för anslutningen.

Orsak 1: Poddar som ansvarar för nod-till-kontroll-plankommunikation körs inte

Om bara några av dina API-kommandon är konsekventa är följande poddar kanske inte i ett körningstillstånd:

konnectivity-agent
tunnelfront
aks-link

Kommentar

I nyare AKS-versioner tunnelfront aks-link och ersätts med konnectivity-agent, så ser du bara konnectivity-agent.

Dessa poddar ansvarar för kommunikationen mellan en nod och kontrollplanet.

Lösning: Minska användningen eller belastningen för nodvärdarna

Kontrollera att noderna som är värdar för dessa poddar inte används för mycket eller är stressade. Överväg att flytta noderna till sin egen systemnodpool.

Kör följande kommandon för att kontrollera vilken nod konnectivity-agent podden finns på och användningen av noden:

# 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

Orsak 2: Åtkomst blockeras på vissa nödvändiga portar, FQDN och IP-adresser

Om de portar som krävs, fullständigt kvalificerade domännamn (FQDN) och IP-adresser inte öppnas, kan flera kommandoanrop misslyckas. Säker, tunnelbaserad kommunikation på AKS mellan API-servern och kubeleten (via konnectivity-agent podden) kräver att vissa av dessa objekt fungerar.

Lösning: Öppna nödvändiga portar, FQDN och IP-adresser

Mer information om vilka portar, FQDN och IP-adresser som behöver öppnas finns i Utgående nätverk och FQDN-regler för AkS-kluster (Azure Kubernetes Service).

Orsak 3: TLS-tillägget application-layer protocol negotiation blockeras

För att upprätta en anslutning mellan kontrollplanet och noderna konnectivity-agent kräver podden TLS-tillägget (Transport Layer Security) för Application-Layer Protocol Negotiation (ALPN). Du kanske tidigare har blockerat det här tillägget.

Lösning: Aktivera ALPN-tillägget

Aktivera ALPN-tillägget på konnectivity-agent podden för att förhindra TCP-timeouter.

Orsak 4: API-serverns IP-auktoriserade intervall täcker inte din aktuella IP-adress

Om du använder auktoriserade IP-adressintervall på DIN API-server blockeras dina API-anrop om din IP-adress inte ingår i de auktoriserade intervallen.

Lösning: Ändra de auktoriserade IP-adressintervallen så att det täcker din IP-adress

Ändra de auktoriserade IP-adressintervallen så att din IP-adress omfattas. Mer information finns i Uppdatera ett klusters API-serverauktoriserade IP-intervall.

Orsak 5: En klient eller ett program läcker anrop till API-servern

Frekventa GET-anrop kan ackumulera och överbelasta API-servern.

Lösning: Använd klockor i stället för GET-anrop, men se till att programmet inte läcker dessa anrop

Kontrollera att du använder klockor i stället för frekventa GET-anrop till API-servern. Du måste också se till att dina program från tredje part inte läcker några klockanslutningar eller GET-samtal. I till exempel istio-mikrotjänstarkitekturen skapar en bugg i mixerprogrammet en ny API-serverbevakningsanslutning när en hemlighet läss internt. Eftersom det här beteendet sker med jämna mellanrum ackumuleras klockanslutningarna snabbt. Dessa anslutningar gör så småningom att API-servern överbelastas oavsett skalningsmönster.

Orsak 6: För många versioner i Helm-distributionerna

Om du använder för många versioner i dina distributioner av Helm (Kubernetes-pakethanteraren) börjar noderna förbruka för mycket minne. Det resulterar också i en stor mängd (konfigurationsdata ConfigMap ) objekt, vilket kan orsaka onödiga användningstoppar på API-servern.

Lösning: Begränsa det maximala antalet revisioner för varje version

Eftersom det maximala antalet revisioner för varje version är oändligt som standard måste du köra ett kommando för att ange det maximala antalet till ett rimligt värde. För Helm 2 är kommandot helm init. För Helm 3 är kommandot helm-uppgradering. Ange parametern --history-max <value> när du kör kommandot.

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

Orsak 7: Intern trafik mellan noder blockeras

Det kan finnas interna trafikblockeringar mellan noder i AKS-klustret.

Lösning: Felsöka felet "dial tcp <Node_IP>:10250: i/o timeout"

Se Felsöka TCP-timeouter, till exempel "dial tcp <Node_IP>:10250: i/o timeout".

Orsak 8: Klustret är privat

Klustret är ett privat kluster, men klienten som du försöker komma åt API-servern från finns i ett offentligt eller annat nätverk som inte kan ansluta till det undernät som används av AKS.

Lösning: Använda en klient som har åtkomst till AKS-undernätet

Eftersom klustret är privat och dess kontrollplan finns i AKS-undernätet kan det inte anslutas till API-servern om det inte finns i ett nätverk som kan ansluta till AKS-undernätet. Det är ett förväntat beteende.

I det här fallet kan du försöka komma åt API-servern från en klient i ett nätverk som kan kommunicera med AKS-undernätet. Kontrollera dessutom att nätverkssäkerhetsgrupper (NSG:er) eller andra enheter mellan nätverk inte blockerar paket.

Ansvarsfriskrivning för information från tredje part

De produkter från andra tillverkare som diskuteras i denna artikel tillverkas oberoende av Microsoft. Produkternas funktion eller tillförlitlighet kan därför inte garanteras.

Kontakta oss för att få hjälp

Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.

Dela via