Dela via

Felsöka anslutningsproblem till en app som finns i ett AKS-kluster

  • Artikel

Anslutningsproblem till ett AKS-kluster (Microsoft Azure Kubernetes Service) kan innebära olika saker. I vissa fall kan det innebära att anslutningen till API-servern påverkas (till exempel med kubectl). I andra fall kan det innebära att vanliga anslutningsproblem påverkar ett program som finns i AKS-klustret. Den här artikeln beskriver hur du felsöker problem med AKS-klusteranslutning.

Obs!

Information om hur du felsöker vanliga problem när du försöker ansluta till AKS API-servern finns i Grundläggande felsökning av problem med klusteranslutning med API-servern.

Förutsättningar

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

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

  • 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 .

Faktorer att tänka på

Det här avsnittet beskriver felsökningssteg som du kan vidta om du har problem när du försöker ansluta till programmet som finns i ett AKS-kluster.

I alla nätverksscenarion bör administratörer ta hänsyn till följande viktiga faktorer vid felsökning:

  • Vad är källan och målet för en begäran?

  • Vad är hoppen mellan källan och målet?

  • Vad är flödet för begäran-svar?

  • Vilka hopp har extra säkerhetslager ovanpå, till exempel följande:

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

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

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

Om du vet hur du hämtar HTTP-svarskoderna och tar in paketinsamlingar blir det enklare att felsöka ett problem med nätverksanslutningen.

Grundläggande nätverksflöde för program i AKS

I allmänhet är begärandeflödet för åtkomst till program som finns i ett AKS-kluster följande:

Klientens >> DNS-namn >> AKS-lastbalanserarens IP-adress >> AKS-noder >> Poddar

Det finns andra möjliga situationer där extra komponenter kan vara inblandade. Till exempel:

  • Programgatewayen används via Application Gateway Ingress Controller (AGIC) i stället för Azure Load Balancer.
  • Azure Front Door och API Management kan användas ovanpå lastbalanseraren.
  • Processen använder en intern lastbalanserare.
  • Anslutningen kanske inte slutar på podden och den begärda URL:en. Detta kan bero på om podden kan ansluta till en annan entitet, till exempel en databas eller någon annan tjänst i samma kluster.

Det är viktigt att förstå begärandeflödet för programmet.

Ett grundläggande flöde för begäranden till program i ett AKS-kluster skulle likna det flöde som visas i följande diagram.

Diagram över ett grundläggande flöde för begäranden till program i ett Azure Kubernetes Service-kluster (A K S).

Felsökning inifrån och ut

Felsökning av anslutningsproblem kan innebära många kontroller, men inifrån och ut-metoden kan hjälpa dig att hitta orsaken till problemet och identifiera flaskhalsen. I den här metoden börjar du på själva podden och kontrollerar om programmet svarar på poddens IP-adress. Kontrollera sedan varje komponent i upp till slutklienten.

Steg 1: Kontrollera om podden körs och att appen eller containern i podden svarar korrekt

För att avgöra om podden körs kör du något av följande kubectl get-kommandon :

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

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

Vad händer om podden inte körs? I det här fallet kontrollerar du poddhändelserna med hjälp av kommandot kubectl describe :

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

Om podden inte är i ett Ready tillstånd, Running eller om den har startats om många gånger, kontrollerar du kubectl describe utdata. Händelserna avslöjar eventuella problem som hindrar dig från att starta podden. Eller, om podden har startats, kan programmet i podden ha misslyckats, vilket gör att podden startas om. Felsök podden i enlighet med detta för att se till att den är i ett lämpligt tillstånd.

Om podden körs kan det också vara användbart att kontrollera loggarna för poddarna och containrarna som finns i dem. Kör följande serie kubectl-loggkommandon :

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

Körs podden? I det här fallet testar du anslutningen genom att starta en testpodd i klustret. Från testpodden kan du direkt komma åt programmets podd-IP-adress och kontrollera om programmet svarar korrekt. Kör kommandona kubectl run, apt-getoch cURL enligt följande:

# 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

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

För program som lyssnar på andra protokoll kan du installera relevanta verktyg i testpodden och sedan kontrollera anslutningen till programpodden.

