翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# `StartJobRun` で Spark ジョブを実行する
<a name="job-runs"></a>

このセクションでは、Spark ジョブを実行する環境を整えるための詳細なセットアップ手順と、指定されたパラメータでジョブ実行を送信するためのステップバイステップの手順について説明します。

**Topics**
+ [Amazon EMR on EKS のセットアップ](setting-up.md)
+ [`StartJobRun` でジョブ実行を送信する](emr-eks-jobs-submit.md)
+ [ジョブ送信者分類の使用](emr-eks-job-submitter.md)
+ [Amazon EMR コンテナのデフォルト分類の使用](emr-eks-job-submitter-container-defaults.md)

# Amazon EMR on EKS のセットアップ
<a name="setting-up"></a>

Amazon EMR on EKS のセットアップを行うには、以下のタスクを完了します。Amazon Web Services (AWS) に既にサインアップしていて、Amazon EKS を既に使用している場合、Amazon EMR on EKS を使用する準備はほぼ整っています。既に完了しているタスクはスキップしてください。

**注記**  
また、[Amazon EMR on EKS Workshop](https://emr-on-eks.workshop.aws/amazon-emr-eks-workshop.html) に従って、Amazon EMR on EKS で Spark ジョブを実行するのに必要なすべてのリソースをセットアップすることもできます。このワークショップには、CloudFormation テンプレートを使用して、開始するのに必要なリソースを作成する自動化機能も用意されています。その他のテンプレートとベストプラクティスについては、GitHub の「[EMR Containers Best Practices Guide](https://aws.github.io/aws-emr-containers-best-practices/)」を参照してください。

1. [の最新バージョンをインストールまたは更新する AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)

1. [kubectl と eksctl のセットアップ](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)

1. [Amazon EKS – eksctl の使用開始](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html)

1. [Amazon EMR on EKS のクラスターアクセスを有効にする](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-cluster-access.html)

1. [EKS クラスターの IAM ロールを有効にする](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM-roles.html)

1. [Amazon EMR on EKS へのアクセス許可をユーザーに付与する](setting-up-iam.md)

1. [Amazon EKS クラスターをAmazon EMR に登録する](setting-up-registration.md)

# Amazon EMR on EKS のクラスターアクセスを有効にする
<a name="setting-up-cluster-access"></a>

以下の各セクションでは、クラスターアクセスを有効にする方法をいくつか示します。1 つ目の方法は、Amazon EKS クラスターアクセス管理 (CAM) を使用することによるものです。もう 1 つの方法は、クラスターアクセスを有効にするための手動手順を実施する方法を示すものです。

## EKS アクセスエントリを使用してクラスターアクセスを有効にする (推奨)
<a name="setting-up-cluster-access-cam-integration"></a>

**注記**  
`aws-auth` ConfigMap は非推奨です。Kubernetes API へのアクセスを管理する際は、[アクセスエントリ](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html)を使用することをお勧めします。

Amazon EMR は [Amazon EKS クラスターアクセス管理 (CAM)](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html) と統合されているため、Amazon EKS クラスターの名前空間で Amazon EMR Spark ジョブを実行するために必要な AuthN ポリシーと AuthZ ポリシーの設定を自動化できます。Amazon EKS クラスター名前空間から仮想クラスターを作成すると、Amazon EMR は必要なすべてのアクセス許可を自動的に設定するため、現在のワークフローにその他の手順を追加する必要はありません。

**注記**  
Amazon EMR と Amazon EKS CAM の統合は、新しい Amazon EMR on EKS 仮想クラスターでのみサポートされています。既存の仮想クラスターを移行してこの統合を使用することはできません。

### 前提条件
<a name="setting-up-cluster-access-cam-integration-prereqs"></a>
+ のバージョン 2.15.3 以降が実行されていることを確認します。 AWS CLI
+ Amazon EKS クラスターでは、1.23 以降のバージョンを使用している必要があります。

### セットアップ
<a name="setting-up-cluster-access-cam-integration-setup"></a>

Amazon EMR と Amazon EKS の AccessEntry API オペレーションの統合を設定するには、次の項目を完了していることを確認してください。
+ Amazon EKS クラスターの `authenticationMode` が `API_AND_CONFIG_MAP` に設定されていることを確認します。

  ```
  aws eks describe-cluster --name <eks-cluster-name>
  ```

  まだ設定されていない場合は、`authenticationMode` を `API_AND_CONFIG_MAP` に設定します。

  ```
  aws eks update-cluster-config 
      --name <eks-cluster-name> 
      --access-config authenticationMode=API_AND_CONFIG_MAP
  ```

  認証モードの詳細については、「[クラスター認証モード](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html#authentication-modes)」を参照してください。
+ `CreateVirtualCluster` および `DeleteVirtualCluster` の API オペレーションの実行に使用する [IAM ロール](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-iam.html)にも、次のアクセス許可があることを確認します。

  ```
  {
    "Effect": "Allow",
    "Action": [
      "eks:CreateAccessEntry"
    ],
    "Resource": "arn:<AWS_PARTITION>:eks:<AWS_REGION>:<AWS_ACCOUNT_ID>:cluster/<EKS_CLUSTER_NAME>"
  }, 
  {
    "Effect": "Allow",
    "Action": [
      "eks:DescribeAccessEntry",
      "eks:DeleteAccessEntry",
      "eks:ListAssociatedAccessPolicies",
      "eks:AssociateAccessPolicy",
      "eks:DisassociateAccessPolicy"
    ],
    "Resource": "arn:<AWS_PARTITION>:eks:<AWS_REGION>:<AWS_ACCOUNT_ID>:access-entry/<EKS_CLUSTER_NAME>/role/<AWS_ACCOUNT_ID>/AWSServiceRoleForAmazonEMRContainers/*"
  }
  ```

### 概念と用語
<a name="setting-up-cluster-access-cam-integration-concepts"></a>

以下に示すのは、Amazon EKS CAM に関連する用語と概念のリストです。
+ 仮想クラスター (VC) – Amazon EKS で作成された名前空間の論理表現。これは、Amazon EKS クラスター名前空間への 1:1 リンクです。これを使用して、指定された名前空間内の Amazon EKS クラスターで Amazon EMR ワークロードを実行できます。
+ 名前空間 – 単一の EKS クラスター内のリソースグループを分離するためのメカニズム。
+ アクセスポリシー – EKS クラスター内の IAM ロールにアクセス権とアクションを付与するアクセス許可。
+ アクセスエントリ – ロール arn で作成されたエントリ。アクセスエントリをアクセスポリシーにリンクして、Amazon EKS クラスターに特定のアクセス許可を割り当てることができます。
+ EKS アクセスエントリ統合仮想クラスター – Amazon EKS の[アクセスエントリ API オペレーション](https://docs.aws.amazon.com/eks/latest/APIReference/API_Operations_Amazon_Elastic_Kubernetes_Service.html)を使用して作成された仮想クラスター。

## `aws-auth` を使用してクラスターアクセスを有効にする
<a name="setting-up-cluster-access-aws-auth"></a>

Amazon EMR on EKS がクラスターで特定の名前空間にアクセスできるようにする必要があります。これを行うには、Kubernetes ロールを作成し、そのロールを Kubernetes ユーザーにバインドして、Kubernetes ユーザーをサービスにリンクされたロール [https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/using-service-linked-roles.html](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/using-service-linked-roles.html) にマッピングします。これらのアクションは、IAM ID マッピングコマンドがサービス名として `emr-containers` と共に使用されると、`eksctl` で自動的に行われます。これらの操作は、次のコマンドを使用して簡単に実行できます。

```
eksctl create iamidentitymapping \
    --cluster my_eks_cluster \
    --namespace kubernetes_namespace \
    --service-name "emr-containers"
```

*my\$1eks\$1cluster* は使用する Amazon EKS クラスターの名前に置き換え、*kubernetes\$1namespace* は Amazon EMR ワークロードを実行するために作成された Kubernetes 名前空間に置き換えます。

**重要**  
この機能を使用するには、前のステップである [kubectl と eksctl の設定](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)を使用して最新の eksctl をダウンロードする必要があります。

### Amazon EMR on EKS のクラスターアクセスを有効にするための手動ステップ
<a name="setting-up-cluster-access-manual"></a>

次の手動ステップを使用して、Amazon EMR on EKS のクラスターアクセスを有効にすることもできます。

1. **特定の名前空間に Kubernetes ロールを作成する**

------
#### [ Amazon EKS 1.22 - 1.29 ]

   Amazon EKS 1.22～1.29 で、次のコマンドを実行して特定の名前空間に Kubernetes ロールを作成します。このロールは、Amazon EMR on EKS に必要な RBAC アクセス許可を付与します。

   ```
   namespace=my-namespace
   cat - >>EOF | kubectl apply -f - >>namespace "${namespace}"
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: emr-containers
     namespace: ${namespace}
   rules:
     - apiGroups: [""]
       resources: ["namespaces"]
       verbs: ["get"]
     - apiGroups: [""]
       resources: ["serviceaccounts", "services", "configmaps", "events", "pods", "pods/log"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "deletecollection", "annotate", "patch", "label"]
     - apiGroups: [""]
       resources: ["secrets"]
       verbs: ["create", "patch", "delete", "watch"]
     - apiGroups: ["apps"]
       resources: ["statefulsets", "deployments"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"]
     - apiGroups: ["batch"]
       resources: ["jobs"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"]
     - apiGroups: ["extensions", "networking.k8s.io"]
       resources: ["ingresses"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"]
     - apiGroups: ["rbac.authorization.k8s.io"]
       resources: ["roles", "rolebindings"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "deletecollection", "annotate", "patch", "label"]
     - apiGroups: [""]
       resources: ["persistentvolumeclaims"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete",  "deletecollection", "annotate", "patch", "label"]
   EOF
   ```

------
#### [ Amazon EKS 1.21 and below ]

   Amazon EKS 1.21 以前で、次のコマンドを実行して特定の名前空間に Kubernetes ロールを作成します。このロールは、Amazon EMR on EKS に必要な RBAC アクセス許可を付与します。

   ```
   namespace=my-namespace
   cat - >>EOF | kubectl apply -f - >>namespace "${namespace}"
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: emr-containers
     namespace: ${namespace}
   rules:
     - apiGroups: [""]
       resources: ["namespaces"]
       verbs: ["get"]
     - apiGroups: [""]
       resources: ["serviceaccounts", "services", "configmaps", "events", "pods", "pods/log"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "deletecollection", "annotate", "patch", "label"]
     - apiGroups: [""]
       resources: ["secrets"]
       verbs: ["create", "patch", "delete", "watch"]
     - apiGroups: ["apps"]
       resources: ["statefulsets", "deployments"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"]
     - apiGroups: ["batch"]
       resources: ["jobs"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"]
     - apiGroups: ["extensions"]
       resources: ["ingresses"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "annotate", "patch", "label"]
     - apiGroups: ["rbac.authorization.k8s.io"]
       resources: ["roles", "rolebindings"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "deletecollection", "annotate", "patch", "label"]
     - apiGroups: [""]
       resources: ["persistentvolumeclaims"]
       verbs: ["get", "list", "watch", "describe", "create", "edit", "delete", "deletecollection", "annotate", "patch", "label"]
   EOF
   ```

------

1. **名前空間にスコープが設定された Kubernetes ロールバインディングを作成する**

   次のコマンドを実行して、特定の名前空間に Kubernetes ロールバインディングを作成します。このロールバインディングは、前のステップで作成したロールに定義されたアクセス許可を、`emr-containers` という名前のユーザーに付与します。このユーザーにより、[Amazon EMR on EKS のサービスにリンクされたロール](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/using-service-linked-roles.html)が特定されるため、Amazon EMR on EKS は作成したロールによって定義されているとおりにアクションを実行できます。

   ```
   namespace=my-namespace
   
   cat - <<EOF | kubectl apply -f - --namespace "${namespace}"
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: emr-containers
     namespace: ${namespace}
   subjects:
   - kind: User
     name: emr-containers
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: Role
     name: emr-containers
     apiGroup: rbac.authorization.k8s.io
   EOF
   ```

1. **Kubernetes `aws-auth` 設定マップを更新する**

   次のいずれかのオプションを使用して、Amazon EMR on EKS のサービスにリンクされたロールを、前のステップで Kubernetes ロールにバインドされた `emr-containers` ユーザーにマップできます。

   **オプション 1: `eksctl` を使用する**

   次の `eksctl` コマンドを実行して、Amazon EMR on EKS のサービスにリンクされたロールを `emr-containers` ユーザーにマップします。

   ```
   eksctl create iamidentitymapping \
       --cluster my-cluster-name \
       --arn "arn:aws:iam::my-account-id:role/AWSServiceRoleForAmazonEMRContainers" \
       --username emr-containers
   ```

   **オプション 2: eksctl を使用しない**

   1. 次のコマンドを実行して、テキストエディタで `aws-auth` 設定マップを開きます。

      ```
      kubectl edit -n kube-system configmap/aws-auth
      ```
**注記**  
`Error from server (NotFound): configmaps "aws-auth" not found` というエラーを受け取った場合、「Amazon EKS ユーザーガイド」の[ユーザーロールの追加](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html)の手順を参照して、ストック ConfigMap を適用してください。

   1. Amazon EMR on EKS のサービスにリンクされたロールの詳細を、`data` の下の `ConfigMap` の `mapRoles` セクションに追加します。ファイルに存在しない場合は、このセクションを追加します。データの下で更新された `mapRoles` セクションは、次の例のようになります。

      ```
      apiVersion: v1
      data:
        mapRoles: |
          - rolearn: arn:aws:iam::<your-account-id>:role/AWSServiceRoleForAmazonEMRContainers
            username: emr-containers
          - ... <other previously existing role entries, if there's any>.
      ```

   1. ファイルを保存し、テキストエディタを終了します。

# EKS クラスターの IAM ロールを有効にする
<a name="setting-up-enable-IAM-roles"></a>

以下のトピックでは、IAM ロールを有効にするためのオプションについて詳しく説明します。

**Topics**
+ [オプション 1: EKS クラスターで EKS Pod Identity を有効にする](setting-up-enable-IAM.md)
+ [オプション 2: EKS クラスターでサービスアカウント (IRSA) の IAM ロールを有効にする](setting-up-enable-IAM-service-accounts.md)

# オプション 1: EKS クラスターで EKS Pod Identity を有効にする
<a name="setting-up-enable-IAM"></a>

EKS Pod Identity の関連付けは、Amazon EC2 インスタンスプロファイルから Amazon EC2 インスタンスに認証情報を提供する場合と同じような方法で、アプリケーションの認証情報を管理する機能があります。Amazon EKS Pod Identity は、追加の EKS Auth API と各ノードで実行されるエージェントポッドを使用して、ワークロードに認証情報を提供します。

Amazon EMR on EKS は、StartJobRun 送信モデルの emr-7.3.0 リリース以降、EKS Pod Identity のサポートを開始します。

EKS Pod Identity の詳細については、「[Understand how EKS Pod Identity works](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-how-it-works.html)」を参照してください。

## EKS Pod Identity を使用する理由
<a name="setting-up-enable-IAM-pod-identity-why"></a>

EMR のセットアップの一環として、ジョブ実行ロールは、IAM ロールと特定の名前空間 (EMR 仮想クラスター) のサービスアカウントの間に信頼境界を確立しなければなりません。IRSA では、これは EMR ジョブ実行ロールの信頼ポリシーを更新することで実現されました。ただし、IAM 信頼ポリシーの長さに 4096 文字のハード制限があるので、最大 十二 (12) 個の EKS クラスターで 1 つのジョブ実行 IAM ロールを共有するという制約がありました。

EMR の Pod Identity のサポートにより、IAM ロールとサービスアカウントの信頼境界は、EKS Pod Identity の関連付け APIs を通じて EKS チームによって管理されるようになりました。

**注記**  
EKS Pod Identity のセキュリティ境界は、ポッドレベルではなく、サービスアカウントレベルのままです。

## Pod Identity に関する考慮事項
<a name="setting-up-enable-IAM-pod-identity-consider"></a>

Pod Identity Limitations の詳細については、「[EKS Pod Identity considerations](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html#pod-id-considerations)」を参照してください。

## EKS クラスターで EKS Pod Identity を準備する
<a name="setting-up-enable-IAM-pod-eks-cluster"></a>

### 必要なアクセス許可が NodeInstanceRole に存在するかどうかを確認します
<a name="setting-up-enable-IAM-pod-eks-cluster-permission"></a>

ノードロール `NodeInstanceRole` には、エージェントが EKS Auth API で `AssumeRoleForPodIdentity` アクションを実行する権限があります。AmazonEKS ユーザーガイドで定義されている [AmazonEKSWorkerNodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/security-iam-awsmanpol.html#security-iam-awsmanpol-amazoneksworkernodepolicy) に以下を追加するか、カスタムポリシーを使用できます。

EKS クラスターが **0.181.0** 以降の eksctl バージョンで作成された場合、必要な `AssumeRoleForPodIdentity` アクセス許可を含む AmazonEKSWorkerNodePolicy がノードロールに自動的にアタッチされます。アクセス許可がない場合は、Pod Identity のロールの引き受けを許可する次のアクセス許可を AmazonEKSWorkerNodePolicy に手動で追加します。このアクセス許可は、EKS Pod Identity エージェントがポッドの認証情報を取得するために必要です。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "eks-auth:AssumeRoleForPodIdentity"
      ],
      "Resource": [
        "*"
      ],
      "Sid": "AllowEKSAUTHAssumeroleforpodidentity"
    }
  ]
}
```

------

### EKS Pod Identity エージェントアドオンを作成する
<a name="setting-up-enable-IAM-pod-eks-cluster-agent"></a>

以下のコマンドを使用して、最新バージョンの EKS Pod Identity Agent アドオンを作成します:

```
aws eks create-addon --cluster-name cluster-name --addon-name eks-pod-identity-agent

kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'
```

Amazon EKS コンソールから EKS Pod Identity Agent アドオンを作成するには、以下の手順に従います:

1. [Amazon EKS コンソール](https://console.aws.amazon.com/eks/home#/clusters)で Amazon EKS コンソールを開きます。

1. 左のナビゲーションペインで、**[クラスター]** を選択し、次にアドオンを設定するEKS Pod Identity エージェントを選択します。

1. **[アドオン]** タブを選択してください。

1. **[その他のアドオンを入手]** を選択してください。

1. EKS Pod Identity のアドオンボックスの右上にあるボックスを選択し、**[次へ]** を選択します。

1. **[選択したアドオン設定を構成する]** ページの **[バージョン]** ドロップダウンリストで任意のバージョンを選択します。

1. (オプション) **[オプションの設定]** を展開して追加の設定を入力します。例えば、代替のコンテナイメージの場所と `ImagePullSecrets` を指定できます。許可されたキーのある JSON スキーマは、**[アドオン設定スキーマ]** に表示されます。

   設定キーと値を **[設定値]** に入力します。

1. [**次へ**] を選択します。

1. エージェントポッドが CLI を介してクラスター上で実行されていることを確認してください。

   `kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'`

出力例は以下のとおりです:

```
NAME                              READY   STATUS    RESTARTS      AGE
eks-pod-identity-agent-gmqp7      1/1     Running   1 (24h ago)   24h
eks-pod-identity-agent-prnsh      1/1     Running   1 (24h ago)   24h
```

これにより、`kube-system` 名前空間に新しい DaemonSet が設定されます。次に、EKS ノード上で実行する Amazon EKS Pod Identity エージェントは [AssumeRoleForPodIdentity](https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html) アクションを使用して EKS Auth API から一時的な認証情報を取得します。これらの認証情報は、コンテナ内で実行する AWS SDKs で使用できます。

詳細については、パブリックドキュメントの前提条件[「Amazon EKS Pod Identity エージェントのセットアップ](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html)」を参照してください。

## ジョブ実行ロールを作成する
<a name="setting-up-enable-IAM-pod-create-job-role"></a>

### EKS Pod Identity を許可するジョブ実行ロールを作成または更新する
<a name="setting-up-enable-IAM-pod-create-job-role-update"></a>

Amazon EMR on EKS でワークロードを実行するには、IAM ロールを作成する必要があります。このドキュメントでは、このロールをジョブ実行ロールと呼びます。IAM ロールの作成方法の詳細については、「IAM ユーザーガイド」の「I[Creating IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html)」を参照してください。

さらに、ジョブ実行ロールに必要なアクセス許可を指定する IAM ポリシーを作成し、このポリシーをロールにアタッチして EKS Pod Identity を有効にしなければなりません。

例えば、次のジョブ実行ロールがあるとします。詳細については、「[Create a job execution role](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/creating-job-execution-role.html)」を参照してください。

```
arn:aws:iam::111122223333:role/PodIdentityJobExecutionRole
```

**重要**  
Amazon EMR on EKS は、ジョブ実行ロール名に基づいて Kubernetes サービスアカウントを自動的に作成します。`cluster_name`、`pod_name` および `service_account_name` の組み合わせが長さ制限を超えるとジョブが失敗する可能性があるので、ロール名が長すぎないようにしてください。

**ジョブ実行ロール設定** – ジョブ実行ロールが EKS Pod Identity の以下の信頼アクセス許可で作成されていることを確認します。既存のジョブ実行ロールを更新するには、次の EKS サービスプリンシパルを信頼ポリシーの追加アクセス許可として信頼するように設定します。この信頼アクセス許可は、既存の IRSA 信頼ポリシーと共存できます。

```
cat >trust-relationship.json <<EOF
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
            "Effect": "Allow",
            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ]
        }
    ]
}
EOF
```

**ユーザーアクセス許可**: ユーザーには、`StartJobRun` API コールを実行したりジョブを送信したりするための `iam:PassRole` アクセス許可が必要です。このアクセス許可により、ユーザーはジョブ実行ロールを EMR on EKS に渡すことができます。ジョブ管理者には、デフォルトでアクセス許可が必要です。

ユーザーに必要なアクセス許可を以下に示します:

```
{
    "Effect": "Allow",
    "Action": "iam:PassRole",
    "Resource": "arn:aws:iam::111122223333:role/PodIdentityJobExecutionRole",
    "Condition": {
        "StringEquals": {
            "iam:PassedToService": "pods.eks.amazonaws.com"
        }
    }
}
```

特定の EKS クラスターへのユーザーアクセスをさらに制限するには、AssociatedResourceArn 属性フィルターを IAM ポリシーに追加します。これにより、ロールの引き受けが承認された EKS クラスターに制限され、リソースレベルのセキュリティコントロールが強化されます。

```
"Condition": {
        "ArnLike": {
            "iam:AssociatedResourceARN": [
                "arn:aws:eks:us-west-2:111122223333:cluster/*"
            ]
        }
```

## EKS Pod Identity の関連付けを設定する
<a name="setting-up-enable-IAM-pod-identity-asociations"></a>

### 前提条件
<a name="setting-up-enable-IAM-pod-identity-asociations-prereq"></a>

EKS 管理者ユーザーなどの Pod Identity の関連付けを作成する IAM Identity に、 アクセス許可 `eks:CreatePodIdentityAssociation` と `iam:PassRole` があることを確認します。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "eks:CreatePodIdentityAssociation"
      ],
      "Resource": [
        "arn:aws:eks:*:*:cluster/*"
      ],
      "Sid": "AllowEKSCreatepodidentityassociation"
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:PassRole"
      ],
      "Resource": [
        "arn:aws:iam::*:role/*"
      ],
      "Condition": {
        "StringEquals": {
          "iam:PassedToService": "pods.eks.amazonaws.com"
        }
      },
      "Sid": "AllowIAMPassrole"
    }
  ]
}
```

------

### ロールと EMR サービスアカウントの関連付けを作成する
<a name="setting-up-enable-IAM-pod-identity-asociations-emr-service"></a>

------
#### [ Create EMR role associations through the AWS CLI ]

Kubernetes 名前空間にジョブを送信する場合、管理者はジョブ実行ロールと EMR マネージドサービスアカウントの ID との間に関連付けを作成しなければなりません。EMR マネージドサービスアカウントは、ジョブの送信時に自動的に作成され、ジョブが送信される名前空間にスコープ設定されます。

 AWS CLI (バージョン 2.24.0 以上) では、次のコマンドを実行して、ポッド ID とのロールの関連付けを作成します。

以下のコマンドを実行して、Pod Identity の関連付けを作成します:

```
aws emr-containers create-role-associations \
        --cluster-name mycluster \
        --namespace mynamespace \
        --role-name JobExecutionRoleIRSAv2
