AWS BatchでEKSコンピューティング環境を作成する際の詰まったところ

AWS BatchでEKSコンピューティング環境を作成する際の詰まったところ

AWS BatchのEKSコンピューティング環境作成の際に詰まった箇所を紹介します
Clock Icon2025.02.25

お疲れさまです。とーちです。

AWS BatchでEKSコンピューティング環境を作成する機会があったのですが、私はEKSやKubernetesのことをほとんど理解していなかったため、思わぬところで詰まってしまいました。この記事では、詰まったポイントとその解決方法を共有したいと思います。

想定読者

  • EKSに関する知見がそれほどない状態でAWS BatchでEKSコンピューティング環境を作ろうとしてる方

AWS BatchでEKSコンピューティング環境を作る際の大まかな流れ

AWS BatchでEKSコンピューティング環境を作成するには、大きく分けて以下の2ステップが必要です。

  1. まずEKSクラスターを作成する
  2. AWS Batch上でEKSコンピューティング環境を作成

2については、以下の公式チュートリアルに従えばそれほど詰まるところもなく作成できると思います。が、実際にチュートリアル通りに作っていく中で不明な点もあったのでそこも紹介したいと思います。

https://docs.aws.amazon.com/batch/latest/userguide/getting-started-eks.html

EKSクラスターの作成で詰まったポイント

1. クラスター認証モードの選択

私はEKSクラスターの作成経験もほとんどなかったので、とりあえずマネージメントコンソールからEKSクラスターを作ってみました。EKSクラスターは2024年のre:Invent前後のアップデートでだいぶ変更が入っており、マネージメントコンソールから作ろうとするとまず以下のような画面が表示されます。

CleanShot 2025-02-25 at 16.44.31@2x.png

これが私にとっては一つめの詰まったポイントでした。

クイック設定で作成した場合、EKSクラスターはクラスター認証モードとして「EKS API」が指定されます。

image.png

ところが、AWS BatchではConfigMapを使った認証を前提としています。ConfigMapを使って認証させるためには、クラスター認証モードを「EKS API と ConfigMap」にする必要があるため、クイック設定で作成するとAWS Batchのコンピューティング環境としては使用できません。

なお、クラスター認証モードはクラスター作成後に「EKS API」から「EKS API と ConfigMap」に変更することはできません。そのため、既存のEKSクラスターのクラスター認証モードが「EKS API」になっている場合は、AWS Batchのために新しくEKSクラスターを作成する必要があります。

2. Kubernetes バージョンの選択

2つめのポイントとしてはKubernetes バージョンです。

EKSで作成できるKubernetes バージョンは2025年2月現時点では1.31が最新版になります。しかしAWS BatchがサポートしているKubernetes バージョンは1.30までです。そのため、このバージョンについてもAWS Batchのドキュメントを確認し、サポートされているバージョンを選ぶようにしましょう。

詳細は以下のドキュメントで確認できます
Supported Kubernetes versions - AWS Batch

3. API サーバーエンドポイントのアクセス設定

また、これは今回詰まったわけではないのですが、ドキュメントを見ていて気をつけたほうがよいと思ったので記載します。AWS BatchのEKSコンピューティング環境では、パブリックインターネットにアクセスできるパブリックアクセスを持つ API サーバーエンドポイントを持つ Amazon EKS クラスターのみをサポートします。ここも注意しましょう。

参考:https://docs.aws.amazon.com/batch/latest/userguide/getting-started-eks.html

EKSクラスターの設定例

以上の注意ポイントを踏まえて今回作成したEKSクラスター設定も載せておきます。AWS BatchのEKSクラスター作成で詰まった方はヒントにして頂ければ幸いです。アドオンについては適宜必要なものを選択するようにお願いします。

image.png

AWS Batch EKS コンピューティング環境の作成

EKSコンピューティング環境の作成については基本的に以下のチュートリアルに従えばOKです。

https://docs.aws.amazon.com/batch/latest/userguide/getting-started-eks.html

ただ、詰まったとまではいきませんが、不明な点があったのでそれも共有します。

サービスにリンクされたロールの事前作成は必要か?

結論から言うと、事前に作成する必要はありません。aws batch create-compute-environment でコンピューティング環境を作成する際に、サービスにリンクされたロールが存在しなければ自動で作成されます。

以下は実際に検証した際のコマンド実行例です

# コンピューティング環境作成前はサービスにリンクされたロールは存在しない
bash-5.2$ aws iam get-role --role-name AWSServiceRoleForBatch