Fler kommandon för att felsöka poddar finns i Felsöka poddar som körs.

Steg 2: Kontrollera om programmet kan nås från tjänsten

För scenarier där programmet i podden körs kan du främst fokusera på att felsöka hur podden exponeras.

Exponeras podden som en tjänst? I det här fallet kontrollerar du tjänsthändelserna. Kontrollera också om podd-IP-adressen och programporten är tillgängliga som en slutpunkt i tjänstbeskrivningen:

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

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

Kontrollera om poddens IP-adress finns som en slutpunkt i tjänsten, som i följande exempel:

$ 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

Om slutpunkterna inte pekar på rätt podd-IP-adress kontrollerar du Labels podden och Selectors tjänsten.

Är slutpunkterna i tjänsten korrekta? I så fall får du åtkomst till tjänsten och kontrollerar om programmet kan nås.

Få åtkomst till ClusterIP-tjänsten

För tjänsten ClusterIP kan du starta en testpodd i klustret och komma åt tjänstens IP-adress:

Diagram över hur du använder en testpodd i ett Azure Kubernetes Service-kluster (A K S) för att komma åt klustrets I P-adress. 

# 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
  
# After the packages are installed, test the connectivity to the service:
curl -Iv http://<service-ip-address>:<port>

Om föregående kommando inte returnerar ett lämpligt svar kontrollerar du om det finns några fel i tjänsthändelserna.

Få åtkomst till LoadBalancer-tjänsten

För tjänsten LoadBalancer kan du komma åt lastbalanserarens IP-adress utanför klustret.

Diagram över en testanvändare som kommer åt lastbalanserarens I P-adress utanför ett Azure Kubernetes Service(A K S)-kluster. 

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

Returnerar tjänstens LoadBalancer IP-adress ett korrekt svar? Om den inte gör det följer du dessa steg:

  1. Verifiera händelserna i tjänsten.

  2. Kontrollera att nätverkssäkerhetsgrupper (NSG:er) som är associerade med AKS-noderna och AKS-undernätet tillåter inkommande trafik på tjänstporten.

Fler kommandon för att felsöka tjänster finns i Felsöka tjänster.

Scenarier som använder en ingress i stället för en tjänst

För scenarier där programmet exponeras med hjälp av en Ingress resurs liknar trafikflödet följande status:

Klientens >> DNS-namn >> Lastbalanserare eller IP-adressingresspoddar >> för programgateway i klustertjänsten >> eller poddar

Diagram över nätverkstrafikflödet när en app i ett Azure Kubernetes Service-kluster (A K S) exponeras med hjälp av en ingressresurs.

Du kan även använda inifrån och ut-metoden för felsökning här. Du kan också kontrollera information om ingress- och ingresskontrollanten för mer information:

$ 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

Det här exemplet innehåller en Ingress resurs som:

  • Lyssnar på myapp.com värden.
  • Har två Path strängar konfigurerade.
  • Dirigerar till två Services i serverdelen.

Kontrollera att serverdelstjänsterna körs och svara på porten som anges i ingressbeskrivningen:

$ 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

Kontrollera loggarna för ingresskontrollantpoddarna om det finns ett fel:

$ 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

Vad händer om klienten skickar begäranden till inkommande värdnamn eller IP-adress, men inga poster visas i loggarna för ingresskontrollantens podd? I det här fallet kanske begärandena inte når klustret och användaren kanske får ett Connection Timed Out felmeddelande.

En annan möjlighet är att komponenterna ovanpå ingress-poddarna, till exempel Load Balancer eller Application Gateway, inte dirigerar begäranden till klustret korrekt. Om detta är sant kan du kontrollera serverdelskonfigurationen för dessa resurser.

Om du får ett Connection Timed Out felmeddelande kontrollerar du nätverkssäkerhetsgruppen som är associerad med AKS-noderna. Kontrollera även AKS-undernätet. Det kan blockera trafiken från lastbalanseraren eller programgatewayen till AKS-noderna.

Mer information om hur du felsöker ingress (till exempel Nginx-ingress) finns i felsökning av ingress-nginx.

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.

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.