Dela via


Problem med tunnelanslutning

Microsoft Azure Kubernetes Service (AKS) använder en specifik komponent för tunnelbaserad, säker kommunikation mellan noderna och kontrollplanet. Tunneln består av en server på kontrollplanets sida och en klient på klusternodsidan. Den här artikeln beskriver hur du felsöker och löser problem som rör tunnelanslutning i AKS.

Diagram över det Azure-hanterade AKS-underlägget, det kundhanterade virtuella Azure-nätverket och undernätet samt tunneln från API:et till tunnelpodden.

Obs!

Som standard, och beroende på region, var tunnel-fronttunnelkomponenten . Vid uppdatering till servicenivåavtalsfunktionen tunnel-front (SLA) för drifttid ersattes den av tunnelkomponenten aks-link som använde OpenVPN. AKS migreras till Konnectivity. Det här är en Kubernetes-överordnad komponent som ersätter både tunnel-front och aks-link. Mer information om migrering till Konnectivity som tunnelkomponent finns i AKS-viktig information och ändringslogg.

Förutsättningar

Symptom

Du får ett felmeddelande som liknar följande exempel om port 10250:

Fel från servern: Hämta "https://< aks-node-name>:10250/containerLogs/<namespace>/<pod-name>/<container-name>": dial tcp <aks-node-ip>:10250: i/o timeout

Fel från server: fel vid uppringning av serverdel: ring tcp <aks-node-ip>:10250: i/o-timeout

Kubernetes API-servern använder port 10250 för att ansluta till en nods kubelet för att hämta loggarna. Om port 10250 blockeras fungerar kubectl-loggarna och andra funktioner endast för poddar som körs på noderna där tunnelkomponenten är schemalagd. Mer information finns i Kubernetes-portar och protokoll: Arbetsnoder.

Eftersom tunnelkomponenterna eller anslutningen mellan servern och klienten inte kan upprättas fungerar inte funktioner som följande som förväntat:

  • Webhooks för antagningskontrollant

  • Möjligheten att hämta loggar (med kommandot kubectl logs )

  • Köra ett kommando i en container eller komma in i en container (med kommandot kubectl exec )

  • Vidarebefordra en eller flera lokala portar för en podd (med kommandot kubectl port-forward )

Orsak 1: En nätverkssäkerhetsgrupp (NSG) blockerar port 10250

Obs!

Den här orsaken gäller för alla tunnelkomponenter som du kan ha i AKS-klustret.

Du kan använda en Nätverkssäkerhetsgrupp (NSG) i Azure för att filtrera nätverkstrafik till och från Azure-resurser i ett virtuellt Azure-nätverk. En nätverkssäkerhetsgrupp innehåller säkerhetsregler som tillåter eller nekar inkommande och utgående nätverkstrafik mellan flera typer av Azure-resurser. För varje regel kan du ange källa och mål, port och protokoll. Mer information finns i Hur nätverkssäkerhetsgrupper filtrerar nätverkstrafik.

Om NSG blockerar port 10250 på virtuell nätverksnivå fungerar tunnelfunktioner (till exempel loggar och kodkörning) endast för de poddar som är schemalagda på noderna där tunnelpoddar schemaläggs. De andra poddarna fungerar inte eftersom deras noder inte kommer att kunna nå tunneln och tunneln schemaläggs på andra noder. För att verifiera det här tillståndet kan du testa anslutningen med hjälp av netcat -kommandon (nc) eller telnet-kommandon. Du kan köra kommandot az vmss run-command invoke för att genomföra anslutningstestet och kontrollera om det lyckas, överskrider tidsgränsen eller orsakar något annat problem:

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ösning 1: Lägg till en NSG-regel för att tillåta åtkomst till port 10250

Om du använder en NSG och du har specifika begränsningar kontrollerar du att du lägger till en säkerhetsregel som tillåter trafik för port 10250 på virtuell nätverksnivå. Följande Azure Portal bild visar ett exempel på en säkerhetsregel:

Skärmbild av fönstret Lägg till inkommande säkerhetsregel i Azure Portal. Rutan Målportintervall är inställd på 10250 för den nya säkerhetsregeln.

Om du vill vara mer restriktiv kan du endast tillåta åtkomst till port 10250 på undernätsnivå.

