Timeout intermittenti o problemi del server durante l'accesso all'applicazione nel servizio Azure Kubernetes

Articolo
04/12/2024

Questo articolo descrive come risolvere i problemi di connettività intermittente che influiscono sulle applicazioni ospitate in un cluster servizio Azure Kubernetes (servizio Azure Kubernetes).

Prerequisiti

Lo strumento URL client (cURL) o uno strumento da riga di comando simile.
Lo strumento Kubernetes kubectl o uno strumento simile per connettersi al cluster. Per installare kubectl usando l'interfaccia della riga di comando di Azure, eseguire il comando az aks install-cli .

Sintomi

Quando si esegue un comando cURL, viene occasionalmente visualizzato un messaggio di errore "Timed out". L'output potrebbe essere simile al testo seguente:

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

Causa

I timeout intermittenti suggeriscono problemi di prestazioni dei componenti, anziché problemi di rete.

In questo scenario è importante controllare l'utilizzo e l'integrità dei componenti. È possibile usare la tecnica inside-out per controllare lo stato dei pod. Eseguire i comandi kubectl top e kubectl get , come indicato di seguito:

$ 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

L'output mostra che l'utilizzo corrente dei pod e dei nodi sembra essere accettabile.

Anche se il pod è nello stato , si verifica un riavvio dopo i primi 108 secondi del pod in Running esecuzione. Questa occorrenza potrebbe indicare che alcuni problemi interessano i pod o i contenitori eseguiti nel pod.

Se il problema persiste, lo stato del pod cambia dopo un certo periodo di tempo:

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

Questo esempio mostra che lo Ready stato è stato modificato e che sono presenti diversi riavvii del pod. Uno dei contenitori è nello CrashLoopBackOff stato .

Questa situazione si verifica perché il contenitore ha esito negativo dopo l'avvio e quindi Kubernetes tenta di riavviare il contenitore per forzarlo a iniziare a funzionare. Tuttavia, se il problema persiste, l'applicazione continua a non riuscire dopo l'esecuzione per un certo periodo di tempo. Kubernetes alla fine modifica lo stato in CrashLoopBackOff.

Per controllare i log per il pod, eseguire i comandi kubectl logs seguenti:

$ 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

Le voci di log sono state effettuate l'ora precedente in cui è stato eseguito il contenitore. L'esistenza di queste voci suggerisce che l'applicazione è stata avviata, ma è stata chiusa a causa di alcuni problemi.

Il passaggio successivo consiste nel controllare gli eventi del pod eseguendo il comando 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

Osservazioni:

Il codice di uscita è 137. Per altre informazioni sui codici di uscita, vedere i riferimenti per l'esecuzione docker e i codici di uscita con significati speciali.
Il motivo della terminazione è OOMKilled.
Il limite di memoria specificato per il contenitore è 500 Mi.

Dagli eventi è possibile stabilire che il contenitore viene ucciso perché supera i limiti di memoria. Quando viene raggiunto il limite di memoria del contenitore, l'applicazione diventa intermittentemente inaccessibile e il contenitore viene eliminato e riavviato.

Soluzione

È possibile rimuovere il limite di memoria e monitorare l'applicazione per determinare la quantità di memoria effettivamente necessaria. Dopo aver appreso l'utilizzo della memoria, è possibile aggiornare i limiti di memoria per il contenitore. Se l'utilizzo della memoria continua ad aumentare, determinare se si verifica una perdita di memoria nell'applicazione.

Per altre informazioni su come pianificare le risorse per i carichi di lavoro in servizio Azure Kubernetes, vedere Procedure consigliate per la gestione delle risorse.

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.

Condividi tramite