クラウドインテグレーション部、
クラウドソリューション2課の川井です。
Amazon Elastic Kubernetes Service (以下、EKS) は、Kubernetesクラスタの管理やデプロイを簡素化し、
スケーラビリティや可用性を向上させるAWSのマネージドサービスです。
その中でもEKS on Fargateは、サーバーレスでKubernetesワークロードを実行できる環境を提供します。
これにより、クラスタのインフラ管理の手間がなくなり、コンテナの実行に専念できます。
本記事では、EKS on Fargate と Amazon Application Load Balancer (以下、ALB) を組み合わせて使う方法を実装していきます。
ALBは、HTTP/HTTPSトラフィックの負荷分散を行い、アクセス制御やスケーラブルなロードバランシングを実現するAWSのサービスです。
特にAWS Load Balancer Controllerを活用することで、Kubernetesから直接ALBの作成や管理が可能になります。
これにより、デプロイの効率がさらに向上し、シンプルかつ柔軟なアプリケーションの運用が実現できます。
本記事の内容は以下の通りです。
✅ Amazon EKSクラスターとFargateプロファイルのセットアップ
✅ AWS Load Balancer Controllerのインストールと設定
✅ ALBを使用したアプリケーションの自動化されたデプロイと管理
今回、作成するEKSの構成は以下の通りとなります。
EKSのコントロールプレーン（APIサーバ）は、AWSが管理するVPCに配置されます。
EKSクラスターを作成する際に、コントロールプレーンへの接続方法を以下の選択肢から選ぶ必要があります。
今回の設定では、コントロールプレーン接続方法を「パブリックおよびプライベート」に設定します。この設定により、
クラスター作成時に指定したサブネット内に、自動でインターフェイス（VPCエンドポイント）が作成されます。
これは、EKSがコントロールプレーンのエンドポイントアクセスを「パブリックおよびプライベート」または「プライベート」に設定した際に自動的に生成されるものです。
この自動生成されるエンドポイントを使用することで、VPC内のサーバーはプライベートにコントロールプレーンへアクセスできます。
したがって、通常はVPC内のリソースはこのインターフェイスを介してコントロールプレーンに接続することになります。
※ 注意: 一部のeksctlコマンドは、この自動作成されるインターフェイス経由では動作しません。
そのため、コントロールプレーンへのアクセスを完全にプライベートにする際は、Amazon EKS（com.amazonaws.region-code.eks）VPCエンドポイントを別途作成する必要があります。
EKSのプライベート接続についての詳細な情報は以下のAWS公式ドキュメントをご覧ください。
インターネットアクセスが制限されたプライベートクラスターをデプロイする
EKSのコンピューティング環境（ノードプール）には Fargateを使用します。Fargateでは、ノードはプライベートサブネットにのみ配置可能です。
そのため、本構成ではノードをプライベートサブネットに配置します。
Fargateタイプを利用する際には、以下のAWS公式ドキュメントをご参照ください。
「AWS Fargate考慮事項」のセクションに、Fargateタイプを使用する際の制限事項が記載されていますので、一読をお勧めします。
AWS Fargate を使用してコンピューティング管理を簡素化する
今回必要なNode/Podは以下の3つです。
1️⃣aws-load-balancer-controlle：KubernetesからネイティブにALBの作成や操作する為のPod。
2️⃣CoreDns：Pod内のドメイン解決や外部DNSのForwardするPod。
3️⃣Nginx：ALBの接続確認のために作成するPod。
Fargateタイプでは、NodeとPodは1対1の関係となります。そのため、1つのNodeに複数のPodを作成することはできません。
したがって、必要なPodの数だけNodeを作成する必要があります。
AWS Load Balancer Controllerを使用してALBをパブリックサブネットに配置し、ALBを経由してNginx Podに接続します。
NAT Gatewayは、NginxイメージをDocker Hubからダウンロードする際などに使用されます。
また、VPC内のパブリックサブネットに配置した Amazon EC2（以下、EC2）は、kubectlやeksctlコマンドを実行するために使用します。
以上が、今回の構成の説明になります。続いて、事前準備を行います。
まず、kubectlやeksctlコマンドを実行するために、EKSクラスターを構築するVPC内にEC2を立ち上げます。使用するAMIは「Amazon Linux 2023」です。
セキュリティグループ（SG）やIAMロールについては、必要に応じて設定を行ってください。
※EC2の作成は省略します、ご了承ください。
では、EKSをセットアップするために、必要なツールをインストールしていきます。
Amazon Linux 2023のAMIでは、AWS CLIはデフォルトでインストールされています。
$ aws --version
AWS CLIがインストールされていない場合は、以下のAWS公式ドキュメントを参照し実行ください。
AWS CLI の最新バージョンのインストールまたは更新
ステップ ①: kubectl がインストールされているかどうかを確認
以下のコマンドでkubectlがインストールされているか確認します。「command not found」と出力された場合、インストールを実行していきます。
$ kubectl version --client
ash: kubectl: command not found
ステップ ②: kubectlをインストールする
kubectlのインストールは、以下のAWS公式ドキュメントを元に実行していきます。
kubectl および eksctl のセットアップ
1：クラスターのKubernetesバージョンのkubectlバイナリをAmazon S3からダウンロードする。
Amazon Linux 2023は「x86_64」を使用していますので、Linux (amd64)の「Kubernetes 1.32」の最新バージョンを以下のコマンドでインストールをします。
※バージョンは現在の 2025年3月時点で最も新しいバージョンをインストールしています。
$ curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/1.32.0/2024-12-20/bin/linux/amd64/kubectl
2：（オプション）ダウンロードしたバイナリを、バイナリのSHA-256チェックサムで検証する。
以下のコマンドで、ダウンロードしたバイナリを、バイナリのSHA-256チェックサムで検証します。「kubectl: OK」と表示されれば問題ありません。
※こちらは必須の工程ではありませんので、スキップしても問題ありません。
$ curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/1.32.0/2024-12-20/bin/linux/amd64/kubectl.sha256
sha256sum -c kubectl.sha256
3：バイナリへの実行アクセス許可を適用。
以下のコマンドで、kubectlファイルに実行権限 (executable permission) を付与します。
$ chmod +x ./kubectl
4：バイナリをPATHのフォルダにコピー。
以下のコマンドで、kubectlをユーザーのローカル環境にインストールし、kubectlを実行可能にします。
$ mkdir -p $HOME/bin && cp ./kubectl $HOME/bin/kubectl && export PATH=$HOME/bin:$PATH
以下画像のように、ホームディレクトリ配下のbinフォルダにkubectlがあれば問題ありません。
5：(オプション) 実行環境における設定を恒久的に変更するために、シェルの初期化ファイルに$HOME/binパスを追加。
※こちらは必須の工程ではありませんので、スキップしても問題ありません。
以下のコマンドで、$HOME/binディレクトリをPATHに追加し、永続的にkubectlを実行可能にします。
$ echo 'export PATH=$HOME/bin:$PATH' >> ~/.bashrc
最後に、kubectlがインストールされているかどうかを確認します。以下のように出力されればインストールは成功です。
$ kubectl version --client
Client Version: v1.32.0-eks-5ca49cb
Kustomize Version: v5.5.0
ステップ ①: eksctlがインストールされているかどうかを確認
以下のコマンドでeksctlがインストールされているか確認します。「command not found」と出力された場合、インストールを実行していきます。
$ eksctl version
bash: eksctl: command not found
ステップ ②: eksctlをインストールする
eksctlは、以下の公式ドキュメントを元に実行します。
eksctlインストール
1：アーキテクチャの設定。
Amazon Linux 2023は「x86_64」を使用していますので、ARCHにシステムのアーキテクチャとして「amd64」を設定します。
PLATFORMには、システムのオペレーティングシステム名（uname -s で取得）とアーキテクチャを組み合わせたものをセットします。Linux_amd64といった値が設定されます。
$ ARCH=amd64
$ PLATFORM=$(uname -s)_$ARCH
2：eksctl をダウンロードする。
以下のコマンドで、eksctlの最新リリースをダウンロードします。ここでのURLは、GitHub上の最新のeksctlリリースのtar.gzファイルを指しています。
「ksctl_Linux_amd64.tar.gz」などのtar.gzファイルがダウンロードされていれば問題ありません。
$ curl -sLO "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_$PLATFORM.tar.gz"
3：（オプション）ダウンロードしたバイナリを、バイナリのSHA-256チェックサムで検証する。
以下のコマンドで、ダウンロードしたバイナリを、バイナリの SHA-256チェックサムで検証します。「eksctl_Linux_amd64.tar.gz: OK」と表示されれば問題ありません。
※こちらは必須の工程ではありませんので、スキップしても問題ありません。
$ curl -sL "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_checksums.txt" | grep $PLATFORM | sha256sum --check
eksctl_Linux_amd64.tar.gz: OK
3：ファイルの解凍とクリーニングを実行する。
以下のコマンドを使って、ダウンロードしたtar.gzファイルを/tmpディレクトリに解凍し、元のファイルを削除します。
$ tar -xzf eksctl_$PLATFORM.tar.gz -C /tmp && rm eksctl_$PLATFORM.tar.gz
4：バイナリの移動をする。
以下のコマンドで、eksctlのバイナリを/tmpから/usr/local/binに移動します。このディレクトリに移動することで、システム全体からeksctlコマンドを利用可能にします。
$ sudo mv /tmp/eksctl /usr/local/bin
最後に、eksctlがインストールされているかどうかを確認します。以下のように出力されればインストールは成功です。
$ eksctl version
0.205.0
これで事前準備は完了です。続いて、EKSクラスター作成を行っていきます。
※今回は、eksctlを使用した「eksctl create cluster」コマンドからEKSクラスターの作成は行いません。
こちらのコマンドを実行することで、EKSクラスターを作成するのに必要なAWSリソース（VPC、サブネット、SG、Internet Gateway、NAT Gateway、IAM ROLE etc.）も一緒に自動作成してくれます。
しかし、今回はEKSコンソール画面からカスタム設定にて、EKSクラスターを作成していきますので、VPCやサブネットなどのネットワークリソースは既に作成済みのものとして進めていきます。
そのため、これらのリソースの作成は省略していますので、ご了承ください。
事前準備が完了しましたので、まずはEKSクラスターに付与するクラスターのIAMロールを作成します。
クラスターのIAMロールは「EKS Auto Mode」にするか、しないかで変わっていきます。EKS Auto Modeとは、2024年11月に発表されたばかりEKSの新機能になります。
詳細はAWS公式ドキュメントを参照して頂きたいと思いますが、このモードはFargateタイプに限らず、EC2で構成されるノードプールをAWS側が管理を行ってくれるというものです。
Fargateタイプとの違いは本記事では割愛致しますが、今回はFargateタイプのみでEKSクラスターを構築しますので、EKS Auto Modeは無効にします。
そのため、EKS Auto Modeは考慮せずにIAMロールを作成していきます。
クラスターで設定するIAMロールおよびIAMポリシーには、以下の設定を適用します。ポリシーはAWS管理ポリシーを使用します。
なお、名前などの設定については、各自の判断で自由に設定してください。今回、名前は「eks-cluster-role」で作成していきます。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
AmazonEKSClusterPolicy
AmazonEKSServicePolicy
クラスターロールを作成しましたら、EKSクラスターを作成していきます。EKSコンソール画面で「クラスターを作成」へと進んでいきます。
クラスターの設定画面が表示されますので、設定オプションは「カスタム設定」、EKSオートモードは「無効」、クラスター名は「eks-fargate-cluster」、クラスターIAM ロールは先程作成した「eks-cluster-role」を指定します（EKSオートモードは、クラスター作成後でも変更可能です）
Kubernetesバージョンは「1.32（現状での最新バージョン）」、自動モードコンピューティングは EKSオートモードが無効なので設定出来ません。
クラスターアクセスは「クラスター管理者アクセスを許可」、クラスター認証モードは「EKS API」を指定します。
EKS APIとは、IAMロール・ユーザーでクラスターへの認証を指定します。詳細な認証を設定した場合は「EKS API と ConfigMap」の指定してください。エンベロープ暗号化は特に指定しません。
ARCゾーンシフトは検証環境のため「無効」にします（クラスター作成後でも変更可能です）
続いて、ネットワーキングの設定画面では、VPCやサブネットは事前に作成したものを指定します。残りは全てDefaultの設定のままにします。サブネットは、パブリック及びプライベート共に3つずつ作成しています。
クラスターエンドポイントアクセスは前述した通り「パブリックおよびプライベート」に設定します。
残りの「オブザーバビリティを設定」、「アドオンを選択」、「選択したアドオン設定を構成する」は変更せずにDefaultのまま設定してEKSクラスターを作成します（これらの設定はクラスター作成後でも変更可能です）
EKSクラスターの作成には約15分程かかります。作成が問題なく完了すると、ステータスは以下の画像のように「アクティブ」と表示されます。
EKSクラスター作成が完了しましたら「Fargateプロファイル」を作成します。Fargateプロファイルとは、KubernetesのPodをFargate上で実行する際に適用される設定のことを指します。
Fargateプロファイルを定義することで、特定のネームスペースやラベルが付与されたPodをFargate上で自動的に実行できるようになります。
では、まずFargateプロファイルを作成する前に、Fargateプロファイル用のIAMロールを作成します。
プロファイルで設定するIAMロールおよびIAMポリシーには、以下の設定を適用します。ポリシーはAWS管理ポリシーを使用します。なお、名前などの設定については、各自の判断で自由に設定してください。今回、名前は「eks-fargate-pods-role」で作成していきます。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks-fargate-pods.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
AmazonEKSFargatePodExecutionRolePolicy
プロファイルロールを作成しましたら、Fargateプロファイルを作成していきます。
Fargateプロファイルは、EKSコンソール画面で「クラスター」、「コンピューティング」、「Fargateプロファイルを追加」へと進んでいきます。
プロファイル設定画面が表示されますので、名前は「fargate-node-profiles」、ポッド実行ロールは先程作成した「eks-fargate-pods-role」、サブネットは自動的にクラスターで設定したVPC内のプライベートサブネットが選択されています。
※前述した通り、Fargateはプライベートサブネットにしかノードを配置できないため、プライベートサブネットしか選択出来ません
次の画面では、ポッドセレクタの設定画面が表示されます。以下の画像では、3つの名前空間を作成しています。
「fargate-nodes」: NginxなどのPodを配置するための名前空間です。任意の名前を指定できます。
「kube-system」: aws-load-balancer-controllerやCoreDNSのPodを配置するための名前空間です。この名前はKubernetesのシステムコンポーネント用として固定されているため、変更できません。
「default」: 一般的なデフォルトの名前空間ですが、本構成では特に使用しません。作成は任意です。
プロファイル作成にも少々時間が掛かりますが、作成が問題なく完了すると、ステータスは以下の画像のように「アクティブ」と表示されます。
以下のAWS公式ドキュメントのノードのサブネットの要件記載されていますが、ロードバランサーをサブネットにデプロイする場合は、サブネットに次のタグが必要です。
EKSやAWS Load Balancer Controllerが、どのサブネットをロードバランサーのデプロイ先として使用するかを判別するために必要になります。
VPC とサブネットの Amazon EKS ネットワーキング要件を表示する
✅プライベートサブネット
キー：kubernetes.io/role/internal-elb
値 ：1
✅パブリックサブネット
キー：kubernetes.io/role/elb
値 ：1
EKSクラスターのセットアップとして上記以外にも、プライベート接続でコントロールプレーンへ接続する際には、 クラスターセキュリティグループへアクセス元の許可設定が必要なります。
また、認証にEKS APIを使用していきますので、EKSクラスターのIAMアクセスエントリで、アクセス元の許可設定が必要になります。
これらは、利用環境に応じて適切に設定を行ってください。
続いて、AWS Load Balancer Controllerのインストールを実施していきます。
AWS Load Balancer Controllerのインストールは、以下のAWS公式ドキュメントを参照に実行していきます。
Helm による AWS Load Balancer Controller のインストール
まず、このドキュメントに記載された前提条件である「OIDCプロバイダーの作成」および「Helmのインストール」を実行していきます。
以下のコマンドは、EKSクラスターにOIDC（OpenID Connect）プロバイダーを関連付けるためのものです。
$ eksctl utils associate-iam-oidc-provider --cluster eks-fargate-cluster --approve
IAMのコンソール画面のIDプロバイダーに「oidc.eks.ap-northeast-1.amazonaws.com/id/×××××××××××××××××」というOIDCプロバイダーが作成されたことが確認できます。
以下のコマンドでHelmをインストールします。
$ curl -sLO "https://get.helm.sh/helm-v3.14.4-linux-amd64.tar.gz"
$ tar -xzf helm-v3.14.4-linux-amd64.tar.gz -C /tmp && rm helm-v3.14.4-linux-amd64.tar.gz
$ sudo mv /tmp/linux-amd64/helm /usr/local/bin/
「Version:"v3.14.4"」と表示されればインストール成功です。
$ helm version
AWS Load Balancer Controllerをインストールする前に、以下のコマンドを実行して指定したEKSクラスターに接続できるようにします。
このコマンドは、EKSクラスタに対するKubernetesの設定ファイル（kubeconfig）を更新するためのコマンドです。
ローカルのkubeconfigファイルを更新して、指定したEKSクラスターに接続できるようにします。「Updated context」と表示されれば成功です。
$ aws eks update-kubeconfig --region ap-northeast-1 --name eks-fargate-cluster
ステップ ①: eksctlを使用して IAMロールを作成する
1：AWS Load Balancer Controller用の IAM ポリシーをダウンロードする。
以下のコマンドで「iam_policy.json」がダウンロードされます。
$ curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.11.0/docs/install/iam_policy.json
2：ダウンロードしたポリシーを使用して、IAMポリシーを作成する。
以下のコマンドで、先程ダウンロードしたファイルを使用してIAMポリシーを作成します。
aws iam create-policy \
--policy-name AWSLoadBalancerControllerIAMPolicy \
--policy-document file://iam_policy.json
IAMのコンソールのポリシー画面にて「AWSLoadBalancerControllerIAMPolicy」というポリシーが作成されたことが確認できます。
3：作成したポリシーを使用して、IAMロールを作成する。
以下のコマンドは、EKSクラスター内で aws-load-balancer-controller というサービスアカウントを作成し、
そのサービスアカウントに、AWSLoadBalancerControllerIAMPolicyを関連付け、AWS Load Balancer Controllerが必要な権限を持つように設定するものです。
これにより、IAMロールをKubernetesのServiceAccountに紐付け、Pod単位でAWSのリソースにアクセスできるようになります。
$ eksctl create iamserviceaccount \
--cluster eks-fargate-cluster \
--region ap-northeast-1 \
--namespace kube-system \
--name aws-load-balancer-controller \
--attach-policy-arn arn:aws:iam::<アカウントID>:policy/AWSLoadBalancerControllerIAMPolicy \
--approve
以下のコマンドで、作成したサービスアカウントに付与されたIAMロールが確認できます。このIAMロールには、先程作成したOIDCプロバイダーとIAMポリシーが関連付けられています。
kubectl get serviceaccount aws-load-balancer-controller -n kube-system -o yaml | grep eks.amazonaws.com/role-arn
IAMのコンソールのロール画面にて「eksctl-eks-fargate-cluster-addon-iamserviceac-Role1-0aSHI5xFCMOu」というロールが作成されたことが確認できます。
ステップ ②: Helmを使用して AWS Load Balancer Controller をインストールする
1：eks-charts Helm チャートリポジトリを追加する。
以下のコマンドを実行すると、eksという名前で AWSのEKSチャートリポジトリがHelmに追加されます。これにより、そのリポジトリからKubernetesマニフェストを容易に取得およびインストールできるようになります。
今回で言えば「AWS Load Balancer Controller」のことになります。
$ helm repo add eks https://aws.github.io/eks-charts
$ helm repo update eks
2：AWS Load Balancer コントローラをインストール
以下のコマンドは、AWS Load Balancer Controllerを指定された設定でKubernetesクラスターにインストールします。これにより Kubernetesクラスター内で AWSのロードバランサーを管理できるようになります。
clusterNameやvpcIdなどは、適切な値を設定してください。
$ helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
--namespace kube-system \
--set clusterName=eks-fargate-cluster \
--set serviceAccount.create=false \
--set serviceAccount.name=aws-load-balancer-controller \
--set vpcId=<vpc-xxxxxxxx>\
--set region=ap-northeast-1
以下のコマンドを実行し、AWS Load Balancer Controllerが正常にインストールされているか確認します。出力が以下の画像のようになっていれば、インストールは正常に完了しています。
$ helm list -n kube-system
3：（オプション） CRD 自動的にインストール ※こちらは必須の工程ではありませんので、スキップしても問題ありません。
以下のコマンドは、CRD（Custom Resource Definition）が一度インストールされた後も、自動でCRDがアップグレードされるようにする設定です。
helm upgradeを使ってチャートを更新すると、新たに必要なCRDが追加された場合でも自動でインストールされません。
そのため、CRDを手動で適用することが推奨されているため、以下コマンドを実行します。
$ wget https://raw.githubusercontent.com/aws/eks-charts/master/stable/aws-load-balancer-controller/crds/crds.yaml
$ kubectl apply -f crds.yaml
ステップ ③: AWS Load Balancer ControllerのPodが起動していることを確認する
helm installを実行すると、デプロイメントのマニュフェストファイルが作成され、AWS Load Balancer Controller用のPodが起動しています。
以下のコマンドで、AWS Load Balancer Controller用のデプロイメントが作成されているかを確認します。出力が以下の画像のようになっていれば、作成は成功しています。
$ kubectl get deployment -n kube-system aws-load-balancer-controller
また、以下のコマンドでAWS Load Balancer ControllerのPodが起動しているかを確認します。出力が以下の画像のようになっていれば、正常に起動しています。
$ kubectl get pods -A
以上で、AWS Load Balancer Controllerのインストールは完了です。
AWS Load Balancer ControllerのPodが正常に起動しました。これにより、KubernetesからALBの作成や管理が可能になります。
次に、ALBを作成するためのマニフェストファイルを作成していきます。
その前に、「名前空間の作成」、「Nginx Podのデプロイ」、「ALB（Ingress）と関連付けるClusterIPサービスの作成」、「CoreDNSのロールアウト」を実施します。
以下のコマンドを実行し、Fargateプロファイルで指定した名前空間「fargate-nodes」を作成します。
Fargateプロファイルを作成しても、名前空間は自動的には作成されないため、手動で作成する必要があります。
$ kubectl create namespace fargate-nodes
以下のデプロイメントのマニュフェストファイルをデプロイして、NginxのPodを起動していきます。
fargate-nodes 名前空間内に、1つのPod（replicas: 1）をデプロイします。
このPodには、nginx:latestのコンテナが 1つ含まれており、ポート80で通信を受け付けるよう設定されています。
apiVersion: apps/v1
kind: Deployment
metadata:
name: "nginx-deployment"
namespace: "fargate-nodes"
spec:
replicas: 1
selector:
matchLabels:
app: "nginx"
template:
metadata:
labels:
app: "nginx"
spec:
containers:
- name: "nginx-container"
image: nginx:latest
imagePullPolicy: Always
ports:
- containerPort: 80
$ kubectl apply -f deployment.yaml
Podが正常に起動すれば、以下の画像のように出力されます。
以下のサービスのマニュフェストファイルをデプロイして、ClusterIPサービスをデプロイしていきます。
ClusterIPタイプの内部サービスで、同じクラスター内の他のリソース（ALB（Ingress））がClusterIP経由で Nginx Podにアクセスできるようにしています。
apiVersion: v1
kind: Service
metadata:
name: ingress
namespace: fargate-nodes
labels:
app: nginx
spec:
ports:
- port: 80
targetPort: 80
name: http
selector:
app: nginx
$ kubectl apply -f service.yaml
正常に作成されれば、以下の画像のように出力されます。
EKSクラスターを作成すると、「CoreDNS」と「metrics-server」のPodが自動的に作成されます。
しかし、デフォルトの状態ではこれらのPodを実行するノードが存在しないため、特に何もしていなければ、Podは「PENDING状態」のままとなっています。
以下のコマンドで実行して、CoreDNSをロールアウトします。Fargateプロファイルで指定した名前空間「kube-system」が存在すればロールアウトは実行されます。
kubectl rollout restart deployment coredns -n kube-system
ロールアウトが正常に実行されれば、以下の画像のようにSTATUSが「Running状態」になります。
CoreDNSが正常起動していないと、サービスアカウントにアタッチしたIAMロール（sts.ap-northeast-1.amazonaws.com）への DNS解決ができず、ALBの作成が失敗しますので、必ず実行しましょう。
これで、ALBを作成するための準備が整いました。必要なPodも全て「Running状態」となっています。
EKSのコンソール画面からも、PodとNodeの起動が確認できます。
以下のマニュフェストファイルをデプロイして、Ingressサービスをデプロイしていきます。
fargate-nodes名前空間にIngressリソースを作成します。アノテーションには、インターネットからアクセス可能なALBを指定し、パス「/」へのリクエストを処理するように設定します。
また、ALBのヘルスチェックには指定されたパスを使用し、HTTPステータスコード200, 201, 302を成功として扱うように設定します。ALBのターゲットタイプにはipを指定する必要があるため、ターゲットがIPアドレスであることを指定します。
ALBのルールとして、「/」パスへのHTTPリクエストをClusterIPサービスのポート80に転送する設定を行います。
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: alb
annotations:
ingressclass.kubernetes.io/is-default-class: "true"
spec:
controller: "ingress.k8s.aws/alb"
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
alb.ingress.kubernetes.io/scheme: "internet-facing"
alb.ingress.kubernetes.io/healthcheck-path: "/"
alb.ingress.kubernetes.io/success-codes: "200,201,302"
alb.ingress.kubernetes.io/target-type: "ip"
name: ingress
namespace: fargate-nodes
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: ingress
port:
number: 80
$ kubectl apply -f ingress.yaml
正常にALBがデプロイされれば、以下の画像のように出力されます。
AWSコンソール画面上からもALBの作成が確認できます。
では、記載されているALBのDNS名に接続してみますと、Nginxのデフォルト画面が表示され無事アクセスすることはできました。
以上、AWS Load Balancer Controllerを使用した EKS on Fargate + ALBの設定を実装しました。
今回の記事では、AWS Load Balancer Controllerを使用したEKS on FargateとALBの設定方法について記載しました。
実際に記事を書く過程で、EKSとFargateの組み合わせがいかに効率的にスケーラブルなコンテナ管理を提供するか、またALBを使ってトラフィックを柔軟に管理できる利点を再確認できました。
一方で、AWS Load Balancer Controllerのインストールに関しては、いくつか分かりづらいところがありました。
今回、Helmを使用してAWS Load Balancer Controllerをインストールしましたが、ALB Ingress Controllerによるインストール方法も存在しており、現在は非推奨となっているようです。
そのため、こちらの方法ではコントローラーが正常に起動せず、インストールがうまく進まない場合もありました。
Amazon EKS on Fargate で ALB Ingress Controller を使用する
現在では、最新のAWS Load Balancer Controllerの使用が推奨されていますので、現在では今回紹介した方法でインストールを行っていただくのが最適です。
では、また別の記事を執筆しますので、引き続きよろしくお願いいたします。
ありがとうございました。
クラウドインテグレーション部
クラウドソリューション2課
川井 康敬