Obs!

  • Fältet Prioritet måste justeras i enlighet med detta. Om du till exempel har en regel som nekar flera portar (inklusive port 10250) ska regeln som visas i bilden ha ett lägre prioritetsnummer (lägre tal har högre prioritet). Mer information om Prioritet finns i Säkerhetsregler.

  • Om du inte ser någon beteendeförändring när du har tillämpat den här lösningen kan du återskapa tunnelkomponentpoddarna. Om du tar bort poddarna skapas de på nytt.

Orsak 2: Verktyget Okomplicerad brandvägg (UFW) blockerar port 10250

Obs!

Den här orsaken gäller för alla tunnelkomponenter som du har i AKS-klustret.

Okomplicerad brandvägg (UFW) är ett kommandoradsprogram för att hantera en brandvägg för netfilter . AKS-noder använder Ubuntu. Därför installeras UFW på AKS-noder som standard, men UFW är inaktiverat.

Om UFW är aktiverat blockeras som standard åtkomsten till alla portar, inklusive port 10250. I det här fallet är det osannolikt att du kan använda Secure Shell (SSH) för att ansluta till AKS-klusternoder för felsökning. Det beror på att UFW också blockerar port 22. Om du vill felsöka kan du köra kommandot az vmss run-command invoke för att anropa ett ufw-kommando som kontrollerar om UFW är aktiverat:

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'

Vad händer om resultatet visar att UFW är aktiverat och inte tillåter port 10250 specifikt? I det här fallet fungerar inte tunnelfunktioner (till exempel loggar och kodkörning) för de poddar som är schemalagda på de noder som har UFW aktiverat. Åtgärda problemet genom att använda någon av följande lösningar på UFW.

Viktigt

Innan du använder det här verktyget för att göra ändringar bör du granska AKS-supportprincipen (särskilt nodunderhåll och åtkomst) för att förhindra att klustret hamnar i ett scenario som inte stöds.

Obs!

Om du inte ser någon beteendeförändring när du har tillämpat en lösning kan du återskapa tunnelkomponentpoddarna. Om du tar bort dessa poddar skapas de på nytt.

Lösning 2a: Inaktivera okomplicerad brandvägg

Kör följande az vmss run-command invoke kommando för att inaktivera UFW:

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ösning 2b: Konfigurera okomplicerad brandvägg för att tillåta åtkomst till port 10250

Om du vill tvinga UFW att tillåta åtkomst till port 10250 kör du följande az vmss run-command invoke kommando:

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'

Orsak 3: Verktyget iptables blockerar port 10250

Obs!

Den här orsaken gäller för alla tunnelkomponenter som du har i AKS-klustret.

Med verktyget iptables kan en systemadministratör konfigurera IP-paketfilterreglerna för en Linux-brandvägg. Du kan konfigurera reglerna iptables för att blockera kommunikation på port 10250.

Du kan visa reglerna för dina noder för att kontrollera om port 10250 är blockerad eller om de associerade paketen tas bort. Det gör du genom att köra följande iptables kommando:

iptables --list --line-numbers

I utdata grupperas data i flera kedjor, inklusive INPUT kedjan. Varje kedja innehåller en tabell med regler under följande kolumnrubriker:

  • num (regelnummer)
  • target
  • prot (protokoll)
  • opt
  • source
  • destination

INPUT Innehåller kedjan en regel där målet är DROP, protokollet är tcpoch målet är tcp dpt:10250? I så fall iptables blockeras åtkomsten till målporten 10250.

Lösning 3: Ta bort regeln för iptables som blockerar åtkomst på port 10250

Kör något av följande kommandon för att ta bort iptables regeln som förhindrar åtkomst till port 10250:

iptables --delete INPUT --jump DROP --protocol tcp --source <ip-number> --destination-port 10250
iptables --delete INPUT <input-rule-number>

För att hantera ditt exakta eller potentiella scenario rekommenderar vi att du kontrollerar manuellt iptables genom att köra iptables --help kommandot .

Viktigt

Innan du använder det här verktyget för att göra ändringar bör du granska AKS-supportprincipen (särskilt nodunderhåll och åtkomst) för att förhindra att klustret hamnar i ett scenario som inte stöds.

Orsak 4: Utgående port 1194 eller 9000 är inte öppen

Obs!

Den här orsaken gäller endast tunnel-front poddarna och aks-link .

Finns det några begränsningar för utgående trafik, till exempel från en AKS-brandvägg? I så fall krävs port 9000 för att aktivera rätt funktioner i tunnel-front podden. På samma sätt krävs port 1194 för aks-link podden.

