トラブルシューティング AWS Batch

コンピューティング環境、ジョブキュー、ジョブ定義、またはジョブに関する問題のトラブルシューティングが必要となる場合があります。この章では、 AWS Batch 環境でこのような問題をトラブルシューティングして解決する方法について説明します。

AWS Batch は IAM ポリシー、ロール、アクセス許可を使用し、Amazon EC2、Amazon ECS AWS Fargate、および Amazon Elastic Kubernetes Service インフラストラクチャで実行されます。これらのサービスに関連する問題のトラブルシューティングを行うには、以下を参照してください:

IAM ユーザーガイドのIAM のトラブルシューティング
Amazon Elastic Container Service 開発者ガイドのAmazon ECS のトラブルシューティング
Amazon EKS ユーザーガイドのAmazon EKS のトラブルシューティング
Amazon EC2 Linux インスタンス用ユーザーガイドのAmazon EC2 Mac インスタンス

AWS Batch

`INVALID`コンピューティング環境

マネージド型コンピューティング環境を誤って設定した可能性があります。設定した場合、コンピューティング環境は INVALID の状態になり、配置するジョブを受け入れられなくなります。以下のセクションでは、考えられる原因と、その原因に基づいトラブルシューティング方法について説明します。

正しくないロール名または ARN

コンピューティング環境が INVALID状態になる最も一般的な原因は、 AWS Batch サービスロールまたは Amazon EC2 スポットフリートロールの名前または Amazon リソースネーム (ARN) が正しくないことです。これは、 AWS CLI または AWS SDKs。でコンピューティング環境を作成する AWS Batch ときは AWS Management Console、正しいサービスロールまたはスポットフリートロールを選択します。ただし、名前または ARN を手動で入力し、またはそれを間違って入力したとします。そうすると、生成されるコンピューティング環境も INVALID になります。

しかし、IAM リソースの名前または ARN を AWS CLI コマンドまたは SDK コードに手動で入力すると仮定します。この場合、文字列を検証 AWS Batch できません。代わりに、 AWS Batch は不正な値を受け入れて環境作成の試みをする必要があります。が環境の作成に AWS Batch 失敗すると、環境は INVALID状態に移行し、次のエラーが表示されます。

無効なサービスロールの場合:

CLIENT_ERROR - Not authorized to perform sts:AssumeRole (Service: AWSSecurityTokenService; Status Code: 403; Error Code: AccessDenied; Request ID: dc0e2d28-2e99-11e7-b372-7fcc6fb65fe7)

無効なスポットフリートロールの場合:

CLIENT_ERROR - Parameter: SpotFleetRequestConfig.IamFleetRole is invalid. (Service: AmazonEC2; Status Code: 400; Error Code: InvalidSpotFleetRequestConfig; Request ID: 331205f0-5ae3-4cea-bac4-897769639f8d) Parameter: SpotFleetRequestConfig.IamFleetRole is invalid

この問題の一般的な原因の１つには、次のシナリオがあります。IAM ロールの名前は、完全な Amazon リソースネーム (ARN) ではなく、 AWS CLI または SDK を使用する場合にのみ指定します。 AWS SDKs ロールを作成した方法によって、ARN に aws-service-role パスプレフィックスが含まれることがあるからです。たとえば、 AWS Batch サービスロールを、サービスにリンクされたロールの使用方法 AWS Batchの手順を使用して手動で作成すると、サービスロール ARN は次のようになります。


arn:aws:iam::123456789012:role/AWSBatchServiceRole

ただし、コンソールの最初の実行ウィザードの一環としてサービスロールを作成した場合、サービスロール ARN は次のようになります。


arn:aws:iam::123456789012:role/aws-service-role/AWSBatchServiceRole

この問題は、 AWS Batch サービスレベルポリシー (AWSBatchServiceRole) を非サービスロールにアタッチした場合にも発生する可能性があります。たとえば、このシナリオでは、次のようなエラーメッセージが表示される場合があります:


CLIENT_ERROR - User: arn:aws:sts::account_number:assumed-role/batch-replacement-role/aws-batch is not 
     authorized to perform: action on resource ...

問題を解決するには、次のいずれかを実行します。

AWS Batch コンピューティング環境を作成するときは、サービスロールに空の文字列を使用します。
以下の形式でサービスロールを指定しますarn:aws:iam::account_number:role/aws-service-role/batch.amazonaws.com/AWSServiceRoleForBatch。

AWS CLI または AWS SDKs、は ARN がaws-service-roleパスプレフィックスを使用しない AWS Batch と見なします。このため、コンピューティング環境を作成するときには、IAM ロールに完全 ARN を指定することが推奨されます。

