ALB Ingress Controller is reached v1.0.0

# AWS ALB Ingress Controller
Kubernetes(以下k8s)でALBを使うには [aws-alb-ingress-controller](https://github.com/kubernetes-sigs/aws-alb-ingress-controller) を利用するのが一般的かと思いますが、先日このようなリリースがありました。

##### [Amazon EKS Adds ALB Support with AWS ALB Ingress Controller](https://aws.amazon.com/jp/about-aws/whats-new/2018/11/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](https://github.com/kubernetes-sigs/aws-alb-ingress-controller/blob/master/docs/guide/controller/setup.md) あたりに従って進めれば利用可能なのですが、いくつかドキュメントが分散していて気になる箇所があるので、今回はそのあたりについて書きたいと思います。

# Prerequisites

#### kubelet

オプションに `--cloud-provider=aws` がついている必要があるが、 EKS や [kops](https://github.com/kubernetes/kops) で構築している場合は大丈夫かと思います。

#### IAM

node もしくは pods ( [kube2iam](https://github.com/jtblin/kube2iam) を使う必要がある) に ALB を操作するための権限を付与する必要があります。付与する IAM Policy は [こちら](https://github.com/kubernetes-sigs/aws-alb-ingress-controller/blob/master/docs/examples/iam-policy.json)。

# Installation

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

やる事的には、

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

だけなのですが、[alb-ingress-controller.yaml](https://github.com/kubernetes-sigs/aws-alb-ingress-controller/blob/master/docs/examples/alb-ingress-controller.yaml#L44) 内でクラスタ名を記述している箇所があるので、修正する必要があります。

※ ただ、こちらの [issue](https://github.com/kubernetes-sigs/aws-alb-ingress-controller/issues/726) で動的にクラスタを判別させるようにしたいとあるので、将来的に変わりそうです。

# Configuration 関連

## Ingress annotations

ALB の各種設定は annotations として設定可能になっています。設定可能なパラメータはこちらの [ドキュメント](https://github.com/kubernetes-sigs/aws-alb-ingress-controller/blob/master/docs/guide/ingress/annotation.md) から確認できます。

# [subnet-auto-discovery](https://github.com/kubernetes-sigs/aws-alb-ingress-controller/blob/master/docs/guide/controller/config.md#subnet-auto-discovery)

[annotations](https://github.com/kubernetes-sigs/aws-alb-ingress-controller/blob/master/docs/guide/ingress/annotation.md#subnets) から設定することも出来ますが、 ALB 作成の度に指定するのではなくタグのパラメータを用いて自動判別させることも可能です。詳しくは [subnet-auto-discovery](https://github.com/kubernetes-sigs/aws-alb-ingress-controller/blob/master/docs/guide/controller/config.md#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](https://github.com/kubernetes-sigs/aws-alb-ingress-controller/blob/master/docs/guide/ingress/annotation.md#target-type)

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


# あとがき

本投稿は、個人の意見であり、所属する企業や団体は関係ありません。お約束です。
Stack Overflow 等を見ていると、IAM や Subnet まわりの設定を忘れて動かないことが多いようなので、k8s 外の操作をまとめてやってくれる CloudFormation 等があるといいのかなぁと思いました。
また、公開されてる IAM Poricy が結構強めの権限がついているので、編集や削除については `kubernetes.io/cluster/$CLUSTER_NAME` タグが付いてるもののみ許可するとかの方が安全かもしれません。