Amazon EKS プライベートクラスターで AWS Batch の使用を開始する

AWS Batch は Amazon Elastic Kubernetes Service (Amazon EKS) クラスターでのバッチワークロードをオーケストレーションするマネージドサービスです。このサービスにはキューイング、依存関係の追跡、ジョブの再試行と優先順位の管理、ポッド管理、ノードスケーリングが含まれます。この機能により、既存のプライベート Amazon EKS クラスターを AWS Batch に接続して、ジョブを大規模に実行できます。eksctl (Amazon EKS のコマンドラインインターフェイス)、AWS コンソール、AWS Command Line Interface を使用して、プライベート Amazon EKS クラスターを他のすべての必要なリソースと共に作成できます。

Amazon EKS プライベート専用クラスターには、デフォルトではインバウンド/アウトバウンドインターネットアクセスがなく、VPC 内または接続されたネットワーク内からのみ API サーバーにアクセスできます。他の AWS サービスへのプライベートアクセスを有効にするには Amazon VPC エンドポイントを使用します。eksctl は既存の Amazon VPC とサブネットを使用した完全なプライベートクラスターの作成をサポートします。eksctl はまた、提供された Amazon VPC に Amazon VPC エンドポイントを作成し、提供されたサブネットのルートテーブルを変更します。

eksctl はメインルートテーブルを変更しないため、各サブネットには明示的に関連付けられたルートテーブルが必要です。クラスターは Amazon VPC 内のコンテナレジストリからイメージを取得する必要があります。Amazon VPC 内に Amazon Elastic Container Registry を作成し、そこにコンテナイメージをコピーしてノードの取得元にすることもできます。詳細については、「あるリポジトリから別のリポジトリにコンテナイメージをコピーする」を参照してください。Amazon ECR のプライベートリポジトリの使用を開始するには、「Amazon ECR private repositories」を参照してください。

必要に応じて、Amazon ECR を使用してプルスルーキャッシュルールを作成することもできます。外部パブリックレジストリのプルスルーキャッシュルールを作成したら、Amazon ECR プライベートレジストリの URI を使用して、その外部パブリックレジストリからイメージをプルできます。その後、Amazon ECR でリポジトリが作成され、イメージがキャッシュされます。キャッシュされたイメージが Amazon ECR プライベートレジストリ URI を使用してプルされると、Amazon ECR はリモートレジストリをチェックしてイメージの新しいバージョンがあるかどうかを確認し、24 時間ごとに最大 1 回、プライベートレジストリを更新します。

概要

このチュートリアルでは、AWS CloudShell、kubectl、eksctl を使用してプライベート Amazon EKS で AWS Batch を設定する方法を示します。

前提条件

このチュートリアルでは、AWS マネジメントコンソール から直接起動できる、ブラウザベースの事前認証されたシェルである AWS CloudShell を取り上げます。これにより、パブリックインターネットアクセスがなくなると、クラスターにアクセスできます。AWS CLI、kubectl、eksctl は、AWS CloudShell の一部として既にインストールされている場合があります。AWS CloudShell の詳細については、「AWS CloudShell ユーザーガイド」を参照してください。代替策として、AWS CloudShell をクラスターの VPC または接続済みのネットワークに接続することもできます。

kubectl コマンドを実行するには Amazon EKS クラスターへのプライベートアクセスが必要です。つまり、クラスター API サーバーへのすべてのトラフィックは、クラスターの VPC または接続されたネットワーク内から送信する必要があります。

ステップ 1: AWS Batch の EKS クラスターを作成する

クラスターを作成するには、eksctl と次の設定ファイルを使用することをお勧めします。クラスターを手動でセットアップするには、「Amazon EKS ユーザーガイド」の「インターネットアクセスが制限されたプライベートクラスターをデプロイする」の指示に従います。

ステップ 2: AWS Batch 用の EKS クラスターを準備する

すべてのステップが必要であり、AWS CloudShell で実行する必要があります。

ステップ 3: Amazon EKS コンピューティング環境を作成する

AWS Batch コンピューティング環境は、バッチワークロードのニーズを満たすコンピューティングリソースパラメータを定義します。マネージドコンピューティング環境では、AWS Batch はAmazon EKS クラスター内のコンピューティングリソース (Kubernetes ノード) の容量とインスタンスタイプを管理します。これは、コンピューティング環境の作成時に定義するコンピューティングリソースの仕様に基づいています。EC2 オンデマンドインスタンスまたは EC2 スポットインスタンスを選択できます。

AWSServiceRoleForBatch サービスにリンクされたロールが Amazon EKS クラスターにアクセスできるようになったので、AWS Batch リソースを作成できます。まず、Amazon EKS クラスターを指すコンピューティング環境を作成します。

$ cat <<EOF > ./batch-eks-compute-environment.json
{
  "computeEnvironmentName": "My-Eks-CE1",
  "type": "MANAGED",
  "state": "ENABLED",
  "eksConfiguration": {
    "eksClusterArn": "arn:aws:eks:us-east-1:<your-account-ID>:cluster/my-test-cluster",
    "kubernetesNamespace": "my-aws-batch-namespace"
  },
  "computeResources": {
    "type": "EC2",
    "allocationStrategy": "BEST_FIT_PROGRESSIVE",
    "minvCpus": 0,
    "maxvCpus": 128,
    "instanceTypes": [
        "m5"
    ],
    "subnets": [
        "<eks-cluster-subnets-with-access-to-the-image-for-image-pull>"
    ],
    "securityGroupIds": [
        "<eks-cluster-sg>"
    ],
    "instanceRole": "<eks-instance-profile>"
  }
}
EOF
        