```

注記:
+ 各クラスターの関連付けの上限は 1,000 です。各ジョブ実行ロール - 名前空間マッピングには、ジョブ送信者、ドライバー、エグゼキュターポッドに 3 つの関連付けが必要です。
+ クラスターと同じ AWS アカウントにあるロールのみを関連付けることができます。別のアカウントから、EKS Pod Identity が使用するように設定したこのアカウントのロールに、アクセスを委任できます。アクセスと の委任に関するチュートリアルについては`AssumeRole`、[「IAM チュートリアル: IAM ロールを使用して AWS アカウント間でアクセスを委任](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)する」を参照してください。

------
#### [ Create EMR role associations through Amazon EKS ]

EMR は、ジョブの送信時に特定の命名パターンを持つサービスアカウントを作成します。手動関連付けを行うか、このワークフローを AWS SDK と統合するには、次の手順に従います。

サービスアカウント名の作成:

```
emr-containers-sa-spark-%(SPARK_ROLE)s-%(AWS_ACCOUNT_ID)s-%(BASE36_ENCODED_ROLE_NAME)s
```

以下の例では、サンプルジョブ実行ロール JobExecutionRoleIRSAv2 のロール関連付けを作成します。

**ロールの関連付けの例:**

```
RoleName: JobExecutionRoleIRSAv2
Base36EncodingOfRoleName: 2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe
```

**サンプル CLI コマンド:**

```
# setup for the client service account (used by job runner pod)
# emr-containers-sa-spark-client-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe
aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-client-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe

