過去に検証で色々Kong Gatewayを立ててきたが、過去に投稿したものは検証レベルで実運用からは少し距離があったので、今回は実運用に使えそうな設定値でKong Gatewayを立ててみる。
※長いです。

前提

以下を前提条件とする。

デプロイ先はEKSでクラスタは構築済み
Type: LoadBalancerが利用できる

構築対象は以下とする。

Kong Gateway Enterprise版
Helmにより構築

Kubernetes前提としたが、それ以外の環境でもパラメータは使えるところがあるかと思うので、参考にしてもらえると幸いである。

実運用で使える設定

実運用に使える、ということで以下の要素を取り入れる。

デプロイにはHybridモードを採用
RBACを有効化し、Kong ManagerのログインにBasic認証を利用
~~CP/DPの証明書の共有はPKIモードを採用~~
証明書はLet's Encryptを利用
~~証明書の管理にはcert-managerを利用~~
DPは冗長化し、Podも分散配置する
PDBでサービス断しないようにする
Ingress ControllerはContourを利用
スケール観点でHPAを利用
リソースの使いすぎに備えてrequests, limitsを設定
Prometheus向けにServiceMonitorを有効化する

PKIモードについてはLet's Encryptでは.svcのような内部ドメインへの払い出しが出来ないっぽいので断念した。
証明書の管理はcert-managerに任せようとしたが、権限の都合上Route53への操作が難しそうだったので今回は断念した。
やれそうな人はせっかくKongのHelm設定にcert-manager向け設定があるので、「Kubernetes cert-managerでRoute53で作成したドメインの証明書を作成し、Ingressで利用する。」などの記事を参考に入れるといいと思う。

冗長化の観点についてはDPのみ記載しているが、CPはサービス断になってもDPの動作（リクエストのプロキシ）には影響しないため、ここでは省略した。
必要な場合はDP側の設定をCPに持ち込めば上手く動作する。

Ingress ControllerについてはKong Ingress Controllerを利用しないのか、と言われそうだが、汎用性を考慮して今回は未採用とした。
またEKSだとALB Ingress Controllerが選択肢となるが、環境依存しないものを使いたかったのでContourを採用した。
その他検討すべき要素はありそうだが、最低限の設定としては十分だと思うので、一旦この設定でKong Gatewayを構築してみる。

ちなみにSecurityContext周りはデフォルトでいい感じになっているので、個別の要件がなければ特に設定する必要はないと思う。

作業は以下の順番で行う。

Contourの導入
Let's Encryptの証明書作成
ControlPlaneとDataPlane間の通信用証明書の作成
Kong GatewayのControl Planeのデプロイ
Kong GatewayのData Planeのデプロイ
動作確認

1. Contourの導入

あまり特筆することはないのでコマンドだけ。
Contourのインストールは以下。

helm repo add bitnami https://charts.bitnami.com/bitnami
helm install contour bitnami/contour --namespace projectcontour --create-namespace

Contourについては念の為kubectl get svc -n projectcontourを実行し、EXTERNAL-IPに何かしらが適切に割り当てられていることを確認する。
あとkubectl get ingressclassでcontourがいることも確認しておく。

※追記：
Bitnamiのポリシー変更により、上記手順でContourが使えないように見える。
ここでは代わりに別のIngress ControllerとしてTraefikのインストール手順を書いておく。

helm install traefik oci://ghcr.io/traefik/helm/traefik -n traefik --create-namespace

2. Let's Encryptの証明書作成

HTTP-01チャレンジはLet's Encryptの説明によるとワイルドカード証明書が利用できないので、ここではDNS-01チャレンジを利用して作成する。

MY_DOMAIN='hogehoge.info'
MY_EMAIL="hogehoge@hogehoge.info"
sudo certbot certonly --manual \
  --preferred-challenges dns-01 \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -m $MY_EMAIL \
  -d "*.${MY_DOMAIN}"

実行すると以下のようにTXTレコードで使う値が表示されるのでDNS側で設定し、証明書を作成する。

Please deploy a DNS TXT record under the name:

_acme-challenge.hogehoge.info.

with the following value:

vOpF9-m36eg1xXZBTbxto3-OEHZeUteqK0Ah81TjK48

作成後、証明書を退避し、自身が参照できるよう所有者等を変更しておく。

