Zeitweilige Timeouts oder Serverprobleme beim Zugriff auf die Anwendung auf AKS

Artikel
03/28/2022
4 Minuten Lesedauer

In diesem Artikel wird beschrieben, wie Sie zeitweilige Konnektivitätsprobleme behandeln, die sich auf Ihre Anwendungen auswirken, die auf einem Azure Kubernetes Service (AKS)-Cluster gehostet werden.

Voraussetzungen

Das Client-URL-Tool (cURL) oder ein ähnliches Befehlszeilentool.
Das Kubernetes kubectl-Tool oder ein ähnliches Tool zum Herstellen einer Verbindung mit dem Cluster. Um kubectl mithilfe von Azure CLI zu installieren, führen Sie den Befehl "az aks install-cli " aus.

Problembeschreibung

Wenn Sie einen cURL-Befehl ausführen, wird gelegentlich die Fehlermeldung "Timed out" angezeigt. Die Ausgabe kann dem folgenden Text ähneln:

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

Ursache

Zeitweilige Timeouts schlagen Leistungsprobleme der Komponente vor, im Gegensatz zu Netzwerkproblemen.

In diesem Szenario ist es wichtig, die Verwendung und Integrität der Komponenten zu überprüfen. Sie können die Inside-Out-Technik verwenden, um den Status der Pods zu überprüfen. Führen Sie die Befehle "kubectl top " und "kubectl get " wie folgt aus:

$ 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

Die Ausgabe zeigt, dass die aktuelle Verwendung der Pods und Knoten scheinbar akzeptabel ist.

Obwohl sich der Pod im Running Zustand befindet, erfolgt ein Neustart nach den ersten 108 Sekunden der Ausführung des Pods. Dieses Vorkommen kann darauf hinweisen, dass sich einige Probleme auf die Pods oder Container auswirken, die im Pod ausgeführt werden.

Wenn das Problem weiterhin besteht, ändert sich der Status des Pods nach einiger Zeit:

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

Dieses Beispiel zeigt, dass der Ready Zustand geändert wird und es mehrere Neustarts des Pods gibt. Einer der Container befindet sich im CrashLoopBackOff Status.

Diese Situation tritt auf, weil der Container nach dem Start fehlschlägt und Kubernetes versucht, den Container neu zu starten, um zu erzwingen, dass er funktioniert. Wenn das Problem jedoch weiterhin besteht, schlägt die Anwendung nach der Ausführung für einige Zeit fehl. Kubernetes ändert schließlich den Status in CrashLoopBackOff.

Führen Sie die folgenden Kubectl-Protokollebefehle aus, um die Protokolle für den Pod zu überprüfen:

$ 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

Protokolleinträge wurden beim vorherigen Ausführen des Containers vorgenommen. Das Vorhandensein dieser Einträge deutet darauf hin, dass die Anwendung zwar gestartet wurde, aber aufgrund einiger Probleme geschlossen wurde.

Der nächste Schritt besteht darin, die Ereignisse des Pods zu überprüfen, indem Sie den Befehl "kubectl describe " ausführen:

$ 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

Beobachtungen:

Der Exitcode ist 137. Weitere Informationen zu Beendigungscodes finden Sie in der Docker-Ausführungsreferenz und den Exit-Codes mit spezieller Bedeutung.
Der Grund für die Beendigung ist OOMKilled.
Der für den Container angegebene Speichergrenzwert beträgt 500 Mi.

Sie können anhand der Ereignisse erkennen, dass der Container nicht mehr verwendet wird, da er die Speichergrenzen überschreitet. Wenn der Containerspeichergrenzwert erreicht ist, kann die Anwendung zeitweise nicht mehr auf sie zugreifen, und der Container wird beendet und neu gestartet.

Lösung

Sie können den Speichergrenzwert entfernen und die Anwendung überwachen, um zu ermitteln, wie viel Arbeitsspeicher sie tatsächlich benötigt. Nachdem Sie die Speicherauslastung kennen gelernt haben, können Sie die Speicherbeschränkungen für den Container aktualisieren. Wenn die Speicherauslastung weiter zunimmt, bestimmen Sie, ob in der Anwendung ein Speicherverlust auftritt.

Weitere Informationen zum Planen von Ressourcen für Workloads in Azure Kubernetes Service finden Sie unter "Bewährte Methoden für die Ressourcenverwaltung".