# driver service account
# emr-containers-sa-spark-driver-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe        
aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-driver-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe

# executor service account
# emr-containers-sa-spark-executor-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe
aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-executor-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe
```

------

EKS Pod Identity に必要なすべてのステップを完了したら、IRSA セットアップの以下のステップをスキップできます:
+ [EKS クラスターでサービスアカウント (IRSA) の IAM ロールを有効にする](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM.html)
+ [ジョブ実行ロールを作成する](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/creating-job-execution-role.html)
+ [ジョブ実行ロールの信頼ポリシーを更新する](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html)

次のステップに直接スキップできます: [Amazon EMR on EKS へのアクセス権をユーザーに付与する](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-iam.html)

## ロールの関連付けを削除する
<a name="setting-up-enable-IAM-pod-identity-asociations-delete-associations"></a>

仮想クラスターまたはジョブ実行ロールを削除し、そのサービスアカウントに EMR へのアクセスを許可しない場合は、そのロールの関連付けを削除しなければなりません。これは、EKS が存在しないリソース (名前空間とサービスアカウント) との関連付けを許可するためです。Amazon EMR on EKS では、名前空間が削除された場合やロールが使用されなくなった場合は、関連付けを削除して、他の関連付けのスペースを解放することをお勧めします。

**注記**  
EKS には作成できる関連付けの数に制限があるため (ソフト制限: クラスターあたり 1,000 個の関連付け)、関連付けが残ると、それらを削除しない場合にスケーリング機能に影響する可能性があります。特定の名前空間に Pod Identity の関連付けを一覧表示して、クリーンアップする必要がある既存の関連付けがあるかどうかを確認できます:

```
aws eks list-pod-identity-associations --cluster-name mycluster --namespace mynamespace
```

 AWS CLI (バージョン 2.24.0 以降) では、次の emr-containers コマンドを実行して EMR のロールの関連付けを削除します。

```
aws emr-containers delete-role-associations \
        --cluster-name mycluster \
        --namespace mynamespace \
        --role-name JobExecutionRoleIRSAv2