Konnectivity är beroende av port 443. Som standard är den här porten öppen. Därför behöver du inte bekymra dig om anslutningsproblem på den porten.

Lösning 4: Öppna port 1194 eller 9000

Kontrollera att den virtuella installationen tillåter åtkomst till port 1194 eller port 9000. Mer information om de regler och beroenden som krävs finns i Nätverksregler som krävs för Azure Global.

Orsak 5: SNAT-portöversättning (Source Network Address Translation)

Obs!

Den här orsaken gäller för alla tunnelkomponenter som du har i AKS-klustret. Det gäller dock inte för privata AKS-kluster. SNAT-portöversättning (Source Network Address Translation) kan bara uppstå för offentlig kommunikation. För privata AKS-kluster finns API-servern i det virtuella AKS-nätverket eller undernätet.

Om SNAT-portöverbelastning inträffar (misslyckade SNAT-portar) kan noderna inte ansluta till API-servern. Tunnelcontainern finns på API-serversidan. Därför upprättas inte tunnelanslutningen.

Om SNAT-portresurserna är slut misslyckas de utgående flödena tills de befintliga flödena släpper vissa SNAT-portar. Azure Load Balancer återtar SNAT-portarna när flödet stängs. Den använder en tidsgräns på fyra minuter för inaktivitet för att frigöra SNAT-portarna från inaktiva flöden.

Du kan visa SNAT-portarna från aks-lastbalanserarens mått eller tjänstdiagnostiken, enligt beskrivningen i följande avsnitt. Mer information om hur du visar SNAT-portar finns i Hur gör jag för att kolla min utgående anslutningsstatistik?.

MÅTT för AKS-lastbalanserare

Följ dessa steg om du vill använda MÅTT för AKS-lastbalanserare för att visa SNAT-portarna:

  1. I Azure Portal söker du efter och väljer Kubernetes-tjänster.

  2. I listan över Kubernetes-tjänster väljer du namnet på klustret.

  3. I menyfönstret i klustret letar du upp rubriken Inställningar och väljer sedan Egenskaper.

  4. Välj det namn som visas under Infrastrukturresursgrupp.

  5. Välj kubernetes-lastbalanseraren .

  6. I menyfönstret i lastbalanseraren letar du upp rubriken Övervakning och väljer sedan Mått.

  7. Som måtttyp väljer du Antal SNAT-anslutningar.

  8. Välj Tillämpa delning.

  9. Ange Dela upp efter till Anslutningstillstånd.

Tjänstdiagnostik

Följ dessa steg om du vill använda tjänstdiagnostik för att visa SNAT-portarna:

  1. I Azure Portal söker du efter och väljer Kubernetes-tjänster.

  2. I listan över Kubernetes-tjänster väljer du namnet på klustret.

  3. I menyfönstret i klustret väljer du Diagnostisera och lösa problem.

  4. Välj Anslutningsproblem.

  5. Under SNAT-anslutning och portallokering väljer du Visa information.

  6. Om det behövs använder du knappen Tidsintervall för att anpassa tidsramen.

Lösning 5a: Kontrollera att programmet använder anslutningspooler

Det här beteendet kan inträffa eftersom ett program inte återanvänder befintliga anslutningar. Vi rekommenderar att du inte skapar en utgående anslutning per begäran. En sådan konfiguration kan orsaka anslutningsöverbelastning. Kontrollera om programkoden följer bästa praxis och använder anslutningspooler. De flesta bibliotek stöder anslutningspooler. Därför bör du inte behöva skapa en ny utgående anslutning per begäran.

Lösning 5b: Justera de allokerade utgående portarna

Om allt är ok i programmet måste du justera de allokerade utgående portarna. Mer information om utgående portallokering finns i Konfigurera de allokerade utgående portarna.

Lösning 5c: Använd en NAT-gateway (Managed Network Address Translation) när du skapar ett kluster

Du kan konfigurera ett nytt kluster för att använda en NAT-gateway (Managed Network Address Translation) för utgående anslutningar. Mer information finns i Skapa ett AKS-kluster med en hanterad NAT-gateway.

Ansvarsfriskrivning för tredje part

Microsoft tillhandahåller kontaktinformation från tredje part som hjälper dig att hitta ytterligare information om det här ämnet. Denna kontaktinformation kan ändras utan föregående meddelande. Microsoft garanterar inte att kontaktinformation från tredje part är korrekt.

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.