AWSのロードバランサー「ALB Ingress Controller」で公開アプリのルーティング：マネージドサービスで始めるKubernetes入門（4）（1/4 ページ）

本連載では、AWSが提供するマネージドKubernetesサービスの「EKS」を用いてアプリを公開する方法を紹介している。第4回は、ロードバランサー「ALB Ingress Controller」について。

[上野一義，株式会社PIVOT]

ALB（Application Load Balancer）とは？

　Amazon Web Services（AWS）が提供するマネージドKubernetesサービス「Amazon Elastic Kubernetes Service（EKS）」を使用して、「Kubernetes」の基本的な使用方法を理解することを目指す本連載「マネージドサービスで始めるKubernetes入門」。前回まで、EKSを用いてアプリを公開する方法を紹介しています。

　アプリを外部に公開するには、連載第2回で行ったように、「type: Load BalancerなService」を使う方法があります。これは、HTTP（S）によるアクセスをロードバランサーで受け、ロードバランサーがKubernetes内に複数存在するアプリ群からServiceのマニフェストファイルで指定したmatchLabelsにひも付くPodへルーティングする仕組みです。アプリをデプロイし、Serviceをロードバランサー（Elastic Load Balancing：ELB）で作成することで、外部から接続できるようになっていました。

　「type: Load BalancerなService」で作成されるELBは、1つのFQDN（Fully Qualified Domain Name）に対してルーティングを行います。新しい外部公開設定が増えるたびにServiceを追加するので、ELBインスタンスも追加されていきます。前回は、アプリが1つだったため作成されたELBも1つでしたが、アプリを増やしたい場合は、Serviceを都度増やすことになるためELBも増えていきます。

アプリ数と同じ数のELBが必要

　「2つくらいであればELBでいい」と思うかもしれませんが、アプリが100個、1000個と増えた場合は、どうでしょう？　ELBが100個、1000個と増えると、当然コストも増えていきます。またELBは、IPアドレスとポート番号の組み合わせ単位でルーティングを行います。そのため、同じIPアドレスや同じドメイン配下に複数のアプリが存在するような場合に対応できません。例えば、「http://example.com/」の配下に、「/app1」「/app2」という2つの違うパスに対して、他のアプリにルーティングすることができません。

　これを実現できるようにしたのがALB（Application Load Balancer）というロードバランサーです。上記を例にすると、/app1の場合は、アプリ1へ。/app2の場合は、アプリ2へルーティングできるようになります。

ALBによるルーティングのイメージ

　またELBがドメインレベル（L4）でのルーティングまでしか対応できなかったのに対して、ALBは、パスベース（L7）でのルーティングが可能です。1つのALBで複数のドメイン＋パスのルーティングが可能となります。

　ALBのメリットをまとめると、下記のようになります。

• 複数のルーティングを1つのALBインスタンスで実現できるので費用を抑えることができる（ロードバランサーインスタンスの個数を減らせる）
• L7ベースになることで細かいルーティング操作を行える

ALB Ingress Controller

　ただし、ALBの作成とURLのひも付けは、AWSのコンソールパネルから手動で行う必要があります。100個のサービスを公開するには、100個のルーティング先を指定しなければなりません。

　ここで「ALB Ingress Controller」の登場となります。ALB Ingres Controllerは、手動で行う作業を設定ファイルに記述することで自動的に行ってくれるのです。ALB Ingress Controllerを有効にするには、大きく以下の4ステップを行います。

1. AWS Identity and Access Management（IAM）でワーカーノードのロール用にポリシーを反映する
2. IAMでALB Ingress Controller用のロールを作成する
3. インストール
4. Kubernetesが使用しているサブネットへタグ付け

　今回は、この手順を紹介し、アプリを公開してみます。