```

## 既存の IRSA を Pod Identity に自動的に移行する
<a name="setting-up-enable-IAM-pod-identity-auto-migrate"></a>

ツール eksctl を使用して、サービスアカウントの既存の IAM ロール (IRSA) を Pod Identity の関連付けに移行できます:

```
eksctl utils migrate-to-pod-identity \
    --cluster mycluster \
    --remove-oidc-provider-trust-relationship \
    --approve
```

`--approve` フラグなしでコマンドを実行することにより、移行ステップを反映した計画のみが出力され、実際の移行は行われません。

## トラブルシューティング
<a name="setting-up-enable-IAM-pod-identity-troubleshooting"></a>

### ジョブが NoClassDefinitionFound または ClassNotFound 認証情報プロバイダーの例外で失敗したか、認証情報プロバイダーを取得できませんでした。
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-no-class"></a>

EKS Pod Identity は、コンテナ認証情報プロバイダーを使用して必要な認証情報を取得します。カスタム認証情報プロバイダーを指定した場合は、正しく動作していることを確認します。または、EKS Pod Identity をサポートする正しい AWS SDK バージョンを使用していることを確認してください。詳細については、「[Amazon EKS の使用を開始する](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)」を参照してください。

### ジョブが失敗し、eks-pod-identity-agent ログに「Failed to Retrieve Credentials due to [x] Size Limit」というエラーが表示されました。
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-creds"></a>

EMR on EKS は、ジョブ実行ロール名に基づいて Kubernetes サービスアカウントを作成します。ロール名が長すぎると、`cluster_name`、`pod_name`、`service_account_name` の組み合わせが長さ制限を超えているため、EKS Auth は認証情報の取得に失敗します。どのコンポーネントが最もスペースを占有しているかを特定し、それに応じてサイズを調整します。

### ジョブが失敗し、eks-pod-identity ログに「認証情報 xxx の取得に失敗しました」というエラーが表示されました。
<a name="setting-up-enable-IAM-pod-identity-troubleshooting-creds-error"></a>

この問題の考えられる原因の 1 つは、クラスターに PrivateLink を正しく設定せずに EKS クラスターがプライベートサブネットの下に設定されていることです。クラスターがプライベートネットワークにあるかどうかを確認し、問題に対処するように AWS PrivateLink を設定します。詳細な手順については、「[Amazon EKS の使用を開始する](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)」を参照してください。

# オプション 2: EKS クラスターでサービスアカウント (IRSA) の IAM ロールを有効にする
<a name="setting-up-enable-IAM-service-accounts"></a>

サービスアカウントの IAM ロール機能は、Amazon EKS バージョン 1.14 以降、および 2019 年 9 月 3 日以降にバージョン1.13 に更新された EKS クラスターで利用できます。この機能を使用するために、既存の EKS クラスターをバージョン 1.14 以降に更新できます。詳細については、「[Amazon EKS クラスターの Kubernetes バージョンの更新](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html)」を参照してください。

クラスターがサービスアカウントの IAM ロールをサポートしている場合、[OpenID Connect](https://openid.net/connect/) 発行者 URL が関連付けられます。この URL は Amazon EKS コンソールで表示することも、次の AWS CLI コマンドを使用して取得することもできます。

**重要**  
このコマンドから適切な出力を受け取るには AWS CLI 、 の最新バージョンを使用する必要があります。

```
aws eks describe-cluster --name cluster_name --query "cluster.identity.oidc.issuer" --output text
```

予想される出力は次のようになります。

```
https://oidc.eks.<region-code>.amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E
```

クラスターでサービスアカウントの IAM ロールを使用するには、[eksctl](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html#create-oidc-eksctl) または [AWS マネジメントコンソール](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html#create-oidc-console) のいずれかを使用して OIDC ID プロバイダーを作成する必要があります。

## `eksctl` を使用してクラスターの IAM OIDC ID プロバイダーを作成するには
<a name="setting-up-OIDC-eksctl"></a>

以下のコマンドを使用して、`eksctl` のバージョンを確認します。この手順では、`eksctl` をインストール済みで、お使いの `eksctl` のバージョンが 0.32.0 以上であることを前提としています。

```
eksctl version
```

eksctl のインストールまたはアップグレードの詳細については、「[eksctl のインストールまたはアップグレード](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html#installing-eksctl)」を参照してください。

次のコマンドを使用して、クラスターの OIDC ID プロバイダーを作成します。*cluster\$1name* は、独自の値に置き換えてください。

```
eksctl utils associate-iam-oidc-provider --cluster cluster_name --approve
```

## を使用してクラスターの IAM OIDC ID プロバイダーを作成するには AWS マネジメントコンソール
<a name="setting-up-OIDC-console"></a>

クラスターの Amazon EKS コンソールの説明から OIDC 発行者 URL を取得するか、次の AWS CLI コマンドを使用します。

次のコマンドを使って、 AWS CLIから OIDC 発行者 URL を取得します。

```
aws eks describe-cluster --name <cluster_name> --query "cluster.identity.oidc.issuer" --output text
```

次の手順に従って、Amazon EKS コンソールから OIDC 発行者 URL を取得します。

1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。

1. ナビゲーションペインで、**[ID プロバイダー]** を選択し、**[プロバイダーの作成]** をクリックします。

   1. [**プロバイダーのタイプ**] で [**Choose a provider type**] を選択してから、[**OpenID Connect**] を選択します。

   1. **Provider URL** に、クラスターの OIDC 発行者 URL を貼り付けます。

   1. [対象者] に、「sts.amazonaws.com」と入力し、**[次のステップ]** を選択します。

1. プロバイダー情報が正しいことを確認し、[**作成**] を選択して ID プロバイダーを作成します。

# ジョブ実行ロールを作成する
<a name="creating-job-execution-role"></a>

Amazon EMR on EKS でワークロードを実行するには、IAM ロールを作成する必要があります。このドキュメントでは、このロールを*ジョブ実行ロール*と呼びます。IAM ロールの作成方法の詳細については、「IAM ユーザーガイド」の「[IAM ロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html)」を参照してください。

また、ジョブ実行ロールの権限を指定する IAM ポリシーを作成し、その IAM ポリシーをジョブ実行ロールにアタッチする必要があります。

ジョブ実行ロールの次のポリシーでは、リソースターゲット、Amazon S3、および CloudWatch へのアクセスが許可されます。これらのアクセス許可は、ジョブとアクセスログを監視するために必要です。 AWS CLIを使用して同じプロセスを実行するには: 

ジョブ実行用の IAM ロールを作成する: EMR がジョブ実行に使用するロールを作成します。これは、EMR ジョブが EKS で実行する時に引き受けるロールです。

```
cat <<EoF > ~/environment/emr-trust-policy.json
 {
   "Version": "2012-10-17",		 	 	 
   "Statement": [
     {
       "Effect": "Allow",
       "Principal": {
         "Service": "elasticmapreduce.amazonaws.com"
       },
       "Action": "sts:AssumeRole"
     }
   ]
 }
 EoF
  
 aws iam create-role --role-name EMRContainers-JobExecutionRole --assume-role-policy-document file://~/environment/emr-trust-policy.json
