AWS Load Balancer Controller を使用した Amazon EKS on Fargate + ALB 設定

はじめに

クラウドインテグレーション部、
クラウドソリューション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

今回必要な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を作成する必要があります。

〇 ALBとその他の構成

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をセットアップするために、必要なツールをインストールしていきます。

〇 AWS CLI インストール

Amazon Linux 2023のAMIでは、AWS CLIはデフォルトでインストールされています。

$ aws --version

AWS CLIがインストールされていない場合は、以下のAWS公式ドキュメントを参照し実行ください。
AWS CLI の最新バージョンのインストールまたは更新

〇 kubectl インストール

ステップ ①: 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がインストールされているかどうかを確認

以下のコマンドで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クラスター作成を行っていきます。

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ロールおよび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オートモードは「無効」、クラスター名は「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分程かかります。作成が問題なく完了すると、ステータスは以下の画像のように「アクティブ」と表示されます。

〇 Fargateプロファイル

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 Load Balancer Controllerのインストールは、以下のAWS公式ドキュメントを参照に実行していきます。
Helm による AWS Load Balancer Controller のインストール

まず、このドキュメントに記載された前提条件である「OIDCプロバイダーの作成」および「Helmのインストール」を実行していきます。

〇 OIDC プロバイダーの作成

以下のコマンドは、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のインストール

以下のコマンドで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

〇 Helmによる AWS Load Balancer Controller のインストール

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のインストールは完了です。

ALBの設定とデプロイ

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のデプロイ

以下のデプロイメントのマニュフェストファイルをデプロイして、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が正常に起動すれば、以下の画像のように出力されます。

〇 ALB（Ingress）と関連付けるClusterIPサービスの作成

以下のサービスのマニュフェストファイルをデプロイして、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

正常に作成されれば、以下の画像のように出力されます。

〇 CoreDNSのロールアウト

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作成と接続確認

これで、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課
川井　康敬