Delen via

Eenvoudige problemen met uitgaande verbindingen vanuit een AKS-cluster oplossen

  • Artikel

In dit artikel wordt beschreven hoe u eenvoudige probleemoplossing kunt uitvoeren voor uitgaande verbindingen vanuit een AKS-cluster (Microsoft Azure Kubernetes Service) en foutieve onderdelen identificeert.

Voorwaarden

Scenario's voor uitgaand verkeer in Azure Kubernetes Service

Verkeer dat afkomstig is van het AKS-cluster, ongeacht of dit afkomstig is van een pod of een werkknooppunt, wordt beschouwd als uitgaand verkeer van het cluster. Wat gebeurt er als er een probleem is in de uitgaande stroom voor een AKS-cluster? Voordat u problemen oplost, bekijkt u eerst de scenario's voor de uitgaande verkeersstroom.

Het uitgaande verkeer van een AKS-cluster kan worden geclassificeerd in de volgende categorieën:

  1. Verkeer naar een pod of service in hetzelfde cluster (intern verkeer).

  2. Verkeer naar een apparaat of eindpunt in hetzelfde virtuele netwerk of een ander virtueel netwerk dat gebruikmaakt van peering van virtuele netwerken.

  3. Verkeer naar een on-premises omgeving via een VPN-verbinding of een Azure ExpressRoute-verbinding.

  4. Verkeer buiten het AKS-netwerk via Azure Load Balancer (openbaar uitgaand verkeer).

  5. Verkeer buiten het AKS-netwerk via Azure Firewall of een proxyserver (openbaar uitgaand verkeer).

Intern verkeer

Een basisaanvraagstroom voor intern verkeer van een AKS-cluster lijkt op de stroom die wordt weergegeven in het volgende diagram.

Diagram van een basisaanvraagstroom voor intern verkeer vanuit een AKS-cluster.

Openbaar uitgaand verkeer via Azure Load Balancer

Als het verkeer voor een bestemming op internet is, is de standaardmethode om het verkeer via de Azure Load Balancer te verzenden.

Diagram van een aanvraagstroom voor extern internetverkeer via Azure Load Balancer vanuit een AKS-cluster.

Openbaar uitgaand verkeer via Azure Firewall of een proxyserver

In sommige gevallen moet het uitgaand verkeer worden gefilterd en is mogelijk Azure Firewall vereist.

Diagram van een aanvraagstroom voor extern internetverkeer via Azure Firewall vanuit een AKS-cluster.

Een gebruiker kan een proxyserver toevoegen in plaats van een firewall of een NAT-gateway instellen voor uitgaand verkeer. De basisstroom blijft hetzelfde als in het diagram.

Het is belangrijk om inzicht te hebben in de aard van uitgaand verkeer voor uw cluster, zodat u kunt doorgaan met het oplossen van problemen.

Overwegingen bij het oplossen van problemen

Controleer uw uitgaand apparaat

Wanneer u problemen met uitgaand verkeer in AKS oplost, is het belangrijk om te weten wat uw uitgaand apparaat is (dat wil zeggen het apparaat waarmee het verkeer wordt doorgegeven). Hier kan het uitgaande apparaat een van de volgende onderdelen zijn:

  • Azure-belastingsverdeling
  • Azure Firewall of een aangepaste firewall
  • Een NAT-gateway (Network Address Translation)
  • Een proxyserver

De stroom kan ook verschillen op basis van de bestemming. Intern verkeer (dat wil gezegd, binnen het cluster) gaat bijvoorbeeld niet via het uitgaande apparaat. Het interne verkeer gebruikt alleen het clusternetwerk. Bepaal voor openbaar uitgaand verkeer of er een uitgaand apparaat wordt doorgegeven en controleer dat apparaat.

Elke hop in de verkeersstroom controleren

Nadat u het uitgaande apparaat hebt geïdentificeerd, controleert u de volgende factoren:

  • De bron en de bestemming voor de aanvraag.

  • De hops tussen de bron en de bestemming.

  • De aanvraag-antwoordstroom.

  • De hops die worden uitgebreid door extra beveiligingslagen, zoals de volgende lagen:

    • Firewall
    • Netwerkbeveiligingsgroep (NSG)
    • Netwerkbeleid

Als u een problematische hop wilt identificeren, controleert u de antwoordcodes vóór en na deze hop. Als u wilt controleren of de pakketten correct in een specifieke hop binnenkomen, kunt u doorgaan met pakketopnamen.

HTTP-antwoordcodes controleren

Wanneer u elk onderdeel controleert, haalt u HTTP-antwoordcodes op en analyseert u deze. Deze codes zijn handig om de aard van het probleem te identificeren. De codes zijn vooral handig in scenario's waarin de toepassing reageert op HTTP-aanvragen.

Pakketopnamen van de client en server maken

Als andere stappen voor probleemoplossing geen overtuigend resultaat bieden, neemt u pakketopnamen van de client en server. Pakketopnamen zijn ook handig wanneer niet-HTTP-verkeer tussen de client en de server wordt gebruikt. Zie de volgende artikelen in de handleiding voor het verzamelen van gegevens voor meer informatie over het verzamelen van pakketopnamen voor de AKS-omgeving:

Controlelijsten voor probleemoplossing