```

次に、ロールに必要な IAM ポリシーをアタッチして、s3 と cloudwatch にログを書き込むことができるようにしなければなりません。

```
cat <<EoF > ~/environment/EMRContainers-JobExecutionRole.json
 {
     "Version": "2012-10-17",		 	 	 
     "Statement": [
         {
             "Effect": "Allow",
             "Action": [
                 "s3:PutObject",
                 "s3:GetObject",
                 "s3:ListBucket"
             ],
             "Resource": "arn:aws:s3:::amzn-s3-demo-bucket"
         },
         {
             "Effect": "Allow",
             "Action": [
                 "logs:PutLogEvents",
                 "logs:CreateLogStream",
               "logs:DescribeLogGroups",
                 "logs:DescribeLogStreams"
             ],
             "Resource": [
                 "arn:aws:logs:*:*:*"
             ]
         }
     ]
 } 
 EoF
 aws iam put-role-policy --role-name EMRContainers-JobExecutionRole --policy-name EMR-Containers-Job-Execution --policy-document file://~/environment/EMRContainers-JobExecutionRole.json
```

**注記**  
アクセス権限は、ジョブ実行ロール内のすべての S3 オブジェクトに付与するのではなく、適切にスコープする必要があります。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::amzn-s3-demo-bucket"
      ],
      "Sid": "AllowS3Putobject"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:PutLogEvents",
        "logs:CreateLogStream",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Resource": [
        "arn:aws:logs:*:*:*"
      ],
      "Sid": "AllowLOGSPutlogevents"
    }
  ]
}
```

------

詳細については、[ジョブ実行ロールの使用](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/iam-execution-role.html)、[S3ログ使用のためのジョブ実行の構成](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-s3)、および [CloudWatchログ使用のためのジョブ実行の構成） を参照してください](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-cloudwatch)。

# ジョブ実行ロールの信頼ポリシーを更新する
<a name="setting-up-trust-policy"></a>

サービスアカウントの IAM ロール (IRSA) を使用して Kubernetes 名前空間上でジョブを実行する場合、管理者はジョブ実行ロールと EMR マネージドサービスアカウントの ID との間に信頼関係を作成する必要があります。信頼関係は、ジョブ実行ロールの信頼ポリシーを更新することによって作成できます。EMR マネージドサービスアカウントは、ジョブの送信時に自動的に作成され、ジョブが送信される名前空間にスコープ設定されます。

信頼ポリシーを更新するには、次のコマンドを実行します。

```
 aws emr-containers update-role-trust-policy \
       --cluster-name cluster \
       --namespace namespace \
       --role-name iam_role_name_for_job_execution
```

詳細については、「[Amazon EMR on EKS でのジョブ実行ロールの使用](iam-execution-role.md)」を参照してください。

**重要**  
上記のコマンドを実行するオペレータには、`eks:DescribeCluster`、`iam:GetRole`、`iam:UpdateAssumeRolePolicy` のアクセス許可が必要です。

# Amazon EMR on EKS へのアクセス許可をユーザーに付与する
<a name="setting-up-iam"></a>

Amazon EMR on EKS で実行するアクションについては、そのアクションに対応する IAM アクセス許可が必要です。Amazon EMR on EKS アクションを実行し、使用する IAM ユーザーまたはロールにポリシーをアタッチできる IAM ポリシーを作成する必要があります。

このトピックでは、新しいポリシーを作成し、ユーザーにアタッチする手順について説明します。Amazon EMR on EKS 環境を設定するために必要な基本的なアクセス許可についても説明します。ビジネスニーズに基づいて、可能な限り、特定のリソースに対するアクセス許可を絞り込むことをお勧めします。

## 新しい IAM ポリシーを作成して、IAM コンソールでユーザーにアタッチする
<a name="setting-up-iam-console"></a>

**新規 IAM ポリシーを作成する**

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを開きます。

1. IAM コンソールの左側のナビゲーションペインで **[ポリシー]** を選択します。

1. **[ポリシー]** ページで、**[ポリシーの作成]** を選択します。

1. **[Create Policy]** (ポリシーの作成) ウィンドウで、**[Edit JSON]** (JSON の編集) タブに移動します。この手順の後、例に示されているように、1 つ以上の JSON ステートメントを含むポリシードキュメントを作成します。次に、**[ポリシーの確認]** を選択します。

1. [**Review Policy**] (ポリシーの確認) 画面で、[**Policy Name**] (ポリシー名)に `AmazonEMROnEKSPolicy` (など)を入力します。任意で説明を入力し、**[ポリシーの作成]** を選択します。

**ポリシーをユーザーまたはロールにアタッチする**

1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソールを開きます。

1. ナビゲーションペインで、**ポリシー** を選択してください。

1. ポリシーのリストで、前のセクションで作成したポリシーの横にあるチェックボックスを選択します。[**Filter (フィルター)**] メニューと検索ボックスを使用して、ポリシーのリストをフィルタリングできます。

1. [**Policy actions**] を選択して、[**Attach**] を選択します。

1. ポリシーをアタッチするユーザーまたはロールを選択します。[**Filter**] メニューと検索ボックスを使用して、プリンシパルエンティティのリストをフィルタリングできます。ポリシーをアタッチするユーザーまたはロールを選択した後、**[Attach policy]** (ポリシーのアタッチ) を選択します。

