Dela via

Problem med tunnelanslutning

  • Artikel

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å kontrollplanssidan och en klient på klusternodsidan. I den här artikeln beskrivs 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.

Kommentar

Tidigare var tunnel-frontAKS-tunnelkomponenten . Den har nu migrerats till Konnectivity-tjänsten, en överordnad Kubernetes-komponent. Mer information om den här migreringen 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 servern: 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:

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

Kommentar

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

Du kan använda en Azure-nätverkssäkerhetsgrupp (NSG) 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å den virtuella nätverksnivån fungerar tunnelfunktioner (till exempel loggar och kodkörning) endast för de poddar som är schemalagda på de noder 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 utfö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 ska du lägga till en säkerhetsregel som tillåter trafik för port 10250 på den virtuella nätverksnivån. 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å.

Kommentar

  • Fältet Prioritet måste justeras i enlighet med detta. Om du till exempel har en regel som nekar flera portar (inklusive port 10250) bör 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

Kommentar

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

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

Om UFW är aktiverat blockerar det 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. För att 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.

Kommentar

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 de här poddarna skapas de igen.

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

Kommentar

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

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

Du kan visa reglerna för noderna för att kontrollera om port 10250 är blockerad eller om de associerade paketen tas bort. Kör följande iptables kommando för att göra detta:

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? Om den gör iptables det blockeras åtkomsten till målporten 10250.

Lösning 3: Ta bort regeln 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 handboken för 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 öppnas inte

Kommentar

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? Om det finns det 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 förlitar sig på 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 9000

Även om tunnel-front de har flyttats till konnektivitetstjänsten använder tunnel-frontvissa AKS-kluster fortfarande , som förlitar sig på port 9000. Kontrollera att den virtuella installationen eller någon nätverksenhet eller programvara ger åtkomst till port 9000. Mer information om de regler och beroenden som krävs finns i Azure Globala nätverksregler som krävs.

Orsak 5: SNAT-port (Source Network Address Translation)

Kommentar

Den här orsaken gäller för alla tunnelkomponenter som du har i ditt AKS-kluster. Det gäller dock inte för privata AKS-kluster. Portöverbelastning (SNAT) för källnätverksadressöversättning (SNAT) kan endast ske 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 tunnelanslutning.

Om SNAT-portresurserna är uttömda 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 antingen 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 in 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. Leta reda på rubriken Inställningar i menyfönstret i klustret och välj sedan Egenskaper.

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

  5. Välj kubernetes-lastbalanseraren.

  6. Leta reda på rubriken Övervakning i menyfönstret i lastbalanseraren och välj sedan Mått.

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

  8. Välj Använd 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 metodtipsen 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.