この設定の誤りがあるコンピューティング環境を修復するには、INVALID コンピューティング環境を修復するを参照してください。

`INVALID` コンピューティング環境を修復する

コンピューティング環境が INVALIDの状態にある場合、無効なパラメータを修復して更新する必要があります。正しくないロール名または ARN については、正しいサービスロールを使ってコンピューティング環境を更新できます。

誤って設定されたコンピューティング環境を修復するには

https://console.aws.amazon.com/batch/ で AWS Batch コンソールを開きます。
ナビゲーションバーから、 AWS リージョン使用するを選択します。
ナビゲーションペインで、Compute environments] (コンピューティング環境) を選択します。
Compute environments] (コンピューティング環境) ページで、編集するコンピューティング環境の横にあるラジオボタンを選択し、Edit] (編集) を選択します。
Update compute environment] (コンピューティング環境の更新) ページの Service role] (サービスロール) で、コンピューティング環境に使用する IAM ロールを選択します。 AWS Batch コンソールには、コンピューティング環境と正しい信頼関係があるロールのみが表示されます。
Save] (保存) を選択して、コンピューティング環境を更新します。

`RUNNABLE` 状態でジョブが止まる

コンピューティング環境にコンピューティングリソースがあるのに、ジョブがRUNNABLE の状態よりも先に進まないとします。その後、何かによってジョブがコンピューティングリソースに配置されず、ジョブキューがブロックされている可能性があります。ジョブがターンを待っているか、スタックしてキューをブロックしているかを確認する方法は次のとおりです。

がヘッドにRUNNABLEジョブがあり、キューをブロックしていること AWS Batch を検出した場合、Amazon CloudWatch Events からブロックされたジョブキューイベントが理由とともに送信されます。同じ理由が、 ListJobsおよび DescribeJobs API コールの一部として statusReasonフィールドに更新されます。

オプションで、 CreateJobQueueおよび UpdateJobQueue API アクションを使用して jobStateTimeLimitActionsパラメータを設定できます。

注記

現在、で使用できる唯一のアクションjobStateLimitActions.actionは、ジョブをキャンセルすることです。

jobStateTimeLimitActions パラメータは、特定の状態のジョブに対してが AWS Batch 実行する一連のアクションを指定するために使用されます。maxTimeSeconds フィールドを使用して、時間しきい値を秒単位で設定できます。

ジョブが定義されたを持つRUNNABLE状態である場合statusReason、 maxTimeSecondsは経過後に指定されたアクションを実行 AWS Batch します。

例えば、 jobStateTimeLimitActionsパラメータを設定して、十分な容量が利用可能になるまで待機している RUNNABLE状態のジョブが最大 4 時間待機するようにできます。これを行うには、ジョブをキャンセルCAPACITY:INSUFFICIENT_INSTANCE_CAPACITYし、次のジョブがジョブキューの先頭に進むのを許可する前に、を statusReasonに設定し、を maxTimeSeconds 144000 に設定します。

ジョブキューがブロックされていることをが検出 AWS Batch したときにが提供する理由は、次のとおりです。このリストには、 ListJobsおよび DescribeJobs API アクションから返されるメッセージが表示されます。これらは、 jobStateLimitActions.statusReasonパラメータに対して定義できる値と同じです。