## 仮想クラスターを管理するためのアクセス許可
<a name="permissions-virtual-cluster"></a>

 AWS アカウントの仮想クラスターを管理するには、次のアクセス許可を持つ IAM ポリシーを作成します。これらのアクセス許可により、 AWS アカウントで仮想クラスターを作成、一覧表示、記述、削除できます。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "*"
      ],
      "Condition": {
        "StringLike": {
          "iam:AWSServiceName": "emr-containers.amazonaws.com"
        }
      },
      "Sid": "AllowIAMCreateservicelinkedrole"
    },
    {
      "Effect": "Allow",
      "Action": [
        "emr-containers:CreateVirtualCluster",
        "emr-containers:ListVirtualClusters",
        "emr-containers:DescribeVirtualCluster",
        "emr-containers:DeleteVirtualCluster"
      ],
      "Resource": [
        "*"
      ],
      "Sid": "AllowEMRCONTAINERSCreatevirtualcluster"
    }
  ]
}
```

------

Amazon EMR は Amazon EKS クラスターアクセス管理 (CAM) と統合されているため、Amazon EKS クラスターの名前空間で Amazon EMR Spark ジョブを実行するために必要な AuthN ポリシーと AuthZ ポリシーの設定を自動化できます。これを行うには、次のアクセス許可が必要です。

```
{
  "Effect": "Allow",
  "Action": [
    "eks:CreateAccessEntry"
  ],
  "Resource": "arn:<AWS_PARTITION>:eks:<AWS_REGION>:<AWS_ACCOUNT_ID>:cluster/<EKS_CLUSTER_NAME>"
}, 
{
  "Effect": "Allow",
  "Action": [
    "eks:DescribeAccessEntry",
    "eks:DeleteAccessEntry",
    "eks:ListAssociatedAccessPolicies",
    "eks:AssociateAccessPolicy",
    "eks:DisassociateAccessPolicy"
  ],
  "Resource": "arn:<AWS_PARTITION>:eks:<AWS_REGION>:<AWS_ACCOUNT_ID>:access-entry/<EKS_CLUSTER_NAME>/role/<AWS_ACCOUNT_ID>/AWSServiceRoleForAmazonEMRContainers/*"
}
```

詳細については、[「Automate enabling cluster access for Amazon EMR on EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-cluster-access.html#setting-up-cluster-access-cam-integration)」を参照してください。

 AWS オペレーション`CreateVirtualCluster`がアカウントから初めて呼び出されると、Amazon EMR on EKS のサービスにリンクされたロールを作成するための`CreateServiceLinkedRole`アクセス許可も必要です。詳細については、「[Amazon EMR on EKS でのサービスにリンクされたロールの使用](using-service-linked-roles.md)」を参照してください。

## ジョブを送信するためのアクセス許可
<a name="permissions-submitting-jobs"></a>

 AWS アカウントの仮想クラスターでジョブを送信するには、次のアクセス許可を持つ IAM ポリシーを作成します。これらのアクセス許可により、アカウント内のすべての仮想クラスターに対して、ジョブ実行の開始、一覧表示、説明、およびキャンセルを行えるようになります。仮想クラスターを一覧表示または記述するアクセス許可を追加することを検討する必要があります。これにより、ジョブを送信する前に仮想クラスターの状態を確認できます。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "emr-containers:StartJobRun",
        "emr-containers:ListJobRuns",
        "emr-containers:DescribeJobRun",
        "emr-containers:CancelJobRun"
      ],
      "Resource": [
        "*"
      ],
      "Sid": "AllowEMRCONTAINERSStartjobrun"
    }
  ]
}
```

------

## デバッグとモニタリングを行うためのアクセス許可
<a name="permissions-debugging-monitoring"></a>

Amazon S3 および CloudWatch にプッシュされたログにアクセスしたり、Amazon EMR コンソールでアプリケーションイベントログを表示したりするには、以下のアクセス許可を持つ IAM ポリシーを作成します。ビジネスニーズに基づいて、可能な限り、特定のリソースに対するアクセス許可を絞り込むことをお勧めします。

