Amazon ECS タスクが PENDING 状態に留まっている原因を教えてください。

簡単な説明

Amazon ECS タスクは、次のシナリオで PENDING 状態に留まります。

• Docker デーモンが応答しない。
• クラスターにリソースの制約がある。
• Docker イメージが大きい。
• Amazon ECS コンテナエージェントが、タスク起動の途中に Amazon ECS サービスとの接続を失った。
• Amazon ECS コンテナエージェントが既存のタスクを停止するのに、長い時間がかかっている。
• Amazon Virtual Private Cloud (Amazon VPC) のルーティングが正しく設定されていない。
• 必須コンテナが、必須以外のコンテナのうち、状態が HEALTHY ではないものに依存している。
• Amazon ECS タスクに関連付けた AWS Identity and Access Management (IAM) ロールが欠けているか、誤っている。
• 選択した Windows バージョンにイメージ互換性の問題がある。

解決策

注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、「AWS CLI で発生したエラーのトラブルシューティング」を参照してください。また、AWS CLI の最新バージョンを使用していることを確認してください。

Docker デーモンが応答しないか、クラスターにリソース制約がある

タスク定義で、タスクがインスタンスがサポートできるキャパシティよりも多くのメモリまたは CPU を要求していないかどうかを確認します。必要に応じて、コンテナインスタンスのリソースを調整します。

CPU の問題については、次の手順を実行します。

1. Amazon CloudWatch メトリクスを参照し、コンテナインスタンスが最大 CPU クォータを超えているかどうかを確認します。
2. 必要に応じて、コンテナインスタンスのサイズを増やします。

メモリの問題については、次の手順を実行します。

1. free コマンドを実行し、システムで使用可能なメモリ量を確認します。
2. 必要に応じて、コンテナインスタンスのサイズを増やします。

I/O の問題については、次の手順を実行します。

1. iotop コマンドを実行します。
2. 各サービスにおいて、1 秒あたりの入出力操作 (IOPS) が最も多いタスクを特定します。
3. タスク配置の制約と戦略を使用して、これらのタスクを複数のコンテナインスタンスに分散します。
   または、
   CloudWatch を使用して Amazon Elastic Block Store (Amazon EBS) のバーストバランスメトリクス用のアラームを作成します。次に、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 ECS サービスとの接続を失った

Amazon ECS コンテナエージェントのステータスと接続を検証するには、お使いの Amazon Linux バージョンに応じて、コンテナインスタンスで次のコマンドを実行します。

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

出力でステータスが inactive になっている場合、エージェントは切断されています。この問題を解決するには、次のコマンドを実行してコンテナエージェントを再起動します。

Amazon Linux 1

sudo stop ecs
sudo start ecs

Amazon Linux 2

sudo systemctl stop ecs
sudo systemctl start ecs

次のメッセージのような出力が表示されます。

ecs start/running, process abcd

エージェントの接続性を判断するには、次のログで、該当する期間における error、warn、agent transition state などのキーワードを確認します。

• Amazon ECS コンテナエージェントログは /var/log/ecs/ecs-agent.log.yyyy-mm-dd-hh に配置されています。
• Amazon ECS の init ログは /var/log/ecs/ecs-init.log に配置されています。
• Docker ログは /var/log/docker に配置されています。

ログの情報を参考に、接続に関する問題の根本原因を特定します。

注: Amazon ECS ログコレクターを使用することで、Amazon ECS の全般的なオペレーティングシステム (OS) ログ、Docker ログ、コンテナエージェントログを収集することもできます。

コンテナインスタンス内のローカルかつリアルタイムのタスクステータスを取得するには、次のコマンドを実行し、コンテナインスタンスで実行中のタスクのメタデータを確認します。

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 "
}

出力で、タスクの環境変数、CPU、メモリ、IAM ロールが正しく設定されていることを確認します。タスクに必要なシークレットがあることも確認してください。

サービスで実行されているすべてのタスクに関する詳細情報を表示するには、次のコマンドを実行します。

curl http://localhost:51678/v1/tasks

次の例のような出力が表示されます。

{  "Tasks": [
    {
      "Arn": "arn:aws:ecs:REGION:ACCOUNT_ID:task/TASK_ID",
      "DesiredStatus": "RUNNING",
      "KnownStatus": "RUNNING",
      ... ...
    }
  ]
}

上記のコマンド出力で、ローカルエージェントと Amazon ECS サービスに違いがあるかどうかを確認します。この情報を参考に、タスクが停滞している場所と原因を特定します。

Amazon ECS コンテナエージェントで、既存のタスクを停止するのに長い時間がかかる

