Tillfälliga timeout-fel eller serverproblem vid åtkomst till programmet på AKS

Artikel
04/12/2024

Den här artikeln beskriver hur du felsöker tillfälliga anslutningsproblem som påverkar dina program som finns i ett Azure Kubernetes Service -kluster (AKS).

Förutsättningar

Verktyget Klient-URL (cURL) eller ett liknande kommandoradsverktyg.
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 .

Symptom

När du kör ett cURL-kommando får du ibland felmeddelandet "Tidsgränsen har överskridits". Utdata kan likna följande text:

$ # One connection is successful, which results in a HTTP 200 response.
$ curl -Iv http://20.62.x.x
*   Trying 20.62.x.x:80...
* Connected to 20.62.x.x (20.62.x.x) port 80 (#0)
...
...
< HTTP/1.1 200 OK
HTTP/1.1 200 OK

$ # Another connection is unsuccessful, because it gets timed out.
$ curl -Iv http://20.62.x.x
*   Trying 20.62.x.x:80...
* connect to 20.62.x.x port 80 failed: Timed out
* Failed to connect to 20.62.x.x port 80 after 21050 ms: Timed out
* Closing connection 0
curl: (28) Failed to connect to 20.62.x.x port 80 after 21050 ms: Timed out

$ # Then the next connection is again successful.
$ curl -Iv http://20.62.x.x
*   Trying 20.62.x.x:80...
* Connected to 20.62.x.x (20.62.x.x) port 80 (#0)
...
...
< HTTP/1.1 200 OK
HTTP/1.1 200 OK

Orsak

Tillfälliga timeouter tyder på problem med komponentprestanda, till skillnad från nätverksproblem.

I det här scenariot är det viktigt att kontrollera komponenternas användning och hälsa. Du kan använda inifrån och ut-tekniken för att kontrollera statusen för poddarna. Kör kommandona kubectl top och kubectl get enligt följande:

$ kubectl top pods  # Check the health of the pods and the nodes.
NAME                            CPU(cores)   MEMORY(bytes)
my-deployment-fc94b7f98-m9z2l   1m           32Mi

$ kubectl top nodes
NAME                                CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
aks-agentpool-42617579-vmss000000   120m         6%     2277Mi          49%

$ kubectl get pods  # Check the state of the pod.
NAME                            READY   STATUS    RESTARTS   AGE
my-deployment-fc94b7f98-m9z2l   2/2     Running   1          108s

Utdata visar att den aktuella användningen av poddar och noder verkar vara acceptabel.

Även om podden är i Running tillståndet sker en omstart efter de första 108 sekunderna av podden som körs. Den här händelsen kan tyda på att vissa problem påverkar poddar eller containrar som körs i podden.

Om problemet kvarstår ändras statusen för podden efter en tid:

$ kubectl get pods
NAME                            READY   STATUS             RESTARTS   AGE
my-deployment-fc94b7f98-m9z2l   1/2     CrashLoopBackOff   42         3h53m

Det här exemplet visar att Ready tillståndet har ändrats och att det finns flera omstarter av podden. En av containrarna är i CrashLoopBackOff tillstånd.

Den här situationen beror på att containern misslyckas efter start och kubernetes sedan försöker starta om containern för att tvinga den att börja fungera. Men om problemet kvarstår fortsätter programmet att misslyckas efter att det har körts under en viss tid. Kubernetes ändrar slutligen statusen till CrashLoopBackOff.

Kontrollera loggarna för podden genom att köra följande kubectl-loggar :

$ kubectl logs my-deployment-fc94b7f98-m9z2l
error: a container name must be specified for pod my-deployment-fc94b7f98-m9z2l, choose one of: [webserver my-app]

$ # Since the pod has more than one container, the name of the container has to be specified.
$ kubectl logs my-deployment-fc94b7f98-m9z2l -c webserver
[...] [mpm_event:notice] [pid 1:tid 140342576676160] AH00489: Apache/2.4.52 (Unix) configured -- resuming normal operations
[...] [core:notice] [pid 1:tid 140342576676160] AH00094: Command line: 'httpd -D FOREGROUND'
10.244.0.1 - - ... "GET / HTTP/1.1" 200 45
10.244.0.1 - - ... "GET /favicon.ico HTTP/1.1" 404 196
10.244.0.1 - - ... "-" 408 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "HEAD / HTTP/1.1" 200 -
10.244.0.1 - - ... "POST /boaform/admin/formLogin HTTP/1.1" 404 196

$ # The webserver container is running fine. Check the logs for other container (my-app).
$ kubectl logs my-deployment-fc94b7f98-m9z2l -c my-app

$ # No logs observed. The container could be starting or be in a transition phase.
$ # So logs for the previous execution of this container can be checked using the --previous flag:
$ kubectl logs my-deployment-fc94b7f98-m9z2l -c my-app --previous
<Some Logs from the container>
..
..
Started increasing memory

Loggposter gjordes tidigare när containern kördes. Förekomsten av dessa poster tyder på att programmet startades, men stängdes på grund av vissa problem.

Nästa steg är att kontrollera händelserna i podden genom att köra kommandot kubectl describe :

$ kubectl describe pod my-deployment-fc94b7f98-m9z2l
Name:         my-deployment-fc94b7f98-m9z2l
Namespace:    default
...
...
Labels:       app=my-pod
...
...
Containers:
  webserver:
 ...
 ...
  my-app:
    Container ID:   containerd://a46e5062d53039d0d812c57c76b740f8d1ffb222de35203575bf8e4d10d6b51e
    Image:          my-repo/my-image:latest
    Image ID:       docker.io/my-repo/my-image@sha256:edcc4bedc7b...
    State:          Running
      Started:      <Start Date>
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
    Ready:          True
    Restart Count:  44
    Limits:
      memory:  500Mi
    Requests:
      cpu:        250m
      memory:     500Mi
...
...
Events:
  Type     Reason   Age                     From     Message
  ----     ------   ----                    ----     -------
  Normal   Pulling  49m (x37 over 4h4m)     kubelet  Pulling image "my-repo/my-image:latest"
  Warning  BackOff  4m10s (x902 over 4h2m)  kubelet  Back-off restarting failed container

Observationer:

Slutkoden är 137. Mer information om slutkoder finns i Docker-körningsreferensen och Slutkoder med särskilda betydelser.
Avslutningsorsaken är OOMKilled.
Den angivna minnesgränsen för containern är 500 mi.

Du kan se från händelserna att containern avlivas eftersom den överskrider minnesgränserna. När gränsen för containerminne har nåtts blir programmet tillfälligt otillgängligt och containern avlivas och startas om.

Lösning

Du kan ta bort minnesgränsen och övervaka programmet för att avgöra hur mycket minne det faktiskt behöver. När du har lärt dig minnesanvändningen kan du uppdatera minnesgränserna för containern. Om minnesanvändningen fortsätter att öka avgör du om det finns en minnesläcka i programmet.

Mer information om hur du planerar resurser för arbetsbelastningar i Azure Kubernetes Service finns i metodtips för resurshantering.

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.

Dela via