AKS でアプリケーションにアクセスするときの断続的なタイムアウトまたはサーバーの問題

[アーティクル]
04/12/2024

この記事では、Azure Kubernetes Service (AKS) クラスターでホストされているアプリケーションに影響する断続的な接続の問題をトラブルシューティングする方法について説明します。

前提条件

クライアント URL (cURL) ツール、または同様のコマンドラインツール。
Kubernetes kubectl ツール、またはクラスターに接続するための同様のツール。 Azure CLI を使用して kubectl をインストールするには、az aks install-cli コマンドを実行します。

現象

cURL コマンドを実行すると、"タイムアウト" というエラーメッセージが表示される場合があります。出力は次のテキストのようになります。

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

原因

断続的なタイムアウトは、ネットワークの問題ではなく、コンポーネントのパフォーマンスの問題を示唆します。

このシナリオでは、コンポーネントの使用状況と正常性をチェックすることが重要です。 インサイドアウト手法を使用して、ポッドの状態をチェックできます。次のように、 kubectl top コマンドと kubectl get コマンドを実行します。

$ 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

出力は、ポッドとノードの現在の使用状況が許容可能であると見なされることを示しています。

ポッドは状態ですが Running 、ポッドが実行されている最初の 108 秒後に 1 回再起動されます。この状況は、ポッドで実行されるポッドまたはコンテナーに影響を与える問題があることを示している可能性があります。

問題が解決しない場合は、しばらくするとポッドの状態が変わります。

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

この例では、状態が Ready 変更され、ポッドが数回再起動されることを示しています。コンテナーの 1 つが状態です CrashLoopBackOff 。

この状況は、開始後にコンテナーが失敗し、Kubernetes がコンテナーを強制的に再起動して動作を開始しようとしたために発生します。ただし、問題が解決しない場合、アプリケーションはしばらくの間実行された後も失敗し続けます。 Kubernetes は最終的に状態をに CrashLoopBackOff変更します。

ポッドのログをチェックするには、次の kubectl logs コマンドを実行します。

$ 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

ログエントリは、コンテナーが実行された前の時刻に作成されました。これらのエントリの存在は、アプリケーションが起動したが、いくつかの問題のために閉じられたことを示唆しています。

次の手順では、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

観測：

終了コードは 137 です。終了コードの詳細については、「 Docker 実行リファレンス」と「特別な意味を持つ終了コード」を参照してください。
終了の理由はです OOMKilled。
コンテナーに指定されるメモリ制限は 500 Mi です。

コンテナーがメモリ制限を超えているので、コンテナーが強制終了されていることをイベントから確認できます。コンテナーのメモリ制限に達すると、アプリケーションに断続的にアクセスできなくなり、コンテナーが強制終了されて再起動されます。

ソリューション

メモリ制限を削除し、アプリケーションを監視して、実際に必要なメモリ量を判断できます。メモリ使用量を学習したら、コンテナーのメモリ制限を更新できます。メモリ使用量が増加し続ける場合は、アプリケーションにメモリリークがあるかどうかを判断します。

Azure Kubernetes Serviceのワークロードのリソースを計画する方法の詳細については、「リソース管理のベストプラクティス」を参照してください。

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティサポートにお問い合わせください。 Azure フィードバックコミュニティに製品フィードバックを送信することもできます。

次の方法で共有

AKS でアプリケーションにアクセスするときの断続的なタイムアウトまたはサーバーの問題

前提条件

現象

原因

ソリューション

お問い合わせはこちらから

フィードバック

その他のリソース