An error occurred (NoSuchEntity) when calling the GetRole operation: The role with name AWSServiceRoleForBatch cannot be found.
# コンピューティング環境を作成する
bash-5.2$ cat <<EOF > ./batch-eks-compute-environment.json
{
  "computeEnvironmentName": "My-Eks-CE1",
  "type": "MANAGED",
  "state": "ENABLED",
  "eksConfiguration": {
<中略>
  }
}
EOF
aws batch create-compute-environment --cli-input-json file://./batch-eks-compute-environment.json
{
    "computeEnvironmentName": "My-Eks-CE1",
    "computeEnvironmentArn": "arn:aws:batch:ap-northeast-1:******:compute-environment/My-Eks-CE1"
}
# コンピューティング環境作成したタイミングでサービスにリンクされたロールが自動で作成
bash-5.2$ aws iam get-role --role-name AWSServiceRoleForBatch
{
    "Role": {
        "Path": "/aws-service-role/batch.amazonaws.com/",
        "RoleName": "AWSServiceRoleForBatch",
<中略>
        "CreateDate": "2025-02-25T06:25:25+00:00",
        "AssumeRolePolicyDocument": {
            "Version": "2012-10-17",
            "Statement": [
                {
                    "Effect": "Allow",
                    "Principal": {
                        "Service": "batch.amazonaws.com"
                    },
                    "Action": "sts:AssumeRole"
                }
            ]
        },
        "MaxSessionDuration": 3600,
        "RoleLastUsed": {}
    }
}

aws-auth ConfigMapが存在していない状態でのマッピング

aws-auth ConfigMapが存在していない状態で、eksctl create iamidentitymapping でマッピングをしても大丈夫なのでしょうか?

こちらも検証したところ、aws-auth configmapが存在していなければ自動で作成されることが確認できました。

# aws-authは存在しない
bash-5.2$  kubectl get --all-namespaces configmaps
NAMESPACE                NAME                                                   DATA   AGE
default                  kube-root-ca.crt                                       1      43m
kube-node-lease          kube-root-ca.crt                                       1      43m
kube-public              kube-root-ca.crt                                       1      43m
kube-system              extension-apiserver-authentication                     6      43m
kube-system              kube-apiserver-legacy-service-account-token-tracking   1      43m
kube-system              kube-root-ca.crt                                       1      43m
my-aws-batch-namespace   kube-root-ca.crt                                       1      54s
# eksctl create iamidentitymappingでサービスにリンクされたロールとKubernetes ロールのマッピングを行う
bash-5.2$ eksctl create iamidentitymapping \
    --cluster test2 \
    --arn "arn:aws:iam::******:role/AWSServiceRoleForBatch" \
    --username aws-batch
2025-02-25 15:10:55 []  checking arn arn:aws:iam::******:role/AWSServiceRoleForBatch against entries in the auth ConfigMap
2025-02-25 15:10:55 []  adding identity "arn:aws:iam::******:role/AWSServiceRoleForBatch" to auth ConfigMap
# aws-authが作成されている
bash-5.2$  kubectl get --all-namespaces configmaps
NAMESPACE                NAME                                                   DATA   AGE
default                  kube-root-ca.crt                                       1      44m
kube-node-lease          kube-root-ca.crt                                       1      44m
kube-public              kube-root-ca.crt                                       1      44m
kube-system              aws-auth                                               2      15s
kube-system              extension-apiserver-authentication                     6      44m
kube-system              kube-apiserver-legacy-service-account-token-tracking   1      44m
kube-system              kube-root-ca.crt                                       1      44m
my-aws-batch-namespace   kube-root-ca.crt                                       1      116s

サービスにリンクされたロールのARNの指定方法

公式ドキュメントに従うと、 eksctl create iamidentitymapping で指定するサービスにリンクされたロールのARNが実際のものと異なりますが、問題ないのでしょうか?

コマンドの引数では以下を指定します

  • "arn:aws:iam::<your-account>:role/AWSServiceRoleForBatch"

しかし実際のサービスにリンクされたロールのARNは以下のようになっています

  • "arn:aws:iam::<your-account>:role/aws-service-role/batch.amazonaws.com/AWSServiceRoleForBatch"

これはドキュメントによると以下のissueが関連しているそうです
https://github.com/kubernetes-sigs/aws-iam-authenticator/issues/268

裏側の仕組みまではわかりませんが、結論からいうと異なっていても問題なくAWS Batchのコンピューティング環境は作成できました。

まとめ

AWS BatchでEKSコンピューティング環境を作成する際には、以下の点に注意しましょう

  1. EKSクラスターのクラスター認証モードは必ず「EKS API と ConfigMap」を選択する
  2. サポートされているKubernetesバージョン(現時点では1.30まで)を選択する
  3. API サーバーエンドポイントにはパブリックアクセスを設定する

以上、AWS BatchのEKSコンピューティング環境作成の際に詰まった箇所の紹介でした。この記事が、同じような状況の方の助けになれば幸いです。

以上、とーちでした。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.