AKS でアプリケーションにアクセスするときの断続的なタイムアウトまたはサーバーの問題
この記事では、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
原因
断続的なタイムアウトは、ネットワークの問題とは対照的に、コンポーネントのパフォーマンスの問題を示唆します。
このシナリオでは、コンポーネントの使用状況と正常性を確認することが重要です。 inside-out手法を使用して、ポッドの状態を確認できます。 次のように、 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
ログ エントリは、コンテナーが実行された前の時刻に作成されました。 これらのエントリの存在は、アプリケーションが起動したが、いくつかの問題のために閉じられたことを示唆しています。
デプロイに関連付けられているサービスを確認し、クラスター内からサービスのクラスター IP をカールして問題を特定します。
$ 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
次の手順では、 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 の実行リファレンス および特別な意味を持つ Exit コードを参照してください。
終了の理由は
OOMKilled。コンテナーに指定されたメモリ制限は 500 Mi です。
コンテナーがメモリ制限を超えているため、コンテナーが強制終了されていることをイベントから確認できます。 コンテナーのメモリ制限に達すると、アプリケーションは断続的にアクセスできなくなり、コンテナーは強制終了されて再起動されます。
Note
ポッド定義 ライブネス、準備、およびスタートアップ プローブ 構成することをお勧めします。 この構成は、アプリケーションの動作に応じて、予期しない問題からアプリケーションを回復するのに役立ちます。 ライブネス プローブを構成するときは注意してください。
ソリューション
メモリ制限を削除し、アプリケーションを監視して、実際に必要なメモリの量を判断できます。 メモリ使用量を学習したら、コンテナーのメモリ制限を更新できます。 メモリ使用量が増加し続ける場合は、アプリケーションにメモリ リークがあるかどうかを判断します。
Azure Kubernetes Service でワークロードのリソースを計画する方法の詳細については、「 リソース管理のベスト プラクティスを参照してください。
お問い合わせはこちらから
質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。