AWS BatchでEKSコンピューティング環境を作成する際の詰まったところ
お疲れさまです。とーちです。
AWS BatchでEKSコンピューティング環境を作成する機会があったのですが、私はEKSやKubernetesのことをほとんど理解していなかったため、思わぬところで詰まってしまいました。この記事では、詰まったポイントとその解決方法を共有したいと思います。
想定読者
- EKSに関する知見がそれほどない状態でAWS BatchでEKSコンピューティング環境を作ろうとしてる方
AWS BatchでEKSコンピューティング環境を作る際の大まかな流れ
AWS BatchでEKSコンピューティング環境を作成するには、大きく分けて以下の2ステップが必要です。
- まずEKSクラスターを作成する
- AWS Batch上でEKSコンピューティング環境を作成
2については、以下の公式チュートリアルに従えばそれほど詰まるところもなく作成できると思います。が、実際にチュートリアル通りに作っていく中で不明な点もあったのでそこも紹介したいと思います。
EKSクラスターの作成で詰まったポイント
1. クラスター認証モードの選択
私はEKSクラスターの作成経験もほとんどなかったので、とりあえずマネージメントコンソールからEKSクラスターを作ってみました。EKSクラスターは2024年のre:Invent前後のアップデートでだいぶ変更が入っており、マネージメントコンソールから作ろうとするとまず以下のような画面が表示されます。
これが私にとっては一つめの詰まったポイントでした。
クイック設定で作成した場合、EKSクラスターはクラスター認証モードとして「EKS API」が指定されます。
ところが、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クラスター作成で詰まった方はヒントにして頂ければ幸いです。アドオンについては適宜必要なものを選択するようにお願いします。
AWS Batch EKS コンピューティング環境の作成
EKSコンピューティング環境の作成については基本的に以下のチュートリアルに従えばOKです。
ただ、詰まったとまではいきませんが、不明な点があったのでそれも共有します。
サービスにリンクされたロールの事前作成は必要か?
結論から言うと、事前に作成する必要はありません。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が関連しているそうです
裏側の仕組みまではわかりませんが、結論からいうと異なっていても問題なくAWS Batchのコンピューティング環境は作成できました。
まとめ
AWS BatchでEKSコンピューティング環境を作成する際には、以下の点に注意しましょう
- EKSクラスターのクラスター認証モードは必ず「EKS API と ConfigMap」を選択する
- サポートされているKubernetesバージョン(現時点では1.30まで)を選択する
- API サーバーエンドポイントにはパブリックアクセスを設定する
以上、AWS BatchのEKSコンピューティング環境作成の際に詰まった箇所の紹介でした。この記事が、同じような状況の方の助けになれば幸いです。
以上、とーちでした。