$ aws batch create-compute-environment --cli-input-json file://./batch-eks-compute-environment.json

ステップ 4: ジョブキューを作成してコンピューティング環境をアタッチする

$ aws batch describe-compute-environments --compute-environments My-Eks-CE1

この新しいジョブキューに送信されたジョブは、コンピューティング環境に関連付けられた Amazon EKS クラスターに結合された AWS Batch マネージドノードでポッドとして実行されます。

$ cat <<EOF > ./batch-eks-job-queue.json
 {
    "jobQueueName": "My-Eks-JQ1",
    "priority": 10,
    "computeEnvironmentOrder": [
      {
        "order": 1,
        "computeEnvironment": "My-Eks-CE1"
      }
    ]
  }
EOF

$ aws batch create-job-queue --cli-input-json file://./batch-eks-job-queue.json

ステップ 5: プルスルーキャッシュを使用して Amazon ECR を作成する

クラスターにはパブリックインターネットアクセスがないため、コンテナイメージ用の Amazon ECR を作成する必要があります。以下の手順では、イメージを保存するプルスルーキャッシュルールを使用して Amazon ECR を作成します。

ステップ 6: ジョブ定義を登録する

次のジョブ定義は、ポッドに 60 秒間スリープするように指示します。

ジョブ定義のイメージフィールドに、パブリック ECR リポジトリのイメージへのリンクではなく、プライベート ECR リポジトリに保存されているイメージへのリンクを指定します。以下はジョブ定義の例です。

$ cat <<EOF > ./batch-eks-job-definition.json
{
  "jobDefinitionName": "MyJobOnEks_Sleep",
  "type": "container",
  "eksProperties": {
    "podProperties": {
      "hostNetwork": true,
      "containers": [
        {
          "image": "<your-account-ID>.dkr.ecr.us-east-1.amazonaws.com/my-prefix/amazonlinux/amazonlinux:2",
          "command": [
            "sleep",
            "60"
          ],
          "resources": {
            "limits": {
              "cpu": "1",
              "memory": "1024Mi"
            }
          }
        }
      ],
      "metadata": {
        "labels": {
          "environment": "test"
        }
      }
    }
  }
}
EOF

$ aws batch register-job-definition --cli-input-json file://./batch-eks-job-definition.json

ステップ 7: ジョブ実行を送信する

AWS CloudShell で次の AWS CLI コマンドを実行して新しいジョブを送信し、一意の JobID を返します。

$ aws batch submit-job --job-queue My-Eks-JQ1 \
    --job-definition MyJobOnEks_Sleep - -job-name My-Eks-Job1

ステップ 8: ジョブの出力を表示する

ジョブのステータスを確認するには:

$ aws batch describe-jobs --job <JobID-from-submit-response>

startedAt と stoppedAt は 1 分間隔で配置する必要があります。

ステップ 9: (オプション) オーバーライドを含むジョブを送信する

このジョブは、コンテナに渡されたコマンドをオーバーライドします。

$ cat <<EOF > ./submit-job-override.json
{
  "jobName": "EksWithOverrides",
  "jobQueue": "My-Eks-JQ1",
  "jobDefinition": "MyJobOnEks_Sleep",
  "eksPropertiesOverride": {
    "podProperties": {
      "containers": [
        {
          "command": [
            "/bin/sh"
          ],
          "args": [
            "-c",
            "echo hello world"
          ]
        }
      ]
    }
  }
}
EOF
        

$ aws batch submit-job - -cli-input-json file://./submit-job-override.json

ステップ 10: チュートリアルのリソースをクリーンアップする

Amazon EC2 インスタンスが有効になっている間は課金されます。インスタンスを削除して、料金の発生を停止できます。

作成したリソースを削除するには、次の作業を行います。

その他のリソース

チュートリアルが完了したら、次のトピックを試すことができます。

トラブルシューティング

AWS Batch によって起動されたノードが、イメージを保存する Amazon ECR リポジトリ (またはその他の任意のリポジトリ) にアクセスできない場合、ジョブは STARTING の状態のままになる可能性があります。これは、ポッドがイメージをダウンロードして AWS Batch のジョブを実行できないことによります。AWS Batch によって起動されたポッド名をクリックするとエラーメッセージが表示され、問題を確認できます。エラーメッセージは次のようになります。

Failed to pull image "public.ecr.aws/amazonlinux/amazonlinux:2": rpc error: code =
Unknown desc = failed to pull and unpack image
"public.ecr.aws/amazonlinux/amazonlinux:2": failed to resolve reference
"public.ecr.aws/amazonlinux/amazonlinux:2": failed to do request: Head
"https://public.ecr.aws/v2/amazonlinux/amazonlinux/manifests/2": dial tcp: i/o timeout

その他の一般的なトラブルシューティングのシナリオについては、「AWS Batch のトラブルシューティング」を参照してください。ポッドステータスに基づくトラブルシューティングについては、「How do I troubleshoot the pod status in Amazon EKS?」を参照してください。