Verbindingsproblemen oplossen met een app die wordt gehost in een AKS-cluster

Artikel
11/19/2024

In de huidige dynamische cloudomgevingen is naadloze connectiviteit met toepassingen die worden gehost in AKS-clusters (Azure Kubernetes Service) essentieel voor het behoud van optimale prestaties en gebruikerservaring. In dit artikel wordt beschreven hoe u verbindingsproblemen oplost en oplost die worden veroorzaakt door verschillende factoren, waaronder problemen aan de toepassingszijde, netwerkbeleid, netwerkbeveiligingsgroepregels (NSG)-regels of andere.

Notitie

Als u veelvoorkomende problemen wilt oplossen wanneer u verbinding probeert te maken met de AKS-API-server, raadpleegt u Basic-probleemoplossing van clusterverbindingsproblemen met de API-server.

Voorwaarden

Het hulpprogramma Client-URL (cURL) of een vergelijkbaar opdrachtregelprogramma.
Het apt-get-opdrachtregelprogramma voor het verwerken van pakketten.
Het opdrachtregelprogramma Netcat (nc) voor TCP-verbindingen.
Het Kubernetes kubectl-hulpprogramma of een vergelijkbaar hulpprogramma om verbinding te maken met het cluster. Als u kubectl wilt installeren met behulp van Azure CLI, voert u de opdracht az aks install-cli uit.

Factoren die in acht moeten worden genomen

In deze sectie worden stappen beschreven voor probleemoplossing als u problemen ondervindt wanneer u verbinding probeert te maken met de toepassing die wordt gehost in een AKS-cluster.

In elk netwerkscenario moeten beheerders rekening houden met de volgende belangrijke factoren bij het oplossen van problemen:

Wat is de bron en de bestemming voor een aanvraag?
Wat zijn de hops tussen de bron en de bestemming?
Wat is de aanvraagresponsstroom?
Welke hops extra beveiligingslagen hebben, zoals de volgende items:
- Firewall
- Netwerkbeveiligingsgroep (NSG)
- Netwerkbeleid

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 en zijn vooral nuttig in scenario's waarin de toepassing reageert op HTTP-aanvragen.

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:

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

Basisnetwerkstroom voor toepassingen in AKS

Wanneer toepassingen worden weergegeven met behulp van het servicetype Azure Load Balancer, is de aanvraagstroom voor toegang tot deze toepassingen als volgt:

>> AKS-load balancer-IP-adres >> van client-DNS-naam >> AKS-knooppunten >> pods

Er zijn andere situaties waarin extra onderdelen betrokken kunnen zijn. Bijvoorbeeld:

Het beheerde NGINX-toegangsbeheerobject met de invoegtoepassing voor toepassingsroutering is ingeschakeld.
De toepassingsgateway wordt gebruikt via de Application Gateway-ingangscontroller (AGIC) in plaats van Azure Load Balancer.
Azure Front Door en API Management kunnen worden gebruikt boven op de load balancer.
Het proces maakt gebruik van een interne load balancer.
De verbinding eindigt mogelijk niet op de pod en de aangevraagde URL. Dit kan afhankelijk zijn van of de pod verbinding kan maken met een andere entiteit, zoals een database of een andere service in hetzelfde cluster.

Het is belangrijk om inzicht te hebben in de aanvraagstroom voor de toepassing.

Een eenvoudige aanvraagstroom naar toepassingen in een AKS-cluster lijkt op de stroom die wordt weergegeven in het volgende diagram.

Problemen met binnenuit oplossen

Het oplossen van connectiviteitsproblemen kan veel controles omvatten, maar de binnenste benadering kan helpen de oorzaak van het probleem te vinden en het knelpunt te identificeren. In deze benadering begint u bij de pod zelf en controleert u of de toepassing reageert op het IP-adres van de pod. Controleer vervolgens elk onderdeel op zijn beurt tot de eindclient.

Stap 1: Controleer of de pod wordt uitgevoerd en of de app of container in de pod correct reageert

Voer een van de volgende kubectl get-opdrachten uit om te bepalen of de pod wordt uitgevoerd:

# List pods in the specified namespace.
kubectl get pods -n <namespace-name>

# List pods in all namespaces.
kubectl get pods -A

Wat gebeurt er als de pod niet wordt uitgevoerd? In dit geval controleert u de pod-gebeurtenissen met behulp van de opdracht kubectl describe :

kubectl describe pod <pod-name> -n <namespace-name>

Als de pod zich niet in een Ready of Running bepaalde status bevindt of als deze vaak opnieuw is opgestart, controleert u de kubectl describe uitvoer. De gebeurtenissen tonen eventuele problemen die verhinderen dat u de pod kunt starten. Als de pod is gestart, is de toepassing in de pod mogelijk mislukt, waardoor de pod opnieuw wordt opgestart. Los de pod dienovereenkomstig op om ervoor te zorgen dat deze zich in een geschikte staat bevindt.

