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

Articolo
10/15/2024

Questo articolo descrive come risolvere i problemi di connettività intermittenti che interessano le applicazioni ospitate in un cluster del 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, si riceve occasionalmente un messaggio di errore "Timeout". 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 interna 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 Running stato, si verifica un riavvio dopo i primi 108 secondi dell'esecuzione del pod. Questa occorrenza può indicare che alcuni problemi interessano i pod o i contenitori eseguiti nel pod.

Se il problema persiste, lo stato del pod cambia dopo qualche 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 viene 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 modifica infine 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.

Controllare il servizio associato alla distribuzione e provare a curl l'INDIRIZZO IP del cluster del servizio dall'interno del cluster per identificare il problema:

$ kubectl get svc # Check the service associated with deployment 
NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP    PORT(S)        AGE
kubernetes              ClusterIP      10.0.0.1      <none>         443/TCP        3h21m
my-deployment-service   LoadBalancer   10.0.136.71   20.62.x.x      80:30790/TCP   21m

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 le informazioni di riferimento sull'esecuzione di Docker e Codici di uscita con significati speciali.
Il motivo della terminazione è OOMKilled.
Il limite di memoria specificato per il contenitore è 500 Mi.

È possibile indicare dagli eventi che il contenitore viene terminato perché supera i limiti di memoria. Quando viene raggiunto il limite di memoria del contenitore, l'applicazione diventa inaccessibile in modo intermittente e il contenitore viene terminato e riavviato.

Note

È consigliabile configurare liveness, idoneità e probe di avvio nella definizione del pod. A seconda del comportamento dell'applicazione, questa configurazione può aiutare a ripristinare l'applicazione da problemi imprevisti. Prestare attenzione quando si configurano probe di attività.

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 nel 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