mkdir -p ./certs/
sudo cp /etc/letsencrypt/live/${MY_DOMAIN}/cert.pem ./certs/tls.crt
sudo cp /etc/letsencrypt/live/${MY_DOMAIN}/privkey.pem ./certs/tls.key
sudo chown $(who -m | awk '{print $1}'):$(id -gn $(who -m | awk '{print $1}')) ./certs/*

作成した証明書をKong Gatewayで参照できるよう、Secretとして登録する。
最初にKong Gatewayを展開するNamespaceを作成する。

kubectl create ns kong

Secretを作成する。

kubectl create secret tls kong-tls-cert \
  --cert=./certs/tls.crt \
  --key=./certs/tls.key \
  -n kong

3. ControlPlaneとDataPlane間の通信用証明書の作成

上述のように内部通信ではLet's Encryptの通信は使いづらいので、ここでは別に自己証明証明書を作成する。
作成にはkong CLIを利用する。

docker run --rm \
  -v $(pwd)/certs:/certs \
  kong/kong-gateway:latest \
  kong hybrid gen_cert /certs/kong-cluster.crt /certs/kong-cluster.key

こちらもKong Gatewayから参照できるようSecretにする。

kubectl create secret tls kong-cluster-tls-cert \
  --cert=./certs/kong-cluster.crt \
  --key=./certs/kong-cluster.key \
  -n kong

4. Kong GatewayのControl Planeのデプロイ

今回はEnterprise版で起動するため、Enterpriseのライセンスファイルを登録する。

LICENSE_FILE=~/license.json
kubectl create secret generic kong-enterprise-license \
  --from-file=license=$LICENSE_FILE \
  -n kong

また、パスワード関連はセキュリティの観点からファイルで保存したくないので、Secretで登録する。
最初にAdminAPIのSecretを作成する。初期パスワードはkongpassとした。

kubectl create secret generic kong-enterprise-superuser-password \
  --from-literal=password=kongpass \
  -n kong

次にDBのパスワードもSecretで作成する。こちらもパスワードはAdminAPIにあわせた。

kubectl create secret generic kong-database-password \
  --from-literal=password=kongpass \
  -n kong

次にvalues.yamlを作成する。
CPには以下の観点を盛り込む。

デプロイにはHybridモードを採用
RBACを有効化し、Kong ManagerのログインにBasic認証を利用
証明書はLet's Encryptを利用
Ingress ControllerはContourを利用
リソースの使いすぎに備えてrequests, limitsを設定
Prometheus向けにServiceMonitorを有効化する

先程も述べたが、冗長化観点や対障害性の向上に関する設定は、CPでは不要と判断して設定は省略した。

作成したvalues.yamlは以下となる。

cp.yaml（クリックして表示）

cp.yaml

image:
  repository: kong/kong-gateway

secretVolumes:
- kong-cluster-tls-cert

env:
  role: control_plane
  database: postgres
  pg_host: kong-aws-cp-postgresql.kong.svc
  pg_database: kong
  pg_password: kong
  pg_user: kong
  cluster_cert: /etc/secrets/kong-cluster-tls-cert/tls.crt
  cluster_cert_key: /etc/secrets/kong-cluster-tls-cert/tls.key
  enforce_rbac: "on"
  admin_gui_auth: basic-auth
  admin_gui_session_conf: "{\"secret\":\"secret\",\"rolling_timeout\": 3600}"
  password:
    valueFrom:
      secretKeyRef:
        name: kong-enterprise-superuser-password
        key: password

resources:
  limits:
   cpu: 2
   memory: 4G
  requests:
   cpu: 1
   memory: 2G

admin:
  enabled: true
  type: ClusterIP
  http:
    enabled: true
    containerPort: 8001
    servicePort: 8001
  tls:
    enabled: false
  ingress:
    enabled: true
    ingressClassName: contour
    tls: kong-tls-cert
    hostname: admin.hogehoge.info

manager:
  enabled: true
  type: ClusterIP
  http:
    enabled: true
    containerPort: 8002
    servicePort: 8002
  tls:
    enabled: false
  ingress:
    enabled: true
    ingressClassName: contour
    tls: kong-tls-cert
    hostname: kong.hogehoge.info

cluster:
  enabled: true
  tls:
    enabled: true
    servicePort: 8005
    containerPort: 8005

clustertelemetry:
  enabled: true
  tls:
    enabled: true
    containerPort: 8006
    servicePort: 8006

proxy:
  enabled: false

enterprise:
  enabled: true
  license_secret: kong-enterprise-license

ingressController:
  enabled: false

postgresql:
  enabled: true
  auth:
    database: kong
    username: kong
    password: kong

serviceMonitor:
  enabled: true
  labels:
    release: kube-prometheus-stack

それぞれ説明する。

デプロイにはHybridモードを採用

以下のあたりがCP向けのHybridモードのための設定となる。

secretVolumes:
- kong-tls-cert
：（省略）
env:
  role: control_plane
  ：（省略）
  cluster_cert: /etc/secrets/kong-cluster-tls-cert/tls.crt
  cluster_cert_key: /etc/secrets/kong-cluster-tls-cert/tls.key
：（省略）
clustertelemetry:
  enabled: true
  tls:
    enabled: true
    containerPort: 8006
    servicePort: 8006

roleにcontol_planeを指定することで、展開するKong GatewayをControl Planeとして動作するよう指定する。
また、cluster_cert、cluster_cert_keyでDPと通信する際に使う証明書を指定する。
これはSecretから読み込むため、secretVolumesで先程作成したSecretをマウントするよう指定する。
clustertelemetryに関しては昔あったVitals向けの設定でDPからCPにテレメトリ情報を送るための設定であり、今はなくても良さそうな気がするが、ないと上手く動かなかったので入れている。

RBACを有効化し、Kong ManagerのログインにBasic認証を利用

RBACを有効にするにはenforce_rbac、admin_gui_auth、admin_gui_session_confを設定する。

  enforce_rbac: "on"
  admin_gui_auth: basic-auth
  admin_gui_session_conf: "{\"secret\":\"secret\",\"rolling_timeout\": 3600}"
  password:
    valueFrom:
      secretKeyRef:
        name: kong-enterprise-superuser-password
        key: password

RBACの初期ユーザであるkong_adminのパスワードは先程設定したSecretから読み込むようにしている。

証明書はLet's Encryptを利用 / Ingress ControllerはContourを利用

managerやadminなどのControl Planeが提供するユーザ向けインターフェースの設定ではIngressが以下の様に指定できる。

  ingress:
    enabled: true
    ingressClassName: contour
    tls: kong-tls-cert
    hostname: admin.hogehoge.info

ingressClassNameでcontourを指定し、tlsに作成したSecretを指定する。

リソースの使いすぎに備えてrequests, limitsを設定

CPの場合は通常はリソースの使いすぎは考えにくいが、バグ等があった場合を考慮して一応設定しておく。
設定は以下のようになる。

resources:
  limits:
   cpu: 2
   memory: 4G
  requests:
   cpu: 1
   memory: 2G

CPに関してはDPが一斉に再接続するようなケースでもない限りリソースは使わないので、あまり大きくしておく必要はないと思う。

Prometheus向けにServiceMonitorを有効化

Prometheus Operatorが使える前提でServiceMonitorを有効化し、Prometheusがスクレイピング出来るようにする。

serviceMonitor:
  enabled: true
  labels:
    release: prometheus-stack

labelsではkind: PrometheusでデプロイされているPrometheusが何のラベル名を見てServiceMonitorを検出しているかを確認した上で設定する。詳細はこちらを参考。
あと後述するが、これだけだとServiceMonitorが監視対象サービスと識別するためのServiceのラベル(enable-metrics=true)が付与されないので、構築後にラベルを手動で追加する必要がある。

なお、Prometheusがない人は代わりにStatus APIを有効化すると使えるかもしれない。ただし、Status APIはHelmでServiceを公開しないようなので、手動でServiceを作る必要がある。

その他

IngressでのTLS終端

ContourがIngressリソースではTLSパススルーに対応していない（カスタムリソースのkind: HTTPProxyなら利用可）。
なので、各サービスでは以下の設定を入れることでIngressでTLSを終端し、内部ではHTTPを使うように設定している。

  http:
    enabled: true
  tls:
    enabled: false

ライセンスの適用

以下でSecretからライセンスファイルを読ませてライセンスを適用している。

enterprise:
  enabled: true
  license_secret: kong-enterprise-license

DBとAdminAPIのパスワードの読み取り

DB、AdminAPIのSecretは以下のような感じでvalueFromで指定できるので、これを使ってSecretから読み取って設定している。

  password:
    valueFrom:
      secretKeyRef:
         name: kong-enterprise-superuser-password
         key: password

5. Kong GatewayのData Planeのデプロイ

次にvalues.yamlを作成する。
DPには以下の観点を盛り込む。

デプロイにはHybridモードを採用
証明書はLet's Encryptを利用
DPは冗長化し、Podも分散配置する
PDBでサービス断しないようにする
Ingress ControllerはContourを利用
スケール観点でHPAを利用
リソースの使いすぎに備えてrequests, limitsを設定
Prometheus向けにServiceMonitorを有効化する

作成したvalues.yamlは以下となる。

dp.yaml（クリックして表示）

dp.yaml

image:
  repository: kong/kong-gateway

secretVolumes:
- kong-cluster-tls-cert

env:
  role: data_plane
  database: "off"
  cluster_control_plane: kong-aws-cp-kong-cluster.kong.svc:8005
  cluster_telemetry_endpoint: kong-aws-cp-kong-clustertelemetry.kong.svc:8006
  cluster_cert: /etc/secrets/kong-cluster-tls-cert/tls.crt
  cluster_cert_key: /etc/secrets/kong-cluster-tls-cert/tls.key

 resources:
   limits:
     cpu: 2
     memory: 4G
   requests:
     cpu: 1
     memory: 2G

podDisruptionBudget:
  enabled: true
  maxUnavailable: 1

autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 3

topologySpreadConstraints:
- maxSkew: 1
  topologyKey: kubernetes.io/hostname
  whenUnsatisfiable: DoNotSchedule

proxy:
  enabled: true
  type: ClusterIP
  http:
    enabled: true
    containerPort: 8000
    servicePort: 8000
  tls:
    enabled: false
  ingress:
    enabled: true
    ingressClassName: contour
    tls: kong-tls-cert
    hostname: proxy.hogehoge.info

enterprise:
  enabled: true
  license_secret: kong-enterprise-license

ingressController:
  enabled: false

manager:
  enabled: false

serviceMonitor:
  enabled: true
  labels:
    release: kube-prometheus-stack

それぞれ説明する。

デプロイにはHybridモードを採用

以下のあたりがDP向けのHybridモードのための設定となる。

secretVolumes:
- kong-tls-cert
：（省略）
env:
  role: data_plane
  database: "off"
  cluster_control_plane: kong-aws-cp-kong-cluster.kong.svc:8005
  cluster_telemetry_endpoint: kong-aws-cp-kong-clustertelemetry.kong.svc:8006
  cluster_cert: /etc/secrets/kong-cluster-tls-cert/tls.crt
  cluster_cert_key: /etc/secrets/kong-cluster-tls-cert/tls.key

CPの時と異なる点として、databaseに関する設定を無効化しているのと、cluster_control_planeとcluster_telemetry_endpointで接続先のCPを指定している点がある。
証明書に関しては同じ証明書を使うので、CPと同様にkong-tls-certを指定する。

証明書はLet's Encryptを利用 / Ingress ControllerはContourを利用

CPの設定同様にproxyでもIngressが以下の様に指定できる。

  ingress:
    enabled: true
    ingressClassName: contour
    tls: kong-tls-cert
    hostname: proxy.hogehoge.info

こちらもCP同様にingressClassNameでcontourを指定し、tlsに作成したSecretを指定する。

DPは冗長化し、Podも分散配置する

Podの分散配置にはtopologySpreadConstraints を利用する。
（Affinityも利用できるが、ここでは設定がシンプルになるtopologySpreadConstraintsを採用）

topologySpreadConstraints:
- maxSkew: 1
  topologyKey: kubernetes.io/hostname
  whenUnsatisfiable: DoNotSchedule

maxSkewはノードごとの偏りの差（許容できるPod数の差分）を表すパラメータであり、1にしておけば基本分散されて配置される。
topologyKeyは分散に利用するキーで、EKSの場合ノードのラベルにhostnameが付与されるので、これをキーとして分散させる。AZ単位でも分散させたい場合はtopology.k8s.aws/zone-idも追加で書いておくと良さそう。
whenUnsatisfiableは条件を満たさない場合は配置しない設定で、これは強すぎる気もするので環境に応じてScheduleAnywayに変更するとよい。

PDBでサービス断しないようにする

PDB(PodDisruptionBudget)はノードの停止やdrainなどのPodが機能を中断(Disruption)する際に保証される最低Pod数を定義するもので、これを指定しておくとノードのスケールダウン等が発生する時でもサービスの継続性がある程度担保される。
この設定はvalues.yamlでサポートされているので、以下のように書いておけばOK。

podDisruptionBudget:
  enabled: true
  maxUnavailable: 1

最低1つ以上のPodが稼働するようにしている。

スケール観点でHPAを利用

HPA(Horizontal Pod Autoscaler)は高負荷時にPodをスケールアウトして負荷に耐えられるようにするための設定である。
ここでは最低2Pod起動し、かつ高負荷時は3Podまで上がるようにした。

autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 3

スケールの条件はユースケースで変わるので、ここではデフォルトのまま(CPU80%オーバー)としている。

リソースの使いすぎに備えてrequests, limitsを設定

DPの場合はリクエスト数が増えると負荷が上がることが考えられるため、Kong Gateway resource sizing guidelines を参考に以下のような感じで設定した。

resources:
  limits:
   cpu: 2
   memory: 4G
  requests:
   cpu: 1
   memory: 2G

複数Podによる負荷分散を考慮するならrequestsを減らしてもOK。
limitsは環境に応じて要調整となる。

Prometheus向けにServiceMonitorを有効化

こちらもCPと同様にServiceMonitorの有効化設定を入れる。

serviceMonitor:
  enabled: true
  labels:
    release: kube-prometheus-stack

CPと異なり、こちらではDPのServiceに適切にラベルが設定されるので、Prometheusから直ぐにメトリクスが取れるようになる。

動作確認

それぞれのvalues.yamlを使ってKong Gatewayをデプロイする。

helm upgrade -i kong-aws-cp kong/kong -f ./cp.yaml -n kong --wait --debug

helm upgrade -i kong-aws-dp kong/kong -f ./dp.yaml -n kong --wait --debug

起動すると以下のような感じでHybridモードとしてCPとDPが分かれて起動する。

$ kubectl get pod -o wide -n kong
NAME                                READY   STATUS    RESTARTS   AGE     IP               NODE                             NOMINATED NODE   READINESS GATES
kong-aws-cp-kong-79ddf7486d-v756b   1/1     Running   0          3m18s   192.168.7.44     ip-192-168-14-192.ec2.internal   <none>           <none>
kong-aws-cp-postgresql-0            1/1     Running   0          3m2s    192.168.5.244    ip-192-168-19-44.ec2.internal    <none>           <none>
kong-aws-dp-kong-84f68c6f49-4z2kb   1/1     Running   0          3m17s   192.168.2.226    ip-192-168-14-192.ec2.internal   <none>           <none>
kong-aws-dp-kong-84f68c6f49-wf9rn   1/1     Running   0          3m17s   192.168.25.138   ip-192-168-19-44.ec2.internal    <none>

DP Podのデプロイ先ノードも分散されていることが分かる。

次に冗長化観点を確認する。
DPの分散は先程見た通りだが、HPAの観点も改めて確認する。

$ kubectl get hpa -n kong
NAME               REFERENCE                     TARGETS              MINPODS   MAXPODS   REPLICAS   AGE
kong-aws-dp-kong   Deployment/kong-aws-dp-kong   cpu: <unknown>/80%   2         3         2          16m

HPAが適切に設定されていることが確認できた。
PDBも確認できる。

$ kubectl get pdb -n kong
NAME               MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
kong-aws-dp-kong   N/A             1                 1                     43h

resources設定も以下で確認できる。

$ kubectl get pod -o yaml -n kong |grep resources -A 5
      resources:
        limits:
          cpu: "2"
          memory: 4G
        requests:
          cpu: "1"
  ：（省略）

ServiceMonitorは以下で確認できる。

$ kubectl get servicemonitor -n kong
NAME               AGE
kong-aws-cp-kong   43h
kong-aws-dp-kong   43h

ServiceMonitorは問題なく設定されているが、ここでPrometheusにアクセスしてTargetを確認すると、DPしか見えていないことが確認できる。
これはCPのServiceにenable-metrics=trueのラベルが付与されていないためServiceMonitorが対象とするServiceを見つけられないためである。
この対策のため、CPのどれかのServiceに手動でラベルを追加する。
ここではAdmin APIのServiceに追加する。

kubectl label service kong-aws-cp-kong-admin enable-metrics="true" -n kong

これでPrometheusのTargetにCPも追加される。

最後にRBACを確認するためにKong Managerにアクセスする。
アクセスすると認証画面となるので、kong_admin/kongpassでアクセスする。

認証突破後、ブラウザで証明書を確認するとLet's Encryptの証明書が使われていることが確認できる。

一通り、やりたい設定が反映されていることが確認できた。

終わりに

今回実運用でもそこそこ使えそうな設定でKong Gatewayをデプロイした。
設定手順自体は色々あって大変であるが、一度values.yamlを作っておけば次から検証毎にこのファイルを使うだけなので構築は楽が出来ると思う。
ただ、要件によっては設定を変える必要があるので、あくまで参考程度にしてもらえると幸いである。