NGINX Ingressで複数ドメインを1つのALBに集約する

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の場合もおおよそ同じになるはずです。

f:id:int128:20180718102825p:plain

例えば、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が管理するリソース
- VPC, Subnet, Route Table, Internet Gateway
- Auto Scaling Group (master), Security Group (API), Security Group (SSH)
- Auto Scaling Group (node), Security Group (SSH)
Terraformが管理するリソース
- ALB, Listener, Target Group, Security Group (HTTPS)
- Route53 Hosted Zone, Route53 RecordSet
- ACM Certificate

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の対応はタグで管理できます。

GeekFactory

int128.hatenablog.com

NGINX Ingressで複数ドメインを1つのALBに集約する

設計

Helmfile, kops, Terraformによる構成管理

評価

See Also