Amazon ECS タスクが保留状態のままになっているのはなぜですか?
Amazon Elastic Container Service (Amazon ECS) のタスクが保留状態のままになっています。
簡単な説明
以下のシナリオでは、Amazon ECS タスクが保留状態で停止することがよくあります。
- Docker デーモンが応答しない。
- Docker イメージが大きい。
- Amazon ECS コンテナエージェントが、タスクの起動中に Amazon ECS サービスとの接続を失った。
- Amazon ECS コンテナエージェントで、既存のタスクを停止するのに長い時間がかかる。
- Amazon Virtual Private Cloud (Amazon VPC) ルーティングが正しく設定されていない。
- 必須のコンテナが、必須ではない異常なコンテナに依存している。
解決方法
タスクが「PENDING」状態のままになっている理由を確認するには、以下のトラブルシューティング手順を実行してください。
注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、最新バージョンの AWS CLI を使用していることを確認してください。
Docker デーモンが応答しない
CPU の問題については、次の手順を実行してください。
1. Amazon CloudWatch メトリックスを使用して、コンテナインスタンスが最大 CPU を超えているかどうかを確認します。
2. 必要に応じてコンテナインスタンスのサイズを増やします。
メモリの問題については、次の手順を実行してください。
1. free コマンドを実行して、システムで使用可能なメモリ量を確認します。
2. 必要に応じてコンテナインスタンスのサイズを増やします。
I/O の問題については、次の手順を実行してください。
1. iotop コマンドを実行します。
2. どのサービスのどのタスクが最も IOPS を使用しているかを調べます。次に、タスク配置の制約と戦略を使用して、これらのタスクを個別のコンテナインスタンスに分散します。
-または-
CloudWatch を使用して Amazon Elastic Block Store (Amazon EBS) の BurstBalance メトリックス用のアラームを作成します。次に、AWS Lambda 関数または独自のカスタムロジックを使用してタスクのバランスを調整します。
Docker イメージが大きい
イメージが大きくなると、ダウンロードに時間がかかり、タスクが「PENDING」状態になる時間が長くなります。
移行時間を短縮するには、イメージキャッシュを利用するように ECS_IMAGE_PULL_BEHAVIOR パラメータを調整します。
注: たとえば、/etc/ecs/ecs.config で ECS_IMAGE_PULL_BEHAVIOR パラメータを prefer-cached に設定するなどします。prefer-cached を指定すると、キャッシュされたイメージがない場合にイメージがリモートでプルされます。それ以外の場合は、インスタンスにキャッシュされたイメージが使用されます。
Amazon ECS コンテナエージェントが、起動中に Amazon ECS サービスとの接続を失った
- Amazon ECS コンテナエージェントのステータスと接続を確認するには、コンテナインスタンスで以下のいずれかのコマンドを実行します。
Amazon Linux 1 で次のコマンドを実行します。
$ sudo status ecs $ sudo docker ps -f name=ecs-agent
Amazon Linux 2 で次のコマンドを実行します。
$ sudo systemctl status ecs $ sudo docker ps -f name=ecs-agent
注: 出力には「active/running」と表示されます。
- ECS コンテナインスタンスで実行中のタスクのメタデータを表示するには、コンテナインスタンスで次のコマンドを実行します。
$ curl http://localhost:51678/v1/metadata
次の出力が表示されます。
{ "Cluster": "CLUSTER_ID", "ContainerInstanceArn": "arn:aws:ecs:REGION:ACCOUNT_ID:container-instance/TASK_ID", "Version": "Amazon ECS Agent - AGENT " }
- 実行中のタスクに関する情報を表示するには、コンテナインスタンスで次のコマンドを実行します。
$ curl http://localhost:51678/v1/tasks
次の出力が表示されます。
{ "Tasks": [ { "Arn": "arn:aws:ecs:REGION:ACCOUNT_ID:task/TASK_ID", "DesiredStatus": "RUNNING", "KnownStatus": "RUNNING", ... ... } ] }
- 接続されていないエージェントに問題がある場合は、以下のいずれかのコマンドを使用してコンテナエージェントを再起動します。
Amazon Linux 1 で次のコマンドを実行します。
$ sudo stop ecs $ sudo start ecs
Amazon Linux 2 で次のコマンドを実行します。
$ sudo systemctl stop ecs $ sudo systemctl start ecs
次のメッセージのような出力が表示されます。
ecs start/running, process xxxx
- エージェントの接続性を判断するには、次のログの該当する時間枠をチェックして、error、warn、agent transition state などのキーワードがないか確認します。
Amazon ECS コンテナエージェントログは /var/log/ecs/ecs-agent.log.yyyy-mm-dd-hh で確認できます。
Amazon ECS の初期化ログは /var/log/ecs/ecs-init.log で確認できます。
Docker ログは /var/log/docker で確認できます。
注: Amazon ECS ログコレクターを使用して、Amazon ECS の一般的なオペレーティングシステムログ、Docker ログ、およびコンテナエージェントログを収集することもできます。
Amazon ECS コンテナエージェントで、既存のタスクを停止するのに長い時間がかかる
コンテナエージェントが Amazon ECS から開始する新しいタスク (PENDING から RUNNING) を受け取ると、古いタスクを停止しなければならない場合があります。この場合、エージェントは古いタスクが最初に停止されるまでこれらの新しいタスクを開始しません。
コンテナの停止と起動のタイムアウトをコンテナインスタンスレベルで制御するには、次の 2 つのパラメータを設定します。
- /etc/ecs/ecs.config で ECS_CONTAINER_STOP_TIMEOUT パラメータの値を調整します。このパラメータは、コンテナが自動的に正常に終了しなかった場合に Amazon ECS がコンテナを強制的に終了するまでの経過時間を設定します。
注: Linux と Windows のデフォルト値は 30s です。
- /etc/ecs/ecs.config で ECS_CONTAINER_START_TIMEOUT パラメータの値を調整します。このパラメータは、Amazon ECS コンテナエージェントがコンテナの起動を停止するまでの経過時間を設定します。
注: デフォルト値は Linux では 3m、Windows では 8m です。
エージェントのバージョンが 1.26.0 以降の場合は、タスクごとに前述の停止および開始タイムアウトパラメータを定義できます。これにより、タスクが「STOPPED」状態に移行する可能性があります。たとえば、コンテナ A の起動が、コンテナ B が「COMPLETE」、「SUCCESS」、「HEALTHY」のいずれかのステータスに達成することに依存しているとします。コンテナ B に StartTimeout 値を指定せず、その時間内にコンテナ B が目的のステータスに達しない場合、コンテナ A は起動しません。
コンテナの依存関係の例については、AWS GitHub の「例: コンテナの依存関係」を参照してください。
Amazon Virtual Private Cloud (Amazon VPC) ルーティングが正しく設定されていない
Amazon ECS または Fargate タスクが実行される VPC サブネットの設定を確認してください。サブネットが正しく設定されていないと、Amazon ECS や Amazon ECR にアクセスできません。この問題を解決するには、サブネットのルートテーブルにインターネットゲートウェイまたは NAT ゲートウェイがあることを確認してください。インターネットへの出口ルートがないサブネットでタスクを起動する場合は、AWS PrivateLink を使用してください。これにより、プライベート IP アドレスで Amazon ECS API にプライベートにアクセスできます。
必須のコンテナが、必須ではない異常なコンテナに依存している
必須ではないコンテナが正常状態にならず、必須のコンテナがそれらに依存している場合、タスクは保留状態になります。この場合、次のメッセージが表示されます。
"stoppedReason":"Service ABCXYZ: task last status remained in PENDING too long."
この問題を解決するには、依存する (必須ではない) コンテナが期待どおりに動作することを確認してください。根本的な問題を解決できない場合は、これらのコンテナを必須にして、タスクが長期間「PENDING」状態にならないようにしてください。
関連情報
関連するコンテンツ
- 質問済み 3ヶ月前lg...
- 質問済み 1年前lg...
- AWS公式更新しました 2年前
- AWS公式更新しました 2年前