Dela via

Grundläggande felsökning av utgående anslutningar från ett AKS-kluster

  • Artikel

I den här artikeln beskrivs hur du utför grundläggande felsökning av utgående anslutningar från ett AkS-kluster (Microsoft Azure Kubernetes Service) och identifierar felaktiga komponenter.

Förutsättningar

  • Kubernetes kubectl-verktyget eller ett liknande verktyg för att ansluta till klustret. Om du vill installera kubectl med hjälp av Azure CLI kör du kommandot az aks install-cli .

  • Kommandoradsverktyget apt-get för hantering av paket.

  • Verktyget Klient-URL (cURL) eller ett liknande kommandoradsverktyg.

  • Kommandoradsverktyget nslookup (dnsutils) för att kontrollera DNS-matchning.

Scenarier för utgående trafik i Azure Kubernetes Service

Trafik som kommer från AKS-klustret, oavsett om den kommer från en podd eller en arbetsnod, anses vara den utgående trafiken från klustret. Vad händer om det finns ett problem i det utgående flödet för ett AKS-kluster? Innan du felsöker bör du först titta på scenarierna för utgående trafikflöde.

Utgående trafik från ett AKS-kluster kan klassificeras i följande kategorier:

  1. Trafik till en podd eller tjänst i samma kluster (intern trafik).

  2. Trafik till en enhet eller slutpunkt i samma virtuella nätverk eller ett annat virtuellt nätverk som använder peering för virtuella nätverk.

  3. Trafik till en lokal miljö via en VPN-anslutning eller en Azure ExpressRoute-anslutning.

  4. Trafik utanför AKS-nätverket via Azure Load Balancer (offentlig utgående trafik).

  5. Trafik utanför AKS-nätverket via Azure Firewall eller en proxyserver (offentlig utgående trafik).

Intern trafik

Ett grundläggande flöde för begäranden för intern trafik från ett AKS-kluster liknar det flöde som visas i följande diagram.

Diagram över ett grundläggande flöde för begäranden för intern trafik från ett AKS-kluster.

Offentlig utgående trafik via Azure Load Balancer

Om trafiken är för ett mål på Internet är standardmetoden att skicka trafiken via Azure Load Balancer.

Diagram över ett begärandeflöde för extern Internettrafik via Azure Load Balancer från ett AKS-kluster.

Offentlig utgående trafik via Azure Firewall eller en proxyserver

I vissa fall måste utgående trafik filtreras och det kan kräva Azure Firewall.

Diagram över ett begärandeflöde för extern Internettrafik via Azure Firewall från ett AKS-kluster.

En användare kanske vill lägga till en proxyserver i stället för en brandvägg eller konfigurera en NAT-gateway för utgående trafik. Det grundläggande flödet förblir detsamma som i diagrammet.

Det är viktigt att du förstår utgående flöde för klustret så att du kan fortsätta felsökningen.

Överväganden vid felsökning

Kontrollera din utgående enhet

När du felsöker utgående trafik i AKS är det viktigt att veta vad din utgående enhet är (dvs. den enhet genom vilken trafiken passerar). Här kan utgående enhet vara en av följande komponenter:

  • Azure Load Balancer
  • Azure Firewall eller en anpassad brandvägg
  • En NAT-gateway (network address translation)
  • En proxyserver

Flödet kan också skilja sig beroende på målet. Intern trafik (det vill säga i klustret) går till exempel inte via utgående enhet. Den interna trafiken skulle endast använda klustrets nätverk. För offentlig utgående trafik kontrollerar du om det finns en utgående enhet som passerar och kontrollerar enheten.

Kontrollera varje hopp i trafikflödet

När du har identifierat utgående enhet kontrollerar du följande faktorer:

  • Källan och målet för begäran.

  • Hoppen mellan källan och målet.

  • Flödet för begäran-svar.

  • Hoppen som förbättras av extra säkerhetslager, till exempel följande lager:

    • Brandvägg
    • Nätverkssäkerhetsgrupp (NSG)
    • Nätverksprincip

Om du vill identifiera ett problematiskt hopp kontrollerar du svarskoderna före och efter det. Om du vill kontrollera om paketen anländer korrekt i ett visst hopp kan du fortsätta med paketinsamlingar.

Kontrollera HTTP-svarskoder

När du kontrollerar varje komponent hämtar och analyserar du HTTP-svarskoder. Dessa koder är användbara för att identifiera problemets art. Koderna är särskilt användbara i scenarier där programmet svarar på HTTP-begäranden.

Ta paketinsamlingar från klienten och servern

Om andra felsökningssteg inte ger några avgörande resultat kan du ta paketinsamlingar från klienten och servern. Paketinsamlingar är också användbara när icke-HTTP-trafik ingår mellan klienten och servern. Mer information om hur du samlar in paketinsamlingar för AKS-miljön finns i följande artiklar i datainsamlingsguiden:

Felsöka checklistor

Följ dessa steg för grundläggande felsökning för utgående trafik från ett AKS-kluster:

  1. Kontrollera att DNS-matchningen (Domain Name System) för slutpunkten fungerar korrekt.

  2. Se till att du kan nå slutpunkten via en IP-adress.

  3. Kontrollera att du kan nå slutpunkten från en annan källa.

  4. Kontrollera att slutpunkten fungerar.

  5. Kontrollera om klustret kan nå någon annan extern slutpunkt.

  6. Kontrollera om en nätverksprincip blockerar trafiken.

  7. Kontrollera om en NSG blockerar trafiken.

  8. Kontrollera om en brandvägg eller proxy blockerar trafiken.

  9. Kontrollera om AKS-tjänstens huvudnamn eller hanterade identitet har de behörigheter för AKS-tjänsten som krävs för att göra nätverksändringar i Azure-resurser.