理由： 接続されているすべてのコンピューティング環境に容量不足エラーがあります。リクエストされると、容量不足エラーが発生した Amazon EC2 インスタンス AWS Batch を検出します。ジョブを手動でキャンセルするか、に jobStateTimeLimitActionsパラメータを設定することでstatusReason、後続のジョブをキューの先頭に移動できます。
- statusReason ジョブがスタックしている間のメッセージ： CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY - Service cannot fulfill the capacity requested for instance type [instanceTypeName]
- reason に使用される jobStateTimeLimitActions： CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY
- statusReason ジョブがキャンセルされた後のメッセージ： Canceled by JobStateTimeLimit action due to reason: CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY
[Note:] (メモ:)
1. AWS Batch サービスロールには、この検出が機能するためのautoscaling:DescribeScalingActivitiesアクセス許可が必要です。AWSServiceRoleForBatch サービスにリンクされたロール (SLR) または AWSBatchServiceRolePolicy管理ポリシーを使用する場合、アクセス許可ポリシーが更新されるため、何もする必要はありません。
2. SLR または管理ポリシーを使用する場合は、でブロックされたジョブキューイベントautoscaling:DescribeScalingActivitiesと更新されたジョブステータスを受信できるように、およびアクセスec2:DescribeSpotFleetRequestHistory許可を追加する必要がありますRUNNABLE。さらに、は、ジョブキューに設定されている場合でも、 jobStateTimeLimitActionsパラメータを使用してcancellationアクションを実行するためにこれらのアクセス許可 AWS Batch が必要です。
3. マルチノード並列 (MNP) ジョブの場合、アタッチされた高優先度の Amazon EC2 コンピューティング環境でinsufficient capacityエラーが発生すると、優先度の低いコンピューティング環境でこのエラーが発生してもキューがブロックされます。
理由： すべてのコンピューティング環境には、ジョブ要件よりも小さいmaxvCpusパラメータがあります。ジョブを手動でキャンセルするか、に jobStateTimeLimitActionsパラメータを設定することでstatusReason、後続のジョブをキューの先頭に移動できます。オプションで、ブロックされたジョブのニーズに合わせてプライマリコンピューティング環境の maxvCpusパラメータを増やすことができます。
- statusReason ジョブがスタックしている間のメッセージ： MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE - CE(s) associated with the job queue cannot meet the CPU requirement of the job.
- reason に使用される jobStateTimeLimitActions： MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE
- statusReason ジョブがキャンセルされた後のメッセージ： Canceled by JobStateTimeLimit action due to reason: MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE
理由： コンピューティング環境には、ジョブ要件を満たすインスタンスがありません。ジョブがリソースをリクエストすると、はアタッチされたコンピューティング環境が受信ジョブに対応できないことを AWS Batch 検出します。ジョブを手動でキャンセルするか、に jobStateTimeLimitActionsパラメータを設定することでstatusReason、後続のジョブをキューの先頭に移動できます。オプションで、コンピューティング環境の許可されたインスタンスタイプを再定義して、必要なジョブリソースを追加できます。
- statusReason ジョブがスタックしている間のメッセージ： MISCONFIGURATION:JOB_RESOURCE_REQUIREMENT - The job resource requirement (vCPU/memory/GPU) is higher than that can be met by the CE(s) attached to the job queue.
- reason に使用される jobStateTimeLimitActions： MISCONFIGURATION:JOB_RESOURCE_REQUIREMENT
- statusReason ジョブがキャンセルされた後のメッセージ： Canceled by JobStateTimeLimit action due to reason: MISCONFIGURATION:JOB_RESOURCE_REQUIREMENT
理由： すべてのコンピューティング環境にサービスロールの問題があります。これを解決するには、サービスロールのアクセス許可をAWS Batch マネージドサービスロールのアクセス許可と比較し、ギャップに対処します。

同様のエラーを避けるために、AWS Batch コンピューティング環境に SLR を使用するのがベストプラクティスです。

