ALB Ingress Controller is reached v1.0.0

ALB Ingress Controller is reached v1.0.0:

AWS ALB Ingress Controller

Kubernetes(以下k8s)でALBを使うには aws-alb-ingress-controller を利用するのが一般的かと思いますが、先日このようなリリースがありました。

Amazon EKS Adds ALB Support with AWS ALB Ingress Controller

内容は記事を読んで頂ければいいのですが、要約すると下記の通りなので、文字通り Amazon EKS (以下 EKS ) が ALB をサポートしたと受け取るとちょっと実情と差があるのかと。。

• aws-alb-ingress-controller がv1.0.0を迎えProduction Readyになった
• AWS の開発チームが Contribute していく

基本的には docs/guide/controller/setup.md あたりに従って進めれば利用可能なのですが、いくつかドキュメントが分散していて気になる箇所があるので、今回はそのあたりについて書きたいと思います。

Prerequisites

kubelet

オプションに --cloud-provider=aws がついている必要があるが、 EKS や kops で構築している場合は大丈夫かと思います。

IAM

node もしくは pods ( kube2iam を使う必要がある) に ALB を操作するための権限を付与する必要があります。付与する IAM Policy は こちら。

Installation

Helm と Kubectl でちまちまやる方法の２つがありますが、内容確認しながら進めたい場合は Kubectl の方がいい気がします。

やる事的には、

• RBAC roles manifest のデプロイ
• ALB ingress controller manifest のデプロイ

だけなのですが、alb-ingress-controller.yaml 内でクラスタ名を記述している箇所があるので、修正する必要があります。

※ ただ、こちらの issue で動的にクラスタを判別させるようにしたいとあるので、将来的に変わりそうです。

Configuration 関連

Ingress annotations

ALB の各種設定は annotations として設定可能になっています。設定可能なパラメータはこちらの ドキュメント から確認できます。

subnet-auto-discovery

annotations から設定することも出来ますが、 ALB 作成の度に指定するのではなくタグのパラメータを用いて自動判別させることも可能です。詳しくは subnet-auto-discovery に載っています。

注意点としては、EKS を利用していると Control Plane 作成時に選択するサブネットに自動的に kubernetes.io/cluster/$CLUSTER_NAME=shared タグが付与されます。これはこれでいいのですが、インターネットに接していない Private Subnet に node を配置していると、 ALB を展開したいサブネットにはタグが付与されていないことになるので、手動で対応する必要があります。kubernetes.io/role/elb , kubernetes.io/role/internal-elb タグについても同様に付与頂く必要があります。

target-type

ALB で参照可能なリソースには instance と ip がありますが、 EKS を利用している場合はデフォルトで amazon-vpc-cni-k8s が有効になっているので、ip の方がいいかと思います。（いわゆるダブルホップ問題も解消できるので）

あとがき

本投稿は、個人の意見であり、所属する企業や団体は関係ありません。お約束です。

Stack Overflow 等を見ていると、IAM や Subnet まわりの設定を忘れて動かないことが多いようなので、k8s 外の操作をまとめてやってくれる CloudFormation 等があるといいのかなぁと思いました。

また、公開されてる IAM Poricy が結構強めの権限がついているので、編集や削除については kubernetes.io/cluster/$CLUSTER_NAME タグが付いてるもののみ許可するとかの方が安全かもしれません。