Amazon ECS が新しいタスクを送信して PENDING 状態から RUNNING 状態に移行する際、コンテナエージェントには、停止する必要のある既存タスクがある場合があります。この場合、エージェントは既存のタスクを停止するまでは、新しいタスクを開始しません。

コンテナインスタンスレベルでコンテナの停止と開始のタイムアウトを制御するには、/etc/ecs/ecs.config 内の変数 ECS_CONTAINER_STOP_TIMEOUT および ECS_CONTAINER_START_TIMEOUT で環境変数を調整します。ECS_CONTAINER_STOP_TIMEOUT では、コンテナが自発的に終了しなかった場合に、Amazon ECS が強制的にコンテナを終了させるまでの時間を設定します。Linux と Windows では、デフォルトの停止タイムアウト値は 30 秒です。ECS_CONTAINER_START_TIMEOUT では、Amazon ECS コンテナエージェントがコンテナ起動の試行を停止するまでの時間を指定します。デフォルトの起動タイムアウト値は、Linux では 3 分、Windows では 8 分です。

バージョン 1.26.0 以降のエージェントでは、タスクごとに停止と起動のタイムアウトパラメータを定義できます。なお、パラメータを変更すると、タスクが STOPPED 状態に変化する場合があります。コンテナインスタンス A には、インスタンス B が COMPLETE、SUCCESS、HEALTHY 状態に到達する必要があるという依存関係がある場合を例に挙げます。コンテナインスタンス B では、startTimeout 値を設定していません。コンテナインスタンス B がタイムアウト期間内に要求される状態に到達しなかった場合、コンテナインスタンス A は開始できません。

コンテナの依存関係の例については、GitHub のウェブサイトで「例: コンテナの依存関係」を参照してください。

Amazon VPC ルーティングが正しく設定されていない

Amazon ECS または AWS Fargate タスクを実行している VPC サブネットの設定を確認します。サブネットは、Amazon ECS または Amazon Elastic Container Registry (Amazon ECR) にアクセスできる必要があります。設定に関する問題を解決するには、サブネットのルートテーブルにインターネットゲートウェイまたは NAT ゲートウェイがあることを確認してください。インターネットへのアウトバウンドルートがないサブネットでタスクを起動する場合は、AWS PrivateLink を使用します。この設定を行うことで、プライベート IP アドレスを使用する Amazon ECS API にアクセスできます。

また、セキュリティグループのルールで、設定で必要となるポート経由でのインバウンド通信とアウトバウンド通信が許可されていることを確認してください。

必須コンテナが、必須以外のコンテナのうち、状態が HEALTHY ではないものに依存している

必須コンテナの依存対象である、必須以外のコンテナが HEALTHY 状態にならなかった場合、タスクは PENDING 状態に留まることになります。"stoppedReason":"Service ABCXYZ: task last status remained in PENDING too long" というメッセージが表示されます。

この問題を解決するには、必須以外のコンテナを想定通りに動作させる必要があります。根本的な問題を解決できない場合は、コンテナインスタンスのタスク定義を更新し、essential パラメータを true に設定します。それでもタスクの停止を解消できない場合は、停止の原因を確認します。その他のトラブルシューティング手順については、「Amazon ECS タスクが停止した理由を知りたいです」を参照してください。

IAM ロールが欠けているか、正しく設定されていない

タスクが必要なアクセス許可を持たないコンテナインスタンスに配置されている場合、次の例に類似したエラーが表示されます。

(service test) failed to launch a task with (error ECS was unable to assume the role 'arn:aws:iam::111111111111:role/test-fTa-T3J4hVnyL53E' that was provided for this task.Please verify that the role being passed has the proper trust relationship and permissions and that your IAM user has permissions to pass this role.) (タスクを起動できません。ECS は、タスクに指定されたロールを引き受けられませんでした。渡すロールに正しい信頼関係とアクセス許可があり、IAM ユーザーがこのロールを渡すことを許可されていることを確認してください)

この問題を解決するには、コンテナインスタンスに必要なアクセス許可があることを確認します。

さらに、コンテナインスタンスで Amazon ECS 最適化 Amazon マシンイメージ (AMI) を使用していない場合は、Amazon ECS エージェントの設定を確認します。

選択した Windows バージョンにイメージ互換性の問題がある

Windows Fargate タスクで使用するイメージがプラットフォームと互換性がない場合、タスクは失敗します。イメージが Windows サーバーホストと互換性があるかどうかを確認するには、Microsoft のウェブサイトで「Windows コンテナーのバージョンの互換性」を参照してください。次に、Windows タスクを実行するための前提条件を確認します。

定義したイメージの URL が正確であることも確認してください。

関連情報

コンテナの依存関係

amazon-ecs-agent (GitHub のウェブサイト)