ジョブを手動でキャンセルするか、に jobStateTimeLimitActionsパラメータを設定することでstatusReason、後続のジョブをキューの先頭に移動できます。サービスロールの問題を解決しないと (複数の）、次のジョブもブロックされる可能性があります。この問題を手動で調査して解決することをお勧めします。
- statusReason ジョブがスタックしている間のメッセージ： MISCONFIGURATION:SERVICE_ROLE_PERMISSIONS – Batch service role has a permission issue.
- reason に使用される jobStateTimeLimitActions： MISCONFIGURATION:SERVICE_ROLE_PERMISSIONS
- statusReason ジョブがキャンセルされた後のメッセージ： Canceled by JobStateTimeLimit action due to reason: MISCONFIGURATION:SERVICE_ROLE_PERMISSIONS
理由： すべてのコンピューティング環境が無効です。詳細については、「 INVALIDコンピューティング環境」を参照してください。注: このエラーを解決するために、 jobStateTimeLimitActionsパラメータを使用してプログラムアクションを設定することはできません。
- statusReason ジョブがスタックしている間のメッセージ： ACTION_REQUIRED - CE(s) associated with the job queue are invalid.
理由： AWS Batch はブロックされたキューを検出しましたが、理由を特定できません。注: このエラーを解決するために、 jobStateTimeLimitActionsパラメータを使用してプログラムアクションを設定することはできません。トラブルシューティングの詳細については、 re:Post の「で RUNNABLE で AWS Batch ジョブが停止する AWSのはなぜですか？」を参照してください。
- statusReason ジョブがスタックしている間のメッセージ： UNDETERMINED - Batch job is blocked, root cause is undetermined.

イベントから CloudWatch イベントを受信しなかった場合、または不明な理由イベントを受信した場合、この問題の一般的な原因をいくつか示します。

awslogsログドライバーがコンピューティングリソースで設定されていない

AWS Batch ジョブはログ情報を CloudWatch Logs に送信します。この機能を有効にするには、awslogsのログドライバーを使用するようにコンピューティングリソースを設定する必要があります。コンピューティングリソース AMI を、Amazon ECSに最適化されたAMI (または Amazon Linux) に基づいて作成すると仮定します。次に、このドライバーはデフォルトにより ecs-initのパッケージに登録されます。ここで、別のベース AMI を使用すると仮定します。別の基本 AMI を使用する場合、Amazon ECS コンテナエージェントが開始するときに、awslogs ログドライバーが、 ECS_AVAILABLE_LOGGING_DRIVERS 環境変数で使用可能なログドライバーとして指定されていることを検証する必要があります。詳細については、コンピューティングリソースの AMI 仕様およびコンピューティングリソース AMI の作成を参照してください。

リソースの不足

コンピューティングリソースが割り当てることができるリソースを超えた CPU、またはメモリリソースがジョブ定義に指定されている場合、ジョブは配置されません。たとえば、ジョブが 4 GiB のメモリを指定し、コンピューティングリソースで使用できるのがそれ以下の場合を考えます。そうなると、そのジョブをそれらのコンピューティングリソースに配置できない場合があります。この場合、ジョブ定義に指定するメモリを減らすか、あるいは環境のコンピューティングリソースを追加する必要があります。一部のメモリは、Amazon ECS コンテナエージェントやその他の重要なシステムプロセス用に予約されています。詳細については、コンピューティングリソースメモリ管理を参照してください。

コンピューティングリソースへのインターネットアクセスなし

コンピューティングリソースには、Amazon ECS サービスエンドポイントと通信するために外部ネットワークアクセスが必要です。これは、インターフェイス VPC エンドポイントを介して、またはパブリック IP アドレスを持つコンピュートリソースを通じて可能になります。

インターフェイス VPC エンドポイントの詳細については、Amazon Elastic Container Service 開発者ガイドのAmazon ECS インターフェイス VPC エンドポイント (AWS PrivateLink)を参照してください。

インターフェイス VPC エンドポイントが設定されておらず、コンピューティングリソースがパブリック IP アドレスを持たない場合は、ネットワークアドレス変換 (NAT) を使用してこのアクセスを提供する必要があります。詳細については、Amazon VPC ユーザーガイドに含まれるNAT ゲートウェイを参照してください。詳細については、「VPC を作成する」を参照してください。

Amazon EC2 インスタンスの制限に達しました

アカウントがで起動できる Amazon EC2 インスタンスの数 AWS リージョンは、EC2 インスタンスのクォータによって決まります。特定のインスタンスタイプにも per-instance-typeクォータがあります。ユーザーのアカウントの Amazon EC2 インスタンス制限の詳細 (制限の引き上げをリクエストする方法を含む) については、 Linuxインスタンスの Amazon EC2ユーザーガイドのAmazon EC2 サービスの制限を参照してください。

Amazon ECS コンテナエージェントがインストールされていない

AWS Batch ジョブを実行するには、Amazon ECS コンテナエージェントは Amazon マシンイメージ (AMI) にインストールされる必要があります。Amazon ECS コンテナエージェントが Amazon ECSに最適化 AMI にデフォルトでインストールされます。詳細については、Amazon ECS コンテナエージェントの構成を参照してくださいAmazon Elastic Container Service デベロッパーガイドにあります。

詳細については、 re:Post の AWS Batch 「ジョブが RUNNABLEステータスのままになるのはなぜですか？」を参照してください。

作成時にタグが付けられていないスポットインスタンス

AWS Batch コンピューティングリソースのスポットインスタンスのタグ付けは、2017 年 10 月 25 日にサポートされています。以前には、Amazon EC2 スポットフリートロール用の推奨 IAM 管理ポリシー (AmazonEC2SpotFleetRole) には、起動時にスポットインスタンスにタグを付けるアクセス権限が含まれていませんでした。新しい推奨の IAM 管理ポリシーは、AmazonEC2SpotFleetTaggingRole と呼ばれます。起動時のスポットインスタンスへのタグ付けをサポートします。

作成時にスポットインスタンスのタグ付けを修正するには、以下の手順に従って、現在推奨の IAM 管理ポリシーを Amazon EC2 スポットフリートロールに割り当てます。その方法で、そのロールで今後作成されるスポットインスタンスには、作成時にインスタンスタグを適用する権限が付与されます。

現在の IAM 管理ポリシーを Amazon EC2 スポットフリートロールに割り当てるには

IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
Roles] (ロール) を選択し、Amazon EC2 スポットフリートロールを選択します。
Attach policy] (ポリシーのアタッチ) を選択します。
AmazonEC2SpotFleetTaggingRole を選択し、ポリシーのアタッチを選択します。
Amazon EC2 スポットフリートロールを再度選択し、前のポリシーを削除します。
AmazonEC2SpotFleetRole ポリシーの右側にある x を選択し、 をデタッチ を選択します。