Voer de volgende stappen uit voor eenvoudige probleemoplossing voor uitgaand verkeer van een AKS-cluster:

  1. Zorg ervoor dat de DNS-resolutie (Domain Name System) voor het eindpunt correct werkt.

  2. Zorg ervoor dat u het eindpunt kunt bereiken via een IP-adres.

  3. Zorg ervoor dat u het eindpunt vanuit een andere bron kunt bereiken.

  4. Zorg ervoor dat het eindpunt werkt.

  5. Controleer of het cluster een ander extern eindpunt kan bereiken.

  6. Controleer of het verkeer wordt geblokkeerd door een netwerkbeleid.

  7. Controleer of een NSG het verkeer blokkeert.

  8. Controleer of een firewall of proxy het verkeer blokkeert.

  9. Controleer of de AKS-service-principal of beheerde identiteit de vereiste AKS-servicemachtigingen heeft om de netwerkwijzigingen in Azure-resources aan te brengen.

Notitie

Gaat ervan uit dat er geen service-mesh is wanneer u eenvoudige probleemoplossing uitvoert. Als u een service-mesh zoals Istio gebruikt, produceert het ongebruikelijke resultaten voor TCP-verkeer.

Controleer of de pod en het knooppunt het eindpunt kunnen bereiken

Vanuit de pod kunt u een DNS-zoekopdracht uitvoeren naar het eindpunt.

Wat gebeurt er als u de opdracht kubectl exec niet kunt uitvoeren om verbinding te maken met de pod en het DNS Utils-pakket te installeren? In deze situatie kunt u een testpod starten in dezelfde naamruimte als de problematische pod en vervolgens de tests uitvoeren.

Notitie

Als u met de DNS-omzetting of uitgaand verkeer de benodigde netwerkpakketten niet kunt installeren, kunt u de rishasi/ubuntu-netutil:1.0 Docker-installatiekopieën gebruiken. In deze installatiekopieën zijn de vereiste pakketten al geïnstalleerd.

Voorbeeldprocedure voor het controleren van DNS-resolutie van een Linux-pod

  1. Start een testpod in dezelfde naamruimte als de problematische pod:

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

    Nadat de testpod wordt uitgevoerd, krijgt u toegang tot de pod.

  2. Voer de volgende apt-get opdrachten uit om andere hulpprogrammapakketten te installeren:

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

  3. Nadat de pakketten zijn geïnstalleerd, voert u de opdracht nslookup uit om de DNS-omzetting naar het eindpunt te testen:

    $ 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. Probeer de DNS-omzetting rechtstreeks vanaf de upstream-DNS-server. In dit voorbeeld wordt Azure DNS gebruikt:

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

Soms is er een probleem met het eindpunt zelf in plaats van een cluster-DNS. Houd in dergelijke gevallen rekening met de volgende controles:

  1. Controleer of de gewenste poort is geopend op de externe host:

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

  2. Controleer de HTTP-antwoordcode:

    curl -Ivm5 https://microsoft.com

  3. Controleer of u verbinding kunt maken met een ander eindpunt:

    curl -Ivm5 https://kubernetes.io

Voer de volgende stappen uit om te controleren of het eindpunt bereikbaar is vanaf het knooppunt waarin de problematische pod zich bevindt en controleer vervolgens de DNS-instellingen:

  1. Voer het knooppunt in waarin de problematische pod zich bevindt via de foutopsporingspod. Zie Verbinding maken met AKS-clusterknooppunten (Azure Kubernetes Service) voor onderhoud of probleemoplossing voor meer informatie over hoe u dit doet.

  2. Test de DNS-omzetting naar het eindpunt:

    $ 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. Controleer het bestand resolv.conf om te bepalen of de verwachte naamservers worden toegevoegd:

    cat /etc/resolv.conf
cat /run/systemd/resolve/resolv.conf
Voorbeeldprocedure voor het controleren van DE DNS-resolutie van een Windows-pod

  1. Voer een testpod uit in de Windows-knooppuntgroep:

    # 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. Voer de opdracht kubectl exec uit om verbinding te maken met de pod met behulp van PowerShell:

    kubectl exec -it dnsutil-win -- powershell

  3. Voer de cmdlet Resolve-DnsName uit in PowerShell om te controleren of de DNS-resolutie werkt voor het eindpunt:

    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

In een ongebruikelijk scenario met DNS-omzetting krijgen de DNS-query's een correct antwoord van het knooppunt, maar mislukken ze van de pod. Voor dit scenario kunt u overwegen om DNS-omzettingsfouten vanuit de pod te controleren, maar niet vanuit het werkknooppunt. Als u de DNS-resolutie voor een eindpunt in het cluster wilt controleren, kunt u overwegen om de DNS-omzettingsstatus in het cluster te controleren.

Als de DNS-omzetting is geslaagd, gaat u verder met de netwerktests. Controleer anders de DNS-configuratie voor het cluster.

Disclaimerinformatie van derden

Microsoft biedt contactgegevens van derden om u te helpen aanvullende informatie over dit onderwerp te vinden. Deze contactinformatie kan zonder voorafgaande kennisgeving worden gewijzigd. Microsoft garandeert niet de nauwkeurigheid van contactgegevens van derden.

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.