Delen via

Eenvoudige probleemoplossing voor uitgaande verbindingen vanuit een AKS-cluster

  • Artikel

In dit artikel wordt beschreven hoe u eenvoudige probleemoplossing uitvoert voor uitgaande verbindingen vanuit een AKS-cluster (Microsoft Azure Kubernetes Service).

Vereisten

Scenario's voor uitgaand verkeer in Azure Kubernetes Service

In elk netwerkscenario moet u rekening houden met de volgende factoren bij het oplossen van problemen:

  • De bron en de bestemming voor de aanvraag.

  • De hops tussen de bron en de bestemming.

  • De aanvraag-antwoordstroom.

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

    • Firewall
    • Netwerkbeveiligingsgroep (NSG)
    • Netwerkbeleid

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

Als andere stappen voor probleemoplossing geen uitsluitsel geven, neemt u pakketopnamen van de client en server. Pakketopnamen zijn ook handig wanneer er niet-HTTP-verkeer tussen de client en server is betrokken. Zie de volgende artikelen in de handleiding voor het verzamelen van gegevens voor meer informatie over het verzamelen van pakketopnamen voor een AKS-omgeving:

Als u weet hoe u de HTTP-antwoordcodes kunt ophalen en pakketopnamen kunt maken, is het eenvoudiger om een probleem met de netwerkverbinding op te lossen.

Verkeer dat afkomstig is van het AKS-cluster, of het nu afkomstig is van een pod- of werkknooppunt, wordt beschouwd als het uitgaande verkeer van het cluster. Wat gebeurt er als er een probleem is in de uitgaande stroom voor een AKS-cluster? Voordat u problemen oplost, moet u eerst de aard van de aanvraag-antwoordstroom begrijpen.

Het uitgaande verkeer van een AKS-cluster kan worden ingedeeld 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 (openbaar uitgaand verkeer)

In dit document behandelen we de basisstappen voor probleemoplossing voor problemen die van invloed zijn op de uitgaande connectiviteit:

  • Binnen het cluster
  • Binnen de virtuele netwerken
  • Naar de buitenwereld (openbaar verkeer)

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

  • Azure Load Balancer
  • 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.

Intern verkeer

Een eenvoudige aanvraagstroom 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 van een AKS-cluster (Microsoft Azure Kubernetes Service).

Extern 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 van een AKS-cluster (Microsoft Azure Kubernetes Service).

Extern verkeer via Azure Firewall of een proxyserver

In sommige gevallen moet het uitgaande verkeer worden gefilterd en is er mogelijk Azure Firewall nodig.

Diagram van een aanvraagstroom voor extern internetverkeer via Azure Firewall van een AKS-cluster (Microsoft Azure Kubernetes Service).

In plaats van een firewall kan een gebruiker een proxyserver toevoegen. Of de gebruiker wil mogelijk een NAT-gateway instellen voor uitgaand verkeer. De basisstroom blijft hetzelfde als in het diagram.

Het is belangrijk om de aard van de uitgaande stroom voor uw cluster te begrijpen, zodat u kunt doorgaan met het oplossen van problemen.

Controlelijst 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 het netwerk te wijzigen in Azure-resources.

Controleren of de DNS-resolutie voor het eindpunt is geslaagd

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.

Opmerking

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

Hier volgt een voorbeeldprocedure voor het controleren van DNS-resolutie:

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

    kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable

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

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

    apt-get update -y
apt-get install dnsutils -y
apt-get install curl -y
apt-get install netcat -y

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

    $ nslookup microsoft.com
Server:         10.0.0.10
Address:        10.0.0.10#53
...
...
Name:   microsoft.com
Address: 20.53.203.50

  4. Probeer de DNS-resolutie 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

  5. Voer de host opdracht uit om te controleren of de DNS-aanvragen worden gerouteerd naar de upstream-server:

    $ host -a microsoft.com
Trying "microsoft.com.default.svc.cluster.local"
Trying "microsoft.com.svc.cluster.local"
Trying "microsoft.com.cluster.local"
Trying "microsoft.com.00idcnmrrm4edot5s2or1onxsc.bx.internal.cloudapp.net"
Trying "microsoft.com"
Trying "microsoft.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62884
;; flags: qr rd ra; QUERY: 1, ANSWER: 27, AUTHORITY: 0, ADDITIONAL: 5

;; QUESTION SECTION:
;microsoft.com.                 IN      ANY

;; ANSWER SECTION:
microsoft.com.          30      IN      NS      ns1-39.azure-dns.com.
...
...
ns4-39.azure-dns.info.  30      IN      A       13.107.206.39

Received 2121 bytes from 10.0.0.10#53 in 232 ms

  6. 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:1809' --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "windows"}}}' -- powershell "Start-Sleep -s 3600"

  7. Voer de opdracht kubectl exec uit om verbinding te maken met de pod met behulp van PowerShell:

    kubectl exec -it dnsutil-win powershell

  8. Voer de cmdlet Resolve-DnsName in PowerShell uit 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

U moet ook controleren of het eindpunt bereikbaar is vanaf het knooppunt. Controleer vervolgens de DNS-instellingen in het knooppunt. Volg deze stappen:

  1. Maak verbinding met Azure Kubernetes Service clusterknooppunten (AKS) voor onderhoud of probleemoplossing.

  2. Test de DNS-resolutie voor 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 zijn toegevoegd:

    cat /etc/resolv.conf
cat /run/systemd/resolve/resolv.conf

In een ongebruikelijk scenario met DNS-omzetting krijgen de DNS-query's een juiste reactie van het knooppunt, maar mislukken ze van de pod. Voor dit scenario kunt u dns-omzettingsfouten controleren vanuit de pod, maar niet vanuit het werkknooppunt.

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

Controleer of het cluster het eindpunt kan bereiken via het netwerk

Voer de volgende stappen uit om te bepalen of u het eindpunt via het netwerk vanuit uw cluster kunt bereiken:

  1. Controleer de route naar het eindpunt om te bepalen of er een time-out is bij een specifieke bewerking:

    kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable
apt-get install -y traceroute && apt-get install netcat -y
traceroute -T microsoft.com -m 50 -p 443

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

    nc -z -v microsoft.com 443

  3. Controleer de HTTP-antwoordcode:

    curl -Iv https://microsoft.com

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

    curl -Iv https://kubernetes.io

Disclaimerinformatie van derden

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

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 Feedback-community van Azure.