スポットインスタンスがスケールダウンしない

AWS Batch は、2021 年 3 月 10 日に AWSServiceRoleForBatchサービスにリンクされたロールを導入しました。コンピューティング環境の serviceRole パラメータにロールが指定されていない場合、このサービスにリンクされたロールが、サービスロールとして使用されます。ただし、サービスにリンクされたロールが EC2 スポットコンピューティング環境で使用されているが、使用されているスポットロールに AmazonEC2SpotFleetTaggingRole 管理ポリシーが含まれていないとします。そうであれば、スポットインスタンスはスケールダウンしません。その結果、このオペレーションを実行する権限がありませんというエラーメッセージを受け取ります。以下の手順で、spotIamFleetRole パラメータで使用するスポットフリートロールを更新してください。詳細については、IAM ユーザーガイドの「サービスにリンクされたロールの使用」および「 AWS のサービスにアクセス許可を委任するロールの作成」を参照してください。

トピック

のスポットフリートロールに AmazonEC2SpotFleetTaggingRole 管理ポリシーをアタッチする AWS Management Console
を使用して AmazonEC2SpotFleetTaggingRole 管理ポリシーをスポットフリートロールにアタッチする AWS CLI

のスポットフリートロールに AmazonEC2SpotFleetTaggingRole 管理ポリシーをアタッチする AWS Management Console

現在の IAM 管理ポリシーを Amazon EC2 スポットフリートロールに割り当てるには

IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
Roles] (ロール) を選択し、Amazon EC2 スポットフリートロールを選択します。
Attach policy] (ポリシーのアタッチ) を選択します。
AmazonEC2SpotFleetTaggingRole を選択し、ポリシーのアタッチ を選択します。
Amazon EC2 スポットフリートロールを再度選択し、前のポリシーを削除します。
AmazonEC2SpotFleetRole ポリシーの右側にある x を選択し、 をデタッチ を選択します。

を使用して AmazonEC2SpotFleetTaggingRole 管理ポリシーをスポットフリートロールにアタッチする AWS CLI

サンプルコマンドは、Amazon EC2 スポットフリートロールの名前が AmazonEC2SpotFleetRole であることを前提としています。ロールで別の名前が使用されている場合は、一致するようにコマンドを調整します。

AmazonEC2SpotFleetTaggingRole 管理ポリシーをスポットフリートロールにアタッチするには

AmazonEC2SpotFleetTaggingRole マネージド IAM ポリシーを AmazonEC2SpotFleetRole ロールにアタッチするには、を使用して次のコマンドを実行します AWS CLI。
```
$ aws iam attach-role-policy \
    --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2SpotFleetTaggingRole \
    --role-name AmazonEC2SpotFleetRole
```
AmazonEC2SpotFleetRole ロールから AmazonEC2SpotFleetRole マネージド IAM ポリシーをデタッチするには、を使用して次のコマンドを実行します AWS CLI。
```
$ aws iam detach-role-policy \
    --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2SpotFleetRole \
    --role-name AmazonEC2SpotFleetRole
```

Secrets Manager のシークレットを取得できない

バージョン 1.16.0-1 より以前の Amazon ECS エージェントで AMI を使用している場合は、この機能を使用するため、Amazon ECS エージェント設定変数 ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE=true を使用する必要があります。そのインスタンスを作成するときに、新しいコンテナインスタンスの ./etc/ecs/ecs.config ファイルに追加します。または、既存のインスタンスに追加することもできます。既存のインスタンスに追加する場合は、追加後に ECS Agent を再起動する必要があります。詳細については、Amazon Elastic Container Service デベロッパーガイドのAmazon ECS コンテナエージェントの構成を参照してください。

ジョブ定義リソース要件を上書きできない

に渡される containerOverrides 構造の memoryおよび vcpus メンバーで指定されたメモリと vCPU のオーバーライドはSubmitJob、ジョブ定義の resourceRequirements 構造で指定されたメモリと vCPU の要件を上書きすることはできません。

これらのリソース要件を上書きしようとすると、次のエラーメッセージが表示されることがあります:

この値は非推奨のキーで送信され、ジョブ定義のリソース要件で提供される値と競合する可能性があります。

これを修正するには、containerOverrides] の resourceRequirements] メンバーにメモリと vCPU の要件を指定します。たとえば、メモリと vCPU の上書きが次の行で指定されているとします。


"containerOverrides": {
   "memory": 8192,
   "vcpus": 4
}

