AWSでKubernetesを利用する場合、Ingress Controllerの選択肢にはaws-alb-ingress-controllerやkube-ingress-aws-controller、nginx-ingressなどがあります。
aws-alb-ingress-controllerやkube-ingress-aws-controllerではKubernetesのレイヤでALBを管理できる反面、シンプルな構成しかサポートされていません。例えば、aws-alb-ingress-controllerでは複数のIngressを1つにALBに集約することができません。また、両者ともインターネットとVPC内部に同一のFQDNでサービスを提供する構成を実現できません*1。
本稿では、nginx-ingressを利用して複数ドメインを1つのALBに集約する構成を説明します。ここでは簡単のためワイルドカードドメインで説明しますが、同じ方法で複数のドメインを集約することも可能です。
設計
具体的には、以下のようにKubernetesリソースとAWSリソースを構成します。
- nginx-ingressのServiceをNodePortで公開する。
- ALB Target GroupにKubernetes WorkerのAuto Scaling Groupをアタッチし、転送先をNodePortに設定する。
- ALB ListenerにワイルドカードドメインのSSL証明書をアタッチする。
- ALBにSecurity Groupをアタッチする。
- Route53 Hosted ZoneにワイルドカードドメインのAレコードを作成する。
上記にInternal ALBやRoute53 Private Hosted Zoneを追加するとインターネットとVPC内部に同一のFQDNでサービスを提供する構成を実現できます。
kopsでKubernetesを管理する場合の構成を下図に示します。EKSの場合もおおよそ同じになるはずです。
例えば、Route53やALBのワイルドカードドメインを *.dev.example.com とした場合、www.dev.example.com に対するトラフィックは以下の流れで転送されます。
- Route53が
www.dev.example.comに対応するALBのAレコードを返す。 - ALB Listenerは
*.dev.example.comのSSL証明書を利用してネゴシエーションを行う。 - ALB Target GroupはKubernetes WorkerのNodePortにトラフィックを転送する。
- nginx-ingressはHostヘッダとパスでトラフィックの転送先を決定する。例の場合は
www.dev.example.comに対応するServiceにトラフィックを転送する。 - アプリケーションのPodにトラフィックが到達する。
もし、Hostヘッダとパスに対応するServiceが見つからない場合、nginx-ingressはDefault Backendにトラフィックを転送します。
Helmfile, kops, Terraformによる構成管理
nginx-ingressはHelm chartを利用すると簡単に導入できます。Helmの構成管理にHelmfileを利用する場合は以下のようになります。メモリサイズやタイムアウトなどはアプリケーションの特性に合わせて修正してください。
releases: - name: nginx-ingress namespace: kube-system chart: stable/nginx-ingress values: - rbac: create: true controller: replicaCount: 2 resources: limits: memory: 128Mi requests: memory: 128Mi service: type: NodePort nodePorts: http: 30080 config: proxy-read-timeout: "180" proxy-send-timeout: "180" # Large request header (e.g. OIDC proxy) proxy-buffer-size: "64k" # Large request body (e.g. file upload) proxy-body-size: "512m" server-tokens: "false" defaultBackend: replicaCount: 2 resources: limits: memory: 16Mi requests: memory: 16Mi
kopsでKubernetesを管理する場合、kopsとTerraformが管理するリソースはそれぞれ下表のようになります。
- kopsが管理するリソース
- Terraformが管理するリソース
Terraformからkopsのリソースを参照するにはNameタグ、もしくはKubernetesクラスタのタグ（kubernetes.io/cluster/name=owned）を利用できます。例えば、Instance Group nodes-ap-northeast-1a に対応するAuto Scaling Groupを参照するには以下のようにNameタグを利用します。
# Auto Scaling Group for the Kubernetes nodes data "aws_autoscaling_groups" "kops_nodes" { filter { name = "key" values = ["Name"] } filter { name = "value" values = ["${formatlist("nodes-%s.%s", data.aws_availability_zones.available.names, var.kubernetes_cluster_name)}"] } }
Helmfile, kops, Terraformによる実装をGitHubの int128/kops-terraform-starter に置いているので参考にしてください。
評価
この構成は小規模で中央集権的な管理を行うクラスタに向いています。多数のチームが1つのクラスタを共用する場合は、Kubernetesのレイヤで各チームが自律的にALBを管理する方がスムーズに運用できるでしょう。
この構成にはいくつかの課題があります。
まず、すべてのトラフィックがNodePortのNGINXを経由してアプリケーションのPodに到達するため、レイテンシが大きくなります。ALBからアプリケーションのNodePortに直接転送する方式（aws-alb-ingress-controller）の方がレイテンシは小さくなると考えられます。
また、高負荷やメモリリークなどでNGINXに障害が発生するとすべてのトラフィックに影響します。トラフィックが増えた場合やWebSocketを扱う場合の知見はPain(less) NGINX Ingressが非常に参考になります。
複数のInstance Groupや複数のALBを扱いたい場合はTerraformの記述が複雑になります。その場合はkube-ingress-aws-controllerを使うとよいでしょう。EC2とALBの対応を自動的に管理してくれます。また、ALBとSecurity Groupの対応はタグで管理できます。
See Also
- aws-alb-ingress-controller: https://qiita.com/koudaiii/items/2031d67c715b5bb50357
- kube-ingress-aws-controller: https://qiita.com/mumoshu/items/a3e1e0f808a7109e5212
*1:kube-ingress-aws-controllerでは同じルールのIngressをinternet-facing/internalに対して重複定義することで可能です。 https://github.com/zalando-incubator/kube-ingress-aws-controller/issues/114