Als de pod wordt uitgevoerd, kan het ook handig zijn om de logboeken te controleren van de containers die zich in de pod bevinden. Voer de volgende reeks kubectl-logboekopdrachten uit:

kubectl logs <pod-name> -n <namespace-name>

# Check logs for an individual container in a multicontainer pod.
kubectl logs <pod-name> -n <namespace-name> -c <container-name>

# Dump pod logs (stdout) for a previous container instance.
kubectl logs <pod-name> --previous                      

# Dump pod container logs (stdout, multicontainer case) for a previous container instance.
kubectl logs <pod-name> -c <container-name> --previous

Wordt de pod uitgevoerd? In dit geval test u de connectiviteit door een testpod in het cluster te starten. Vanuit de testpod hebt u rechtstreeks toegang tot het IP-adres van de pod van de toepassing en controleert u of de toepassing correct reageert. Voer de kubectl-uitvoering en apt-getcURL opdrachten als volgt uit:

# Start a test pod in the cluster:
kubectl run -it --rm aks-ssh --image=debian:stable

# After the test pod is running, you will gain access to the pod.
# Then you can run the following commands:
apt-get update -y && apt-get install dnsutils -y && apt-get install curl -y && apt-get install netcat-traditional -y

# After the packages are installed, test the connectivity to the application pod:
curl -Iv http://<pod-ip-address>:<port>

Voor toepassingen die luisteren naar andere protocollen, kunt u relevante hulpprogramma's in de testpod installeren, zoals het netcat-hulpprogramma, en vervolgens de verbinding met de toepassingspod controleren door de volgende opdracht uit te voeren:

# After the packages are installed, test the connectivity to the application pod using netcat/nc command:
nc -z -v <pod-ip-address> <port>

Zie Fouten opsporen in actieve pods voor meer opdrachten voor het oplossen van problemen met pods.

Stap 2: Controleren of de toepassing bereikbaar is vanuit de service

Voor scenario's waarin de toepassing in de pod wordt uitgevoerd, kunt u zich voornamelijk richten op het oplossen van problemen met hoe de pod beschikbaar wordt gesteld.

Wordt de pod weergegeven als een service? Controleer in dit geval de service-gebeurtenissen. Controleer ook of het IP-adres van de pod en de toepassingspoort beschikbaar zijn als eindpunt in de servicebeschrijving:

# Check the service details.
kubectl get svc -n <namespace-name>

# Describe the service.
kubectl describe svc <service-name> -n <namespace-name>

Controleer of het IP-adres van de pod aanwezig is als eindpunt in de service, zoals in het volgende voorbeeld:

$ kubectl get pods -o wide  # Check the pod's IP address.
NAME            READY   STATUS        RESTARTS   AGE   IP            NODE                                
my-pod          1/1     Running       0          12m   10.244.0.15   aks-agentpool-000000-vmss000000  

$ kubectl describe service my-cluster-ip-service  # Check the endpoints in the service.
Name:              my-cluster-ip-service
Namespace:         default
Selector:          app=my-pod
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.0.174.133
IPs:               10.0.174.133
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.244.0.15:80     # <--- Here

$ kubectl get endpoints  # Check the endpoints directly for verification.
NAME                      ENDPOINTS           AGE
my-cluster-ip-service     10.244.0.15:80      14m

Als de eindpunten niet verwijzen naar het juiste IP-adres van de pod, controleert u de Labels en Selectors voor de pod en de service.

Zijn de eindpunten in de service juist? Zo ja, dan opent u de service en controleert u of de toepassing bereikbaar is.

Toegang tot de ClusterIP-service

Voor de ClusterIP service kunt u een testpod starten in het cluster en toegang krijgen tot het IP-adres van de service:

# Start a test pod in the cluster:
kubectl run -it --rm aks-ssh --image=debian:stable
  
# After the test pod is running, you will gain access to the pod.
# Then, you can run the following commands:
apt-get update -y && apt-get install dnsutils -y && apt-get install curl -y && apt-get install netcat-traditional -y
  
# After the packages are installed, test the connectivity to the service:
curl -Iv http://<service-ip-address>:<port>

# After the packages are installed, test the connectivity to the application pod using netcat/nc command:
nc -z -v <pod-ip-address> <port>

Als de vorige opdracht geen geschikt antwoord retourneert, controleert u de service-gebeurtenissen op eventuele fouten.

Toegang tot de LoadBalancer-service

Voor de LoadBalancer service hebt u toegang tot het IP-adres van de load balancer van buiten het cluster.

curl -Iv http://<service-ip-address>:<port>

nc -z -v <pod-ip-address> <port>

Retourneert het IP-adres van de LoadBalancer service een correct antwoord? Als dit niet het probleem is, voert u de volgende stappen uit:

