Onregelmatige time-outs of serverproblemen bij het openen van de toepassing op AKS

Artikel
04/12/2024

In dit artikel wordt beschreven hoe u onregelmatige verbindingsproblemen oplost die van invloed zijn op uw toepassingen die worden gehost op een AKS-cluster (Azure Kubernetes Service).

Vereisten

Het hulpprogramma Client-URL (cURL) of een vergelijkbaar opdrachtregelprogramma.
Het kubectl-hulpprogramma Kubernetes 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.

Symptomen

Wanneer u een cURL-opdracht uitvoert, ontvangt u af en toe het foutbericht 'Time-out'. De uitvoer kan lijken op de volgende tekst:

$ # 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

Oorzaak

Onregelmatige time-outs duiden op prestatieproblemen van onderdelen, in tegenstelling tot netwerkproblemen.

In dit scenario is het belangrijk om het gebruik en de status van de onderdelen te controleren. U kunt de inside-out-techniek gebruiken om de status van de pods te controleren. Voer de opdrachten kubectl top en kubectl get als volgt uit:

$ 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

De uitvoer laat zien dat het huidige gebruik van de pods en knooppunten acceptabel lijkt te zijn.

Hoewel de pod zich in de Running status bevindt, wordt er na de eerste 108 seconden van het uitvoeren van de pod een herstart uitgevoerd. Deze gebeurtenis kan erop wijzen dat sommige problemen van invloed zijn op de pods of containers die in de pod worden uitgevoerd.

Als het probleem zich blijft voordoen, verandert de status van de pod na enige tijd:

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

In dit voorbeeld ziet u dat de Ready status is gewijzigd en dat er verschillende herstarts van de pod zijn. Een van de containers heeft CrashLoopBackOff de status.

Deze situatie treedt op omdat de container mislukt na het starten en kubernetes probeert de container opnieuw te starten om af te dwingen dat deze gaat werken. Als het probleem zich echter blijft voordoen, blijft de toepassing mislukken nadat deze enige tijd is uitgevoerd. Kubernetes wijzigt uiteindelijk de status in CrashLoopBackOff.

Voer de volgende kubectl-logboekopdrachten uit om de logboeken voor de pod te controleren:

$ 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

Logboekvermeldingen zijn gemaakt de vorige keer dat de container werd uitgevoerd. Het bestaan van deze vermeldingen suggereert dat de toepassing is gestart, maar is gesloten vanwege een aantal problemen.

De volgende stap is het controleren van de gebeurtenissen van de pod door de opdracht kubectl-beschrijving uit te voeren:

$ 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

Opmerkingen:

De afsluitcode is 137. Zie de Docker-uitvoeringsreferentie en Afsluitcodes met speciale betekenissen voor meer informatie over afsluitcodes.
De reden voor beëindiging is OOMKilled.
De geheugenlimiet die is opgegeven voor de container is 500 Mi.

U kunt aan de gebeurtenissen zien dat de container wordt afgebroken omdat deze de geheugenlimieten overschrijdt. Wanneer de limiet voor het geheugen van de container is bereikt, wordt de toepassing af en toe niet meer toegankelijk en wordt de container uitgeschakeld en opnieuw opgestart.

Oplossing

U kunt de geheugenlimiet verwijderen en de toepassing controleren om te bepalen hoeveel geheugen deze daadwerkelijk nodig heeft. Nadat u het geheugengebruik hebt geleerd, kunt u de geheugenlimieten voor de container bijwerken. Als het geheugengebruik blijft toenemen, bepaalt u of er een geheugenlek in de toepassing is.

Zie best practices voor resourcebeheer voor meer informatie over het plannen van resources voor workloads in Azure Kubernetes Service.

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.

Share via