それらを次に変更します:


"containerOverrides": {
   "resourceRequirements": [
      {
         "type": "MEMORY",
         "value": "8192"
      },
      {
         "type": "VCPU",
         "value": "4"
      }
   ],
}

ジョブ定義の containerProperties] オブジェクトで指定されているメモリと vCPU の要件と同じ変更を行います。たとえば、メモリと vCPU の要件が次の行で指定されているとします。


{
   "containerProperties": {
      "memory": 4096,
      "vcpus": 2,
}

それらを次に変更します:


"containerProperties": {
   "resourceRequirements": [
      {
         "type": "MEMORY",
         "value": "4096"
      },
      {
         "type": "VCPU",
         "value": "2"
      }
   ],
}

`desiredvCpus` 設定を更新すると、エラーメッセージが表示されます

AWS Batch API を使用して目的の vCPUs (desiredvCpus) 設定を更新すると、次のエラーメッセージが表示されます。

Manually scaling down compute environment is not supported. Disconnecting job queues from compute environment will cause it to scale-down to minvCpus.

この問題は、desiredvCpus 更新された desiredvCpus 値が現在の値より小さい場合に発生します。desiredvCpus 値を更新するには、次のいずれかが当てはまる必要があります：

desiredvCpus 値は minvCpus と maxvCpus 値の間になければなりません。
値は、desiredvCpusStart Frame (スタートフレーム) desiredvCpus 値と同等かそれ以上である必要があります。

AWS Batch Amazon EKS での

トピック

INVALIDコンピューティング環境
AWS Batch Amazon EKS ジョブのが RUNNABLEステータスのままになる
aws-auth ConfigMapのフィールドが正しく設定されていることを確認します
RBAC の権限またはバインディングが適切に設定されていない

`INVALID`コンピューティング環境

サポート対象外の Kubernetes バージョン

CreateComputeEnvironment API オペレーションまたは API オペレーション UpdateComputeEnvironment を使用してコンピュート環境を作成または更新すると、次のようなエラーメッセージが表示されることがあります。この問題は、Kubernetes でサポートされていないバージョンを EC2Configuration で指定した場合に発生します。


At least one imageKubernetesVersion in EC2Configuration is not supported.

この問題を解決するには、コンピュート環境を削除し、サポートされている Kubernetes バージョンで再作成してください。

Amazon EKS クラスターでマイナーバージョンアップグレードを実行できます。たとえば、イナーバージョンがサポートされていない場合でも、クラスターを 1.xx から 1.yy マにアップグレードできます。

ただし、INVALID メジャーバージョンを更新すると、コンピュート環境のステータスがに変わることがあります。たとえば、1.xx から 2.yy へのメジャーバージョンアップグレードを実行する場合などです。メジャーバージョンがでサポートされていない場合は AWS Batch、次のようなエラーメッセージが表示されます。


reason=CLIENT_ERROR - ... EKS Cluster version [2.yy] is unsupported

この問題を解決するには、API オペレーションを使用してコンピューティング環境を作成または更新するときに、Kubernetes サポートされているバージョンを指定してください。

AWS Batch Amazon EKS のでは、現在次のKubernetesバージョンがサポートされています。

1.29
1.28
1.27
1.26
1.25
1.24
1.23

インスタンスプロファイルが存在しません

指定されたインスタンスプロファイルが存在しない場合、 AWS Batch Amazon EKS のコンピューティング環境ステータスはに変更されますINVALID。statusReason パラメータに次のようなエラーセットが表示されます。


CLIENT_ERROR - Instance profile arn:aws:iam::...:instance-profile/<name> does not exist

この問題を解決するには、ワーキングインスタンスプロファイルを指定または作成します。詳細については、Amazon EKS ユーザーガイドのAmazon EKS ノードの IAM ロールを参照してくださない。

無効な Kubernetes 名前空間が

AWS Batch 上の Amazon EKS がコンピューティング環境の名前空間を検証できない場合、コンピューティング環境のステータスはに変更されますINVALID。たとえば、この問題は名前空間が存在しない場合に発生する可能性があります。

statusReason パラメータには、次のようなエラーメッセージが設定されています。


CLIENT_ERROR - Unable to validate Kubernetes Namespace

この問題は、次のいずれかに該当する場合に発生する可能性があります:

CreateComputeEnvironment 呼び出し中のKubernetes 名前空間文字列は存在しません。詳細については、「」を参照してくださいCreateComputeEnvironment。
名前空間の管理に、必要なロールベースのアクセス制御 (RBAC) 権限が正しく設定されていません。
AWS Batch は Amazon EKS Kubernetes API サーバーエンドポイントにアクセスできません。

この問題を解決するには、aws-auth ConfigMapのフィールドが正しく設定されていることを確認しますをご参照ください。詳細については、Amazon EKS AWS Batch でのの開始方法を参照してください。

削除されたコンピューティング環境

Amazon EKS コンピューティング環境にアタッチされているを削除する前に AWS Batch 、Amazon EKS クラスターを削除するとします。そうすると、コンピューティング環境のステータスは INVALID に変わります。このシナリオでは、Amazon EKS クラスターを同じ名前で再作成すると、コンピューティング環境は正しく機能しません。

この問題を解決するには、を削除してから、Amazon EKS コンピューティング環境でを再作成 AWS Batch します。

ノードは Amazon EKS クラスターに加わりません

AWS Batch Amazon EKS 上のは、すべてのノードが Amazon EKS クラスターに参加していないと判断した場合、コンピューティング環境をスケールダウンします。 AWS Batch で Amazon EKS がコンピューティング環境をスケールダウンすると、コンピューティング環境のステータスがに変更されますINVALID。

注記

AWS Batch は、問題をデバッグできるように、コンピューティング環境のステータスをすぐに変更しません。

statusReason パラメータには、次のようなエラーメッセージが設定されています。

Your compute environment has been INVALIDATED and scaled down because none of the instances joined the underlying ECS Cluster. Common issues preventing instances joining are the following: VPC/Subnet configuration preventing communication to ECS, incorrect Instance Profile policy preventing authorization to ECS, or customized AMI or LaunchTemplate configurations affecting ECS agent.

Your compute environment has been INVALIDATED and scaled down because none of the nodes joined the underlying Amazon EKS Cluster. Common issues preventing nodes joining are the following: networking configuration preventing communication to Amazon EKS Cluster, incorrect Amazon EKS Instance Profile or Kubernetes RBAC policy preventing authorization to Amazon EKS Cluster, customized AMI or LaunchTemplate configurations affecting Amazon EKS/Kubernetes node bootstrap.

デフォルトの Amazon EKS AMI を使用する場合、この問題の最も一般的な原因は次のとおりです：

インスタンスロールが正しく設定されていません。詳細については、Amazon EKS ユーザーガイドのAmazon EKS ノードの IAM ロールを参照してください。
サブネットが正しく設定されていません。詳細については、Amazon EKS ユーザーガイドのAmazon EKS VPC とサブネットの要件と考慮事項を参照してください。
セキュリティグループが正しく設定されていません。詳細については、Amazon EKS ユーザーガイドのAmazon EKS セキュリティグループに関する考慮事項を参照してください。

注記
また、Personal Health Dashboard (PHD) にエラー通知が表示される場合があります。

AWS Batch Amazon EKS ジョブのが `RUNNABLE`ステータスのままになる

マネージド型ノードグループを作成する場合、または aws-auth を使用してノードグループを作成する場合、ConfigMap eksctl が自動的に作成され、クラスターに適用されます。aws-auth ConfigMap は最初に、ノードがクラスターに参加できるようにするために作成されました。ただし、aws-auth ConfigMap を使用して、ユーザーとロールにロールベースのアクセス制御 (RBAC) アクセスを追加することもできます。

aws-auth ConfigMap が正しく設定されていることを確認するには：

マップされたロールを以下の aws-auth ConfigMap から取得します：
```
$ kubectl get configmap -n kube-system aws-auth -o yaml
```
roleARN が次のように設定されていることを確認します。

rolearn: arn:aws:iam::aws_account_number:role/AWSServiceRoleForBatch

注記
また、Amazon EKS コントロールプレーンログを確認することもできます。詳細については、Amazon EKS ユーザーガイドの Amazon EKS クラスターコントロールプレーンのログを参照してください。

ジョブが RUNNABLEのステータスのままになる問題を解決するには、kubectl を使用してマニフェストを再適用することをお勧めします。詳細については、ステップ 1: 用の Amazon EKS クラスターを準備する AWS Batchを参照してください。または、kubectl を使用して aws-auth ConfigMap を手動で編集することもできます。詳細については、Amazon EKS ユーザーガイドのIAMユーザーとロールのAmazon EKS クラスターへのアクセスを有効にするを参照してください。

`aws-auth ConfigMap`のフィールドが正しく設定されていることを確認します

aws-auth ConfigMap が正しく設定されていることを確認するには：

aws-auth ConfigMap にマップされたロールを取得します。
```
$ kubectl get configmap -n kube-system aws-auth -o yaml
```
roleARN が次のように設定されていることを確認します。

rolearn: arn:aws:iam::aws_account_number:role/AWSServiceRoleForBatch

注記
パス aws-service-role/batch.amazonaws.com/が、サービスにリンクされたロールの ARN から削除されました。これは aws-auth 設定マップに問題があるためです。詳細については、パスを持つロールは、aws-authconfigmap の ARN にパスが含まれていると機能しないを参照してください。

注記
また、Amazon EKS コントロールプレーンログを確認することもできます。詳細については、Amazon EKS ユーザーガイドの Amazon EKS クラスターコントロールプレーンのログを参照してください。

RBAC の権限またはバインディングが適切に設定されていない

RBAC 権限またはバインディングの問題が発生した場合は、aws-batch Kubernetesのロールが Kubernetes 名前空間にアクセスできることを確認してください：


$ kubectl get namespace namespace --as=aws-batch


$ kubectl auth can-i get ns --as=aws-batch

kubectl describe コマンドを使用して、クラスターロールまたは Kubernetesの名前空間の権限を確認することもできます。


$ kubectl describe clusterrole aws-batch-cluster-role

以下は出力例です。


Name:         aws-batch-cluster-role
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources                                      Non-Resource URLs  Resource Names  Verbs
  ---------                                      -----------------  --------------  -----
  configmaps                                     []                 []              [get list watch]
  nodes                                          []                 []              [get list watch]
  pods                                           []                 []              [get list watch]
  daemonsets.apps                                []                 []              [get list watch]
  deployments.apps                               []                 []              [get list watch]
  replicasets.apps                               []                 []              [get list watch]
  statefulsets.apps                              []                 []              [get list watch]
  clusterrolebindings.rbac.authorization.k8s.io  []                 []              [get list]
  clusterroles.rbac.authorization.k8s.io         []                 []              [get list]
  namespaces                                     []                 []              [get]


$ kubectl describe role aws-batch-compute-environment-role -n my-aws-batch-namespace

以下は出力例です。


Name:         aws-batch-compute-environment-role
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources                               Non-Resource URLs  Resource Names  Verbs
  ---------                               -----------------  --------------  -----
  pods                                    []                 []              [create get list watch delete patch]
  serviceaccounts                         []                 []              [get list]
  rolebindings.rbac.authorization.k8s.io  []                 []              [get list]
  roles.rbac.authorization.k8s.io         []                 []              [get list]

この問題を解決するには、RBAC 権限と rolebinding コマンドを再度適用します。詳細については、ステップ 1: 用の Amazon EKS クラスターを準備する AWS Batchを参照してください。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

Service Quotas

ベストプラクティス

トラブルシューティング AWS Batch

目次

AWS Batch

INVALIDコンピューティング環境

正しくないロール名または ARN

INVALID コンピューティング環境を修復する

誤って設定されたコンピューティング環境を修復するには

RUNNABLE 状態でジョブが止まる

注記

作成時にタグが付けられていないスポットインスタンス

現在の IAM 管理ポリシーを Amazon EC2 スポットフリートロールに割り当てるには

スポットインスタンスがスケールダウンしない

トピック

のスポットフリートロールに AmazonEC2SpotFleetTaggingRole 管理ポリシーをアタッチする AWS Management Console

現在の IAM 管理ポリシーを Amazon EC2 スポットフリートロールに割り当てるには

を使用して AmazonEC2SpotFleetTaggingRole 管理ポリシーをスポットフリートロールにアタッチする AWS CLI

AmazonEC2SpotFleetTaggingRole 管理ポリシーをスポットフリートロールにアタッチするには

Secrets Manager のシークレットを取得できない

ジョブ定義リソース要件を上書きできない

desiredvCpus 設定を更新すると、エラーメッセージが表示されます

AWS Batch Amazon EKS での

トピック

INVALIDコンピューティング環境

サポート対象外の Kubernetes バージョン

インスタンスプロファイルが存在しません

無効な Kubernetes 名前空間が

削除されたコンピューティング環境

ノードは Amazon EKS クラスターに加わりません

注記

注記

AWS Batch Amazon EKS ジョブの が RUNNABLEステータスのままになる

注記

aws-auth ConfigMapのフィールドが正しく設定されていることを確認します

注記

注記

RBAC の権限またはバインディングが適切に設定されていない

`INVALID`コンピューティング環境

`INVALID` コンピューティング環境を修復する

`RUNNABLE` 状態でジョブが止まる

`desiredvCpus` 設定を更新すると、エラーメッセージが表示されます

`INVALID`コンピューティング環境

AWS Batch Amazon EKS ジョブのが `RUNNABLE`ステータスのままになる

`aws-auth ConfigMap`のフィールドが正しく設定されていることを確認します