Controleer de gebeurtenissen van de service.
Controleer of de netwerkbeveiligingsgroepen (NSG's) die zijn gekoppeld aan de AKS-knooppunten en het AKS-subnet het binnenkomende verkeer op de servicepoort toestaan.

Zie Foutopsporingsservices voor meer opdrachten voor het oplossen van problemen met services.

Scenario's die een inkomend verkeer gebruiken in plaats van een service

Voor scenario's waarin de toepassing wordt weergegeven met behulp van een Ingress resource, lijkt de verkeersstroom op de volgende voortgang:

Load balancer van client-DNS-naam >> >> of IP-adres >> van toepassingsgatewaycontrollerpods in de clusterservice >> of pods

U kunt hier ook de interne benadering van probleemoplossing toepassen. U kunt ook de details van de toegangsbeheerobject-kubernetes-resource en toegangsbeheerobjectcontroller controleren voor meer informatie:

$ kubectl get ing -n <namespace-of-ingress>  # Checking the ingress details and events.
NAME                         CLASS    HOSTS                ADDRESS       PORTS     AGE
hello-world-ingress          <none>   myapp.com            20.84.x.x     80, 443   7d22h

$ kubectl describe ing -n <namespace-of-ingress> hello-world-ingress
Name:             hello-world-ingress
Namespace:        <namespace-of-ingress>
Address:          20.84.x.x
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
TLS:
  tls-secret terminates myapp.com
Rules:
  Host                Path  Backends
  ----                ----  --------
  myapp.com
                      /blog   blog-service:80 (10.244.0.35:80)
                      /store  store-service:80 (10.244.0.33:80)

Annotations:          cert-manager.io/cluster-issuer: letsencrypt
                      kubernetes.io/ingress.class: nginx
                      nginx.ingress.kubernetes.io/rewrite-target: /$1
                      nginx.ingress.kubernetes.io/use-regex: true
Events:
  Type    Reason  Age    From                      Message
  ----    ------  ----   ----                      -------
  Normal  Sync    5m41s  nginx-ingress-controller  Scheduled for sync
  Normal  Sync    5m41s  nginx-ingress-controller  Scheduled for sync

Dit voorbeeld bevat een Ingress resource die:

Luistert op de myapp.com host.
Er zijn twee Path tekenreeksen geconfigureerd.
Routes naar twee Services in de back-end.

Controleer of de back-endservices worden uitgevoerd en reageer op de poort die wordt vermeld in de beschrijving van inkomend verkeer:

$ kubectl get svc -n <namespace-of-ingress>
NAMESPACE       NAME                                     TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                      
ingress-basic   blog-service                             ClusterIP      10.0.155.154   <none>        80/TCP                       
ingress-basic   store-service                            ClusterIP      10.0.61.185    <none>        80/TCP             
ingress-basic   nginx-ingress-ingress-nginx-controller   LoadBalancer   10.0.122.148   20.84.x.x     80:30217/TCP,443:32464/TCP

Controleer de logboeken voor de controllerpods voor inkomend verkeer als er een fout optreedt:

$ kubectl get pods -n <namespace-of-ingress>  # Get the ingress controller pods.
NAME                                                     READY   STATUS    RESTARTS   AGE
aks-helloworld-one-56c7b8d79d-6zktl                      1/1     Running   0          31h
aks-helloworld-two-58bbb47f58-rrcv7                      1/1     Running   0          31h
nginx-ingress-ingress-nginx-controller-9d8d5c57d-9vn8q   1/1     Running   0          31h
nginx-ingress-ingress-nginx-controller-9d8d5c57d-grzdr   1/1     Running   0          31h

$ # Check logs from the pods.
$ kubectl logs -n ingress-basic nginx-ingress-ingress-nginx-controller-9d8d5c57d-9vn8q

Wat gebeurt er als de client aanvragen indient naar de hostnaam of het IP-adres van inkomend verkeer, maar er geen vermeldingen worden weergegeven in de logboeken van de controllerpod voor inkomend verkeer? In dit geval bereiken de aanvragen mogelijk het cluster niet en ontvangt de gebruiker mogelijk een Connection Timed Out foutbericht.

Een andere mogelijkheid is dat de onderdelen boven op de ingangspods, zoals Load Balancer of Application Gateway, de aanvragen niet correct naar het cluster routeren. Als dit waar is, kunt u de back-endconfiguratie van deze resources controleren.

Als u een Connection Timed Out foutbericht ontvangt, controleert u de netwerkbeveiligingsgroep die is gekoppeld aan de AKS-knooppunten. Controleer ook het AKS-subnet. Het kan het verkeer van de load balancer of toepassingsgateway naar de AKS-knooppunten blokkeren.

Zie het oplossen van problemen met inkomend verkeer (zoals Nginx Inkomend verkeer) voor meer informatie over het oplossen van problemen met inkomend verkeer.

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.

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.

Delen via