App Mesh 設定のトラブルシューティング

このトピックでは、App Mesh 設定で発生する可能性のある一般的な問題の詳細を説明します。

Envoy コンテナイメージをプルできない

症状

Amazon ECS タスクで、次のエラーメッセージが表示されます。次のメッセージの Amazon ECR アカウント ID とリージョンは、コンテナイメージを取得した Amazon ECR リポジトリによって異なる場合があります。

CannotPullContainerError: Error response from daemon: pull access denied for 840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy, repository does not exist or may require 'docker login'

解決方法

このエラーは、使用されているタスク実行ロールに Amazon ECR と通信するアクセス許可がなく、リポジトリから Envoy コンテナイメージをプルできないことを示しています。Amazon ECS タスクに割り当てられたタスク実行ロールには、次のステートメントを含む IAM ポリシーが必要です。

{
  "Action": [
    "ecr:BatchCheckLayerAvailability",
    "ecr:GetDownloadUrlForLayer",
    "ecr:BatchGetImage"
  ],
  "Resource": "arn:aws:ecr:us-west-2:111122223333:repository/aws-appmesh-envoy",
  "Effect": "Allow"
},
{
  "Action": "ecr:GetAuthorizationToken",
  "Resource": "*",
  "Effect": "Allow"
}

それでも問題が解決しない場合は、GitHub 問題を開くことを検討してください。または、 AWS サポートにお問い合わせください。

App Mesh Envoy 管理サービスに接続できない

症状

Envoy プロキシが App Mesh Envoy 管理サービスに接続できません。次が表示されます：

• 接続がエラーを拒否しました

• 接続タイムアウトしました

• App Mesh Envoy 管理サービスエンドポイントの解決中にエラーが発生しました

• gRPC エラー

解決方法

Envoy プロキシがインターネットまたはプライベートVPC エンドポイントにアクセスできること、およびセキュリティグループがポート 443 でのアウトバウンドトラフィックを許可していることを確認してください。App Mesh の公開 Envoy 管理サービスのエンドポイントは、完全修飾ドメイン名 (FQDN、Fully Qualified Domain Name) フォーマットに従います。

# App Mesh Production Endpoint
appmesh-envoy-management.Region-code.amazonaws.com

# App Mesh Preview Endpoint
appmesh-preview-envoy-management.Region-code.amazonaws.com

次のコマンドを使用して、EMS への接続をデバッグできます。これにより、有効だが空の gRPC 要求が Envoy 管理サービスに送信されます。

curl -v -k -H 'Content-Type: application/grpc' -X POST https://appmesh-envoy-management.Region-code.amazonaws.com:443/envoy.service.discovery.v3.AggregatedDiscoveryService/StreamAggregatedResources

これらのメッセージを受け取った場合、Envoy Management Service への接続は機能しています。gRPC 関連のエラーのデバッグについては、「Envoy が エラーテキストで App Mesh Envoy 管理サービスから切断されました」を参照してください。

grpc-status: 16
grpc-message: Missing Authentication Token

それでも問題が解決しない場合は、GitHub 問題を開くことを検討してください。または、 AWS サポートにお問い合わせください。

Envoy がエラーテキストで App Mesh Envoy 管理サービスから切断されました

症状

Envoy プロキシは、App Mesh Envoy 管理サービスへの接続して設定を受信することができません。Envoy プロキシログには、次のようなログエントリが含まれています。

gRPC config stream closed: gRPC status code, message

解決方法

ほとんどの場合、ログのメッセージ部分は問題を示しているはずです。次の表に、表示される可能性のある最も一般的な gRPC ステータスコード、その原因、および解決策を示します。

gRPC ステータスコード	原因	解決方法
0	Envoy 管理サービスから正常に切断します。	問題はありません。App Mesh は、このステータスコードで Envoy プロキシを切断することがあります。Envoy は再接続し、更新を受信し続けます。
3	メッシュエンドポイント (仮想ノードまたは仮想ゲートウェイ) 、または関連するリソースの 1 つが見つかりませんでした。	Envoy 設定を再チェックして、それが表す App Mesh リソースの適切な名前があることをチェックします。App Mesh リソースが、AWS Cloud Map 名前空間やACM証明書などの他の AWS リソースと統合されている場合、それらのリソースが存在することを確認します。
7	Envoy プロキシは、Envoy 管理サービスへの接続や関連リソースの取得などのアクションの実行を許可されていません。	App Mesh やその他のサービスに適切なポリシーステートメントを持つIAMポリシーを作成し、Envoy プロキシが Envoy 管理サービスに接続するために使用している IAM ユーザーまたはロールに、そのポリシーをアタッチしていることを確認してください。
8	特定の App Mesh リソースの Envoy プロキシの数がアカウントレベルのサービスクォータを超えています。	デフォルトのアカウントクォータの詳細および引き上げをリクエストする方法については、「App Mesh Service Quotas」を参照してください。
16	Envoy プロキシには、AWS の有効な認証資格情報がありません。	Envoy に接続する適切な資格情報があることを確認しますAWSIAM ユーザーまたはロールを介したサービス。Envoy のバージョン v1.24 以前の既知の問題 #24136 では、Envoy プロセスが 1024 個を超えるファイル記述子を使用すると認証情報の取得に失敗します。これは Envoy が大量のトラフィックを処理している場合に発生します。デバッグレベルで Envoy ログのテキスト「A libcurl function was given a bad argument」を確認することで、この問題を確認できます。この問題を軽減するには、Envoy バージョン v1.25.1.0-prod 以降にアップグレードしてください。