**重要**  
Amazon S3 バケットを作成していない場合は、`s3:CreateBucket` アクセス許可をポリシーステートメントに追加する必要があります。ロググループを作成していない場合は、`logs:CreateLogGroup` をポリシーステートメントに追加する必要があります。

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "emr-containers:DescribeJobRun",
        "elasticmapreduce:CreatePersistentAppUI",
        "elasticmapreduce:DescribePersistentAppUI",
        "elasticmapreduce:GetPersistentAppUIPresignedURL"
      ],
      "Resource": [
        "*"
      ],
      "Sid": "AllowEMRCONTAINERSDescribejobrun"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "*"
      ],
      "Sid": "AllowS3Getobject"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:Get*",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Resource": [
        "*"
      ],
      "Sid": "AllowLOGSGet"
    }
  ]
}
```

------

Amazon S3 および CloudWatch にログをプッシュするようにジョブ実行を設定する方法の詳細については、[S3ログ使用のための実行の構成）および](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-s3) [CloudWatchログ使用のためのジョブ実行の構成） を参照してください](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-cloudwatch)。

# Amazon EKS クラスターをAmazon EMR に登録する
<a name="setting-up-registration"></a>

ワークロードを実行するように Amazon EMR on EKS をセットアップするために必要な最後の手順は、クラスターの登録です。

次のコマンドを使用して、前の手順で設定した Amazon EKS クラスターと名前空間の名前を指定して仮想クラスターを作成します。

**注記**  
各仮想クラスターには、EKS クラスター全体で一意の名前を付ける必要があります。同じ名前の仮想クラスターが 2 つあると、デプロイプロセスは失敗します。これは、その 2 つの仮想クラスターがそれぞれ異なる EKS クラスターに属している場合でも同じです。

```
aws emr-containers create-virtual-cluster \
--name virtual_cluster_name \
--container-provider '{
    "id": "cluster_name",
    "type": "EKS",
    "info": {
        "eksInfo": {
            "namespace": "namespace_name"
        }
    }
}'
```

または、仮想クラスターに必要なパラメータを含む JSON ファイルを作成し、JSON ファイルへのパスを指定して `create-virtual-cluster` コマンドを実行することもできます。詳細については、「[仮想クラスターの管理](virtual-cluster.md)」を参照してください。

**注記**  
仮想クラスターが正常に作成されたことを確認するには、`list-virtual-clusters` オペレーションを使用するか、Amazon EMR コンソールで **Virtual Clusters** ページに移動して、仮想クラスターのステータスを確認します。

# `StartJobRun` でジョブ実行を送信する
<a name="emr-eks-jobs-submit"></a>

**指定したパラメータを持つ JSON ファイルを使用してジョブ実行を送信するには**

1. `start-job-run-request.json` ファイルを作成し、次の JSON ファイルの例に示すように、ジョブ実行に必要なパラメータを指定します。パラメータの詳細については、「 」を参照してください[ジョブ実行を構成するためのオプション](emr-eks-jobs-CLI.md#emr-eks-jobs-parameters)

   ```
   {
     "name": "myjob", 
     "virtualClusterId": "123456",  
     "executionRoleArn": "iam_role_name_for_job_execution", 
     "releaseLabel": "emr-6.2.0-latest", 
     "jobDriver": {
       "sparkSubmitJobDriver": {
         "entryPoint": "entryPoint_location",
         "entryPointArguments": ["argument1", "argument2", ...],  
          "sparkSubmitParameters": "--class <main_class> --conf spark.executor.instances=2 --conf spark.executor.memory=2G --conf spark.executor.cores=2 --conf spark.driver.cores=1"
       }
     }, 
     "configurationOverrides": {
       "applicationConfiguration": [
         {
           "classification": "spark-defaults", 
           "properties": {
             "spark.driver.memory":"2G"
            }
         }
       ], 
       "monitoringConfiguration": {
         "persistentAppUI": "ENABLED", 
         "cloudWatchMonitoringConfiguration": {
           "logGroupName": "my_log_group", 
           "logStreamNamePrefix": "log_stream_prefix"
         }, 
         "s3MonitoringConfiguration": {
           "logUri": "s3://my_s3_log_location"
         }
       }
     }
   }
   ```

1. ローカルに保存されている `start-job-run-request.json` ファイルへのパスを指定して、`start-job-run` コマンドを使用します。

   ```
   aws emr-containers start-job-run \
   --cli-input-json file://./start-job-run-request.json
   ```

**`start-job-run` コマンドを使用してジョブ実行を開始するには**

1. 次の例に示すように、`StartJobRun` コマンドで指定したすべてのパラメータを指定します。

   ```
   aws emr-containers start-job-run \
   --virtual-cluster-id 123456 \
   --name myjob \
   --execution-role-arn execution-role-arn \
   --release-label emr-6.2.0-latest \
   --job-driver '{"sparkSubmitJobDriver": {"entryPoint": "entryPoint_location", "entryPointArguments": ["argument1", "argument2", ...], "sparkSubmitParameters": "--class <main_class> --conf spark.executor.instances=2 --conf spark.executor.memory=2G --conf spark.executor.cores=2 --conf spark.driver.cores=1"}}' \
   --configuration-overrides '{"applicationConfiguration": [{"classification": "spark-defaults", "properties": {"spark.driver.memory": "2G"}}], "monitoringConfiguration": {"cloudWatchMonitoringConfiguration": {"logGroupName": "log_group_name", "logStreamNamePrefix": "log_stream_prefix"}, "persistentAppUI":"ENABLED",  "s3MonitoringConfiguration": {"logUri": "s3://my_s3_log_location" }}}'
   ```

1. Spark SQL の場合、以下の例に示すように、`StartJobRun` コマンドで指定したすべてのパラメータを指定します。

   ```
   aws emr-containers start-job-run \
   --virtual-cluster-id 123456 \
   --name myjob \
   --execution-role-arn execution-role-arn \
   --release-label emr-6.7.0-latest \
   --job-driver '{"sparkSqlJobDriver": {"entryPoint": "entryPoint_location", "sparkSqlParameters": "--conf spark.executor.instances=2 --conf spark.executor.memory=2G --conf spark.executor.cores=2 --conf spark.driver.cores=1"}}' \
   --configuration-overrides '{"applicationConfiguration": [{"classification": "spark-defaults", "properties": {"spark.driver.memory": "2G"}}], "monitoringConfiguration": {"cloudWatchMonitoringConfiguration": {"logGroupName": "log_group_name", "logStreamNamePrefix": "log_stream_prefix"}, "persistentAppUI":"ENABLED",  "s3MonitoringConfiguration": {"logUri": "s3://my_s3_log_location" }}}'
   ```

# ジョブ送信者分類の使用
<a name="emr-eks-job-submitter"></a>

## 概要:
<a name="emr-eks-job-submitter-overview"></a>

Amazon EMR on EKS `StartJobRun` リクエストは、Spark ドライバーを生成するジョブ送信者ポッド (job-runner ポッドとも呼ばれます) を作成します。`emr-job-submitter` 分類を使用して、ノードセレクタの設定、許容範囲の追加、ログ記録のカスタマイズ、ジョブ送信者ポッドへのその他の変更を行うことができます。

`emr-job-submitter` 分類では以下の設定が可能です:

** `jobsubmitter.node.selector.[selectorKey]` **  
キー *selectorKey* と値を設定値として、ジョブ送信者ポッドのノードセレクタに追加します。たとえば、 ` jobsubmitter.node.selector.identifier`を に設定でき`myIdentifier`、ジョブ送信者ポッドにはキー`identifier`と値 を持つノードセレクタがあります`myIdentifier`。これは、ジョブ送信者ポッドを配置できるノードを指定するために使用できます。複数のノードセレクターキーを追加するには、このプレフィックスを使用して複数の設定を設定します。

** `jobsubmitter.label.[labelKey]` **  
キー *labelKey* と値を設定値として、ジョブ送信者ポッドのラベルに追加します。複数のラベルを追加するには、このプレフィックスを使用して複数の設定を行います。

** `jobsubmitter.annotation.[annotationKey]` **  
キー *annotationKey* と値を設定値として、ジョブ送信者ポッドの注釈に追加します。複数の注釈を追加するには、このプレフィックスを使用して複数の設定を行います。

** `jobsubmitter.node.toleration.[tolerationKey]` **  
ジョブ送信者ポッドに[許容範囲](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)を追加します。デフォルトでは、ポッドに許容値は追加されません。Toleration のキーは *tolerationKey* になり、 Toleration の値は設定値になります。設定値が空でない文字列に設定されている場合、演算子は になります`Equals`。設定値が に設定されている場合`""`、演算子は になります`Exists`。

** `jobsubmitter.node.toleration.[tolerationKey].[effect]` **  
プレフィックス *tolerationKey* に許容効果を追加します。このフィールドは、許容範囲を追加するときに必要です。効果フィールドに使用できる値は、` NoExecute`、`NoSchedule`、および です`PreferNoSchedule`。

** `jobsubmitter.node.toleration.[tolerationKey].[tolerationSeconds]` **  
tolerationSeconds をプレフィックス *tolerationKey*に追加します。オプションのフィールド。効果が の場合にのみ該当します`NoExecute`。

** `jobsubmitter.scheduler.name` **  
ジョブ送信者ポッドのカスタムschedulerNameを設定します。

** `jobsubmitter.logging` **  
ジョブ送信者ポッドのログ記録を有効または無効にします。これを に設定する` DISABLED`と、ログ記録コンテナがジョブ送信者ポッドから削除され、 `s3MonitoringConfiguration`や など`monitoringConfiguration`、 で指定されたこのポッドのログ記録が無効になります`cloudWatchMonitoringConfiguration`。この設定が設定されていないか、他の値に設定されている場合、ジョブ送信者ポッドでのログ記録が有効になります。

** `jobsubmitter.logging.image` **  
ジョブ送信者ポッドのログ記録コンテナに使用するカスタムイメージを設定します。

** `jobsubmitter.logging.request.cores` **  
ジョブ送信者ポッドのログ記録コンテナの CPU 数のカスタム値を CPU 単位で設定します。デフォルトでは、**100m** に設定されています。

** `jobsubmitter.logging.request.memory` **  
ジョブ送信者ポッドのログ記録コンテナのメモリ量のカスタム値をバイト単位で設定します。デフォルトでは、**200Mi** に設定されています。メビバイトは、メガバイトに似た測定単位です。

** `jobsubmitter.container.image` **  
ジョブ送信者ポッドの`job-runner`コンテナのカスタムイメージを設定します。

** `jobsubmitter.container.image.pullPolicy` **  
ジョブ送信者ポッドのコンテナの [imagePullPolicy](https://kubernetes.io/docs/concepts/containers/images/#image-pull-policy) を設定します。

オンデマンドインスタンスにジョブ送信者ポッドを配置することをお勧めします。ジョブ送信者ポッドをスポットインスタンスに配置することにより、ジョブ送信者ポッドが実行されるインスタンスがスポットインスタンスの中断を受けると、ジョブが失敗する可能性があります。[ジョブ送信者ポッドを単一のアベイラビリティーゾーンに配置することも、ノードに適用される Kubernetes ラベルを使用](#emr-eks-job-submitter-ex-ec2)することもできます。

## ジョブ送信者の分類例
<a name="emr-eks-job-submitter-examples"></a>

**Topics**
+ [ジョブ送信者ポッドのオンデマンドノード配置を含む `StartJobRun` リクエスト](#emr-eks-job-submitter-ex-od)
+ [`StartJobRun` ジョブ送信者ポッドのシングル AZ ノード配置と Amazon EC2 インスタンスタイプの配置による リクエスト](#emr-eks-job-submitter-ex-ec2)
+ [`StartJobRun` ジョブ送信者ポッドのラベル、注釈、カスタムスケジューラを含む リクエスト](#emr-eks-job-submitter-label-annotation-scheduler)
+ [`StartJobRun` キー 、値 `dedicated`、`graviton_machines`効果 `NoExecute`、および 60 秒`tolerationSeconds`の を持つジョブ送信者ポッドに許容範囲が適用された リクエスト](#emr-eks-job-submitter-tolerations)
+ [`StartJobRun` ジョブ送信者ポッドのログ記録が無効になっている リクエスト](#emr-eks-job-submitter-logging-disabled)
+ [`StartJobRun` ジョブ送信者ポッドのカスタムログ記録コンテナイメージ、CPU、メモリを使用した リクエスト](#emr-eks-job-submitter-custom)
+ [`StartJobRun` カスタムジョブ送信者コンテナイメージとプルポリシーを使用した リクエスト](#emr-eks-job-submitter-custom-container)

### ジョブ送信者ポッドのオンデマンドノード配置を含む `StartJobRun` リクエスト
<a name="emr-eks-job-submitter-ex-od"></a>

```
cat >spark-python-in-s3-nodeselector-job-submitter.json << EOF
{
  "name": "spark-python-in-s3-nodeselector", 
  "virtualClusterId": "virtual-cluster-id", 
  "executionRoleArn": "execution-role-arn", 
  "releaseLabel": "emr-6.11.0-latest", 
  "jobDriver": {
    "sparkSubmitJobDriver": {
      "entryPoint": "s3://S3-prefix/trip-count.py", 
      "sparkSubmitParameters": "--conf spark.driver.cores=5  --conf spark.executor.memory=20G --conf spark.driver.memory=15G --conf spark.executor.cores=6"
    }
  }, 
  "configurationOverrides": {
    "applicationConfiguration": [
      {
        "classification": "spark-defaults", 
        "properties": {
          "spark.dynamicAllocation.enabled":"false"
        }
      },
      {
        "classification": "emr-job-submitter",
        "properties": {
          "jobsubmitter.node.selector.eks.amazonaws.com/capacityType": "ON_DEMAND"
        }
      }
    ], 
    "monitoringConfiguration": {
      "cloudWatchMonitoringConfiguration": {
        "logGroupName": "/emr-containers/jobs", 
        "logStreamNamePrefix": "demo"
      }, 
      "s3MonitoringConfiguration": {
        "logUri": "s3://joblogs"
      }
    }
  }
}
EOF
aws emr-containers start-job-run --cli-input-json file:///spark-python-in-s3-nodeselector-job-submitter.json
```

### `StartJobRun` ジョブ送信者ポッドのシングル AZ ノード配置と Amazon EC2 インスタンスタイプの配置による リクエスト
<a name="emr-eks-job-submitter-ex-ec2"></a>

```
"configurationOverrides": {
  "applicationConfiguration": [
    {
      "classification": "emr-job-submitter",
      "properties": {
        "jobsubmitter.node.selector.topology.kubernetes.io/zone": "Availability Zone",
        "jobsubmitter.node.selector.node.kubernetes.io/instance-type":"m5.4xlarge"
      }
    }
  ]
}
```

### `StartJobRun` ジョブ送信者ポッドのラベル、注釈、カスタムスケジューラを含む リクエスト
<a name="emr-eks-job-submitter-label-annotation-scheduler"></a>

```
"configurationOverrides": { 
  "applicationConfiguration": [ 
    {
      "classification": "emr-job-submitter", 
      "properties": {
        "jobsubmitter.label.label1": "value1",
        "jobsubmitter.label.label2": "value2",
        "jobsubmitter.annotation.ann1": "value1",
        "jobsubmitter.annotation.ann2": "value2",
        "jobsubmitter.scheduler.name": "custom-scheduler"
      }
    }
  ]
}
```

### `StartJobRun` キー 、値 `dedicated`、`graviton_machines`効果 `NoExecute`、および 60 秒`tolerationSeconds`の を持つジョブ送信者ポッドに許容範囲が適用された リクエスト
<a name="emr-eks-job-submitter-tolerations"></a>

```
"configurationOverrides": {
  "applicationConfiguration": [
    {
      "classification": "emr-job-submitter",
      "properties": {
        "jobsubmitter.node.toleration.dedicated":"graviton_machines",
        "jobsubmitter.node.toleration.dedicated.effect":"NoExecute",
        "jobsubmitter.node.toleration.dedicated.tolerationSeconds":"60"
      }
    }
  ]
}
```

### `StartJobRun` ジョブ送信者ポッドのログ記録が無効になっている リクエスト
<a name="emr-eks-job-submitter-logging-disabled"></a>

```
"configurationOverrides": {
  "applicationConfiguration": [
    {
      "classification": "emr-job-submitter",
      "properties": {
        "jobsubmitter.logging": "DISABLED"
      }
    }
  ], 
  "monitoringConfiguration": {
    "cloudWatchMonitoringConfiguration": {
      "logGroupName": "/emr-containers/jobs", 
      "logStreamNamePrefix": "demo"
    }, 
    "s3MonitoringConfiguration": {
      "logUri": "s3://joblogs"
    }
  }
}
```

### `StartJobRun` ジョブ送信者ポッドのカスタムログ記録コンテナイメージ、CPU、メモリを使用した リクエスト
<a name="emr-eks-job-submitter-custom"></a>

```
"configurationOverrides": {
  "applicationConfiguration": [
    {
      "classification": "emr-job-submitter",
      "properties": {
        "jobsubmitter.logging.image": "YOUR_ECR_IMAGE_URL",
        "jobsubmitter.logging.request.memory": "200Mi",
        "jobsubmitter.logging.request.cores": "0.5"
      }
    }
  ], 
  "monitoringConfiguration": {
    "cloudWatchMonitoringConfiguration": {
      "logGroupName": "/emr-containers/jobs", 
      "logStreamNamePrefix": "demo"
    }, 
    "s3MonitoringConfiguration": {
      "logUri": "s3://joblogs"
    }
  }
}
```

### `StartJobRun` カスタムジョブ送信者コンテナイメージとプルポリシーを使用した リクエスト
<a name="emr-eks-job-submitter-custom-container"></a>

```
"configurationOverrides": {
  "applicationConfiguration": [
    {
      "classification": "emr-job-submitter",
      "properties": {
        "jobsubmitter.container.image": "123456789012.dkr.ecr.us-west-2.amazonaws.com/emr6.11_custom_repo",
        "jobsubmitter.container.image.pullPolicy": "kubernetes pull policy"
      }
    }
  ]
}
```

# Amazon EMR コンテナのデフォルト分類の使用
<a name="emr-eks-job-submitter-container-defaults"></a>

## 概要:
<a name="emr-eks-job-submitter-container-defaults-overview"></a>

`emr-containers-defaults` 分類では以下の設定が可能です:

** `job-start-timeout` **  
デフォルトでは、ジョブが開始できず、` SUBMITTED` 状態で 15 分間待機することにより、ジョブはタイムアウトします。この設定では、ジョブがタイムアウトするまで待機する秒数を変更します。

** `executor.logging` **  
エグゼキュターポッドのログ記録を有効または無効にします。これを に設定する` DISABLED`と、エグゼキュターポッドからログコンテナが削除され、 `s3MonitoringConfiguration`や など`monitoringConfiguration`、 で指定されたこれらのポッドのログ記録が無効になります`cloudWatchMonitoringConfiguration`。この設定が設定されていないか、他の値に設定されている場合、エグゼキュターポッドでのログ記録が有効になります。

** `logging.image` **  
ドライバーポッドとエグゼキュターポッドのログ記録コンテナに使用するカスタムイメージを設定します。

** `logging.request.cores` **  
ドライバーポッドとエグゼキュターポッドのログ記録コンテナの CPU 数のカスタム値を CPU 単位で設定します。デフォルトでは、これは設定されていません。

** `logging.request.memory` **  
ドライバーポッドとエグゼキュターポッドのログ記録コンテナのメモリ量のカスタム値をバイト単位で設定します。デフォルトでは、**512Mi** に設定されています。メビバイトは、メガバイトに似た測定単位です。

## ジョブ送信者の分類例
<a name="emr-eks-job-submitter-container-examples"></a>

**Topics**
+ [カスタムジョブタイムアウトによる `StartJobRun` リクエスト](#emr-eks-job-submitter-container-custom-timeout)
+ [`StartJobRun` エグゼキュターポッドのログ記録が無効になっている リクエスト](#emr-eks-executor-logging-disabled)
+ [`StartJobRun` ドライバーポッドとエグゼキュターポッドのカスタムログ記録コンテナイメージ、CPU、メモリを使用した リクエスト](#emr-eks-job-submitter-container-custom-image-cpu)

### カスタムジョブタイムアウトによる `StartJobRun` リクエスト
<a name="emr-eks-job-submitter-container-custom-timeout"></a>

```
{
  "name": "spark-python", 
  "virtualClusterId": "virtual-cluster-id", 
  "executionRoleArn": "execution-role-arn", 
  "releaseLabel": "emr-6.11.0-latest", 
  "jobDriver": {
    "sparkSubmitJobDriver": {
      "entryPoint": "s3://S3-prefix/trip-count.py"
    }
  }, 
  "configurationOverrides": {
    "applicationConfiguration": [
      {
        "classification": "emr-containers-defaults", 
        "properties": {
          "job-start-timeout": "1800"
        }
      }
    ], 
    "monitoringConfiguration": {
      "cloudWatchMonitoringConfiguration": {
        "logGroupName": "/emr-containers/jobs", 
        "logStreamNamePrefix": "demo"
      }, 
      "s3MonitoringConfiguration": {
        "logUri": "s3://joblogs"
      }
    }
  }
}
```

### `StartJobRun` エグゼキュターポッドのログ記録が無効になっている リクエスト
<a name="emr-eks-executor-logging-disabled"></a>

```
"configurationOverrides": {
  "applicationConfiguration": [
    {
      "classification": "emr-containers-defaults", 
      "properties": {
        "executor.logging": "DISABLED"
      }
    }
  ], 
  "monitoringConfiguration": {
    "cloudWatchMonitoringConfiguration": {
      "logGroupName": "/emr-containers/jobs", 
      "logStreamNamePrefix": "demo"
    }, 
    "s3MonitoringConfiguration": {
      "logUri": "s3://joblogs"
    }
  }
}
```

### `StartJobRun` ドライバーポッドとエグゼキュターポッドのカスタムログ記録コンテナイメージ、CPU、メモリを使用した リクエスト
<a name="emr-eks-job-submitter-container-custom-image-cpu"></a>

```
"configurationOverrides": {
  "applicationConfiguration": [
    {
      "classification": "emr-containers-defaults", 
      "properties": {
        "logging.image": "YOUR_ECR_IMAGE_URL",
        "logging.request.memory": "200Mi",
        "logging.request.cores": "0.5"
      }
    }
  ], 
  "monitoringConfiguration": {
    "cloudWatchMonitoringConfiguration": {
      "logGroupName": "/emr-containers/jobs", 
      "logStreamNamePrefix": "demo"
    }, 
    "s3MonitoringConfiguration": {
      "logUri": "s3://joblogs"
    }
  }
}
```