Zeitweilige Timeouts oder Serverprobleme beim Zugriff auf die Anwendung auf AKS

Artikel
10/15/2024

In diesem Artikel wird beschrieben, wie Sie zeitweilige Verbindungsprobleme 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. Führen Sie zum Installieren von Kubectl mithilfe der Azure CLI den Befehl "az aks install-cli " aus.

Symptome

Wenn Sie einen cURL-Befehl ausführen, wird gelegentlich eine Fehlermeldung "Timed out" angezeigt. Die Ausgabe könnte 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

Intermittierende Timeouts schlagen Probleme mit der Komponentenleistung im Gegensatz zu Netzwerkproblemen vor.

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 akzeptabel erscheint.

Obwohl sich der Pod im Running Zustand befindet, tritt ein Neustart nach den ersten 108 Sekunden des ausgeführten Pods auf. 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 gibt mehrere Neustarts des Pods. Einer der Container befindet sich im CrashLoopBackOff Zustand.

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

Führen Sie die folgenden Kubectl-Protokolle 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 gestartet wurde, aber aufgrund einiger Probleme geschlossen wurde.

Überprüfen Sie den Dienst, der der Bereitstellung zugeordnet ist, und versuchen Sie, die Cluster-IP des Diensts innerhalb des Clusters zu gliedern, um das Problem zu identifizieren:

$ 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

Der nächste Schritt besteht darin, die Ereignisse des Pods durch Ausführen des Kubectl-Beschreibungsbefehls zu überprüfen:

$ 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 Beendigungscode ist 137. Weitere Informationen zu Exitcodes finden Sie in den Docker-Run-Referenz - und Exit-Codes mit besonderer Bedeutung.
Der Kündigungsgrund lautet OOMKilled.
Der für den Container angegebene Speichergrenzwert beträgt 500 Mi.

Sie können aus den Ereignissen erkennen, dass der Container getötet wird, da er die Speichergrenzwerte überschreitet. Wenn der Grenzwert für den Containerspeicher erreicht ist, kann die Anwendung zeitweise nicht mehr zugegriffen werden, und der Container wird abgebrochen und neu gestartet.

Notiz

Es wird empfohlen , Liveness-, Bereitschafts- und Startsonden in Ihrer Poddefinition zu konfigurieren. Je nach Verhalten Ihrer Anwendung kann diese Konfiguration dazu beitragen, die Anwendung aus unerwarteten Problemen wiederherzustellen. Seien Sie vorsichtig, wenn Sie Livenesssonden konfigurieren.

Lösung

Sie können den Speichergrenzwert entfernen und die Anwendung überwachen, um zu bestimmen, wie viel Arbeitsspeicher sie tatsächlich benötigt. Nachdem Sie die Speicherauslastung kennengelernt haben, können Sie die Speicherbeschränkungen für den Container aktualisieren. Wenn die Arbeitsspeicherauslastung weiterhin zunimmt, ermitteln 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.

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.

Freigeben über