次のクエリを使用して、Amazon CloudWatch Insights で Envoy プロキシのステータスコードとメッセージを確認できます。

filter @message like /gRPC config stream closed/
| parse @message "gRPC config stream closed: *, *" as StatusCode, Message

表示されたエラーメッセージが役に立たなかったり、問題が解決しない場合は、GitHub 問題を開くことを検討してください。

Envoy コンテナのヘルスチェック、準備状態プローブ、またはライブネスプローブの失敗

症状

Envoy プロキシが Amazon ECS タスク、Amazon EC2 インスタンス、Kubernetes ポッドでヘルスチェックに失敗しています。例えば、次のコマンドを使用して Envoy 管理インターフェースをクエリし、LIVE 以外のステータスを受け取ります。

curl -s http://my-app.default.svc.cluster.local:9901/server_info | jq '.state'

解決方法

Envoy プロキシによって返されるステータスに応じた修復手順の一覧を次に示します。

• PRE_INITIALIZING または INITIALIZING — Envoy プロキシがまだ設定を受信していないか、まだ接続できないため App Mesh Envoy 管理サービスから設定を取得できない。Envoy 管理サービスから接続しようとしたときに、 Envoy がエラーを受信している可能性があります。詳細については、「Envoy がエラーテキストで App Mesh Envoy 管理サービスから切断されました」を参照してください。

• DRAINING — Envoy プロキシは、Envoy 管理インターフェースの /healthcheck/fail または /drain_listeners リクエストに応答して接続のドレインを開始しました。Amazon ECS タスク、Amazon EC2 インスタンス、または Kubernetes ポッドを終了する場合を除き、管理インターフェイスでこれらのパスを呼び出すことはお勧めしません。

それでも問題が解決しない場合は、GitHub 問題を開くことを検討してください。または、 AWS サポートにお問い合わせください。

ロードバランサーからメッシュエンドポイントへのヘルスチェックが失敗している

症状

メッシュエンドポイントは、コンテナヘルスチェックまたは準備プローブによって正常と見なされますが、ロードバランサーからメッシュエンドポイントへのヘルスチェックが失敗しています。

解決方法

この問題を解決するには、次のタスクを完了します。

• メッシュエンドポイントに関連するセキュリティグループが、ヘルスチェック用に設定したポートのインバウンドトラフィックを受け入れていることを確認してください。

• 手動で要求された場合、ヘルスチェックが一貫して成功していることを確認します。例えば、VPC 内の踏み台ホストです。

• 仮想ノードのヘルスチェックを設定する場合は、アプリケーションにヘルスチェックエンドポイントを実装することをお勧めします。例えば、HTTP の場合は /ping などです。これにより、Envoy プロキシとアプリケーションの両方がロードバランサーからルーティング可能になります。

• 必要な機能に応じて、仮想ノードには任意の Elastic Load Balancer タイプを使用できます。詳細については、「Elastic Load Balancing の機能」を参照してください。

• 仮想ゲートウェイのヘルスチェックを設定する場合は、仮想ゲートウェイのリスナーポートに TCP または TLS ヘルスチェックを備えたネットワークロードバランサーを使用することをお勧めします。これにより、仮想ゲートウェイリスナーがブートストラップされ、接続を受け入れる準備ができていることが保証されます。

それでも問題が解決しない場合は、GitHub 問題を開くことを検討してください。または、 AWS サポートにお問い合わせください。

仮想ゲートウェイがポート 1024 以下のトラフィックを受け入れない

症状

仮想ゲートウェイは、ポート 1024 以下のトラフィックを受け入れませんが、1024 より大きいポート番号のトラフィックを受け入れます。例えば、次のコマンドを使用して Envoy 統計をクエリし、ゼロ以外の値を受け取ります。

curl -s http://my-app.default.svc.cluster.local:9901/stats | grep "update_rejected"

特権ポートへのバインド障害を示す、次のテキストのようなテキストがログに、表示される場合があります。

gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected: Error adding/updating listener(s) lds_ingress_0.0.0.0_port_<port num>: cannot bind '0.0.0.0:<port num>': Permission denied

解決方法

この問題を解決するには、ゲートウェイに指定したユーザーに linux 機能 CAP_NET_BIND_SERVICE が必要です。詳細については、「Linux プログラマーズマニュアル」の「機能」、「ECS タスク定義パラメータ」の「Linux パラメータ」、および Kubernetes ドキュメントの「コンテナの機能の設定」を参照してください。

重要

Fargate は 1024 より大きいポート値を使用する必要があります。

それでも問題が解決しない場合は、GitHub 問題を開くことを検討してください。または、 AWS サポートにお問い合わせください。