Kommentar

Förutsätter att det inte finns något servicenät när du utför grundläggande felsökning. Om du använder ett tjänstnät, till exempel Istio, ger det ovanliga resultat för TCP-baserad trafik.

Kontrollera om podden och noden kan nå slutpunkten

Inifrån podden kan du köra en DNS-sökning till slutpunkten.

Vad händer om du inte kan köra kommandot kubectl exec för att ansluta till podden och installera DNS Utils-paketet? I det här fallet kan du starta en testpodd i samma namnområde som den problematiska podden och sedan köra testerna.

Kommentar

Om DNS-matchningen eller utgående trafik inte låter dig installera nödvändiga nätverkspaket kan du använda Docker-avbildningen rishasi/ubuntu-netutil:1.0 . I den här avbildningen är de nödvändiga paketen redan installerade.

Exempelprocedur för att kontrollera DNS-matchning för en Linux-podd

  1. Starta en testpodd i samma namnområde som den problematiska podden:

    kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "linux"}}}'

    När testpodden har körts får du åtkomst till podden.

  2. Kör följande apt-get kommandon för att installera andra verktygspaket:

    # Update and install tool packages
apt-get update && apt-get install -y dnsutils curl

  3. När paketen har installerats kör du kommandot nslookup för att testa DNS-matchningen till slutpunkten:

    $ nslookup microsoft.com # Microsoft.com is used as an example
Server:         <server>
Address:        <server IP address>#53
...
...
Name:   microsoft.com
Address: 20.53.203.50

  4. Prova DNS-matchningen direkt från den överordnade DNS-servern. I det här exemplet används Azure DNS:

    $ nslookup microsoft.com 168.63.129.16
Server:         168.63.129.16
Address:        168.63.129.16#53
...
...
Address: 20.81.111.85

Ibland är det problem med själva slutpunkten i stället för ett kluster-DNS. I sådana fall bör du överväga följande kontroller:

  1. Kontrollera om den önskade porten är öppen på fjärrvärden:

    curl -Ivm5 telnet://microsoft.com:443

  2. Kontrollera HTTP-svarskoden:

    curl -Ivm5 https://microsoft.com

  3. Kontrollera om du kan ansluta till någon annan slutpunkt:

    curl -Ivm5 https://kubernetes.io

Kontrollera att slutpunkten kan nås från noden där den problematiska podden finns och sedan verifiera DNS-inställningarna genom att följa dessa steg:

  1. Ange noden där den problematiska podden finns i via felsökningspodden. Mer information om hur du gör detta finns i Ansluta till AKS-klusternoder (Azure Kubernetes Service) för underhåll eller felsökning.

  2. Testa DNS-matchningen till slutpunkten:

    $ nslookup  microsoft.com
Server:         168.63.129.16
Address:        168.63.129.16#53

Non-authoritative answer:
Name:   microsoft.com
Address: 20.112.52.29
Name:   microsoft.com
Address: 20.81.111.85
Name:   microsoft.com
Address: 20.84.181.62
Name:   microsoft.com
Address: 20.103.85.33
Name:   microsoft.com
Address: 20.53.203.50

  3. Kontrollera filen resolve.conf för att avgöra om de förväntade namnservrarna läggs till:

    cat /etc/resolv.conf
cat /run/systemd/resolve/resolv.conf
Exempelprocedur för att kontrollera DNS-matchning för en Windows-podd

  1. Kör en testpodd i Windows-nodpoolen:

    # For a Windows environment, use the Resolve-DnsName cmdlet.
kubectl run dnsutil-win --image='mcr.microsoft.com/windows/servercore:ltsc2022' --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "windows"}}}' -- powershell "Start-Sleep -s 3600"

  2. Kör kommandot kubectl exec för att ansluta till podden med hjälp av PowerShell:

    kubectl exec -it dnsutil-win -- powershell

  3. Kör cmdleten Resolve-DnsName i PowerShell för att kontrollera om DNS-matchningen fungerar för slutpunkten:

    PS C:\> Resolve-DnsName www.microsoft.com 

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
www.microsoft.com              CNAME  20    Answer     www.microsoft.com-c-3.edgekey.net
www.microsoft.com-c-3.edgekey. CNAME  20    Answer     www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net
net
www.microsoft.com-c-3.edgekey. CNAME  20    Answer     e13678.dscb.akamaiedge.net
net.globalredir.akadns.net

Name       : e13678.dscb.akamaiedge.net 
QueryType  : AAAA
TTL        : 20
Section    : Answer
IP6Address : 2600:1408:c400:484::356e   


Name       : e13678.dscb.akamaiedge.net 
QueryType  : AAAA
TTL        : 20
Section    : Answer
IP6Address : 2600:1408:c400:496::356e 


Name       : e13678.dscb.akamaiedge.net
QueryType  : A
TTL        : 12
Section    : Answer
IP4Address : 23.200.197.152

I ett ovanligt scenario som omfattar DNS-matchning får DNS-frågorna ett korrekt svar från noden men misslyckas från podden. I det här scenariot kan du överväga att kontrollera DNS-matchningsfel inifrån podden, men inte från arbetsnoden. Om du vill kontrollera DNS-matchning för en slutpunkt i klustret kan du kontrollera DNS-matchningsstatusen i klustret.

Om DNS-matchningen lyckas fortsätter du till nätverkstesterna. Annars kontrollerar du DNS-konfigurationen för klustret.

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.