Contents
Hybridモードの概要とメリット・制限事項
Hybridモードは、Kong Enterprise の Control Plane(管理機能)と Data Plane(リクエスト処理)を物理的に分離し、中央で設定を一元管理できる構成です。大規模なマルチクラウド・マルチリージョン環境でも同じポリシーを適用できる点が最大の利点です。本節では概念と導入時に留意すべきポイントを整理します。
Hybridモードとは
Hybridモードは、1 つの Control Plane が複数の Data Plane を統括し、TLS とトークンで相互認証する仕組みです。公式ドキュメント(Kong Enterprise Hybrid)に基づき、以下の特徴があります。
- 単一管理:Control Plane で設定・プラグインを登録すると、接続された全 Data Plane に自動配布されます。
- 分散処理:Data Plane は軽量エージェントとして動作し、リクエストは各デプロイ先で処理されます。
メリットと主な制限事項
Hybridモードを採用することで得られる効果と、運用上注意が必要な点を簡潔にまとめました。
- メリット
- 設定変更の即時反映 → 運用負荷が低減。
- マルチクラウド・マルチリージョンで統一された API ガバナンスが実現。
-
Data Plane がステートレスなので、リソース要件が低くスケールアウトが容易。
-
制限事項
- Control Plane と Data Plane の間は常時 TLS 接続が必須で、ネットワーク遅延が大きいと応答時間に影響。
- バージョン互換性の確保が必要 → アップグレードは全体計画に基づいて実施。
- VPC ピアリングや VPN 等、安定したネットワークトポロジーの構築が前提となる。
前提条件と環境準備
Hybrid デプロイを行う前に必要なライセンス取得・インフラ要件・TLS 証明書作成手順を示します。本節では実装前に必ず確認すべきポイントを整理しています。
Enterprise ライセンスの取得方法
Kong Enterprise の Hybrid 機能は有償版のみで利用できます。公式サイトからトライアルまたは購入手続きを行い、enterprise_license ファイル(または環境変数)を入手してください。
- Kong Japan 製品ページ https://jp.konghq.com/products/kong-gateway にアクセス。
- 「無料トライアル」または「購入」ボタンから申請フォームに必要情報を入力。
- 送付されたメールに記載のライセンスキーを
enterprise_licenseとして安全な場所に保存。
Kubernetes クラスタ要件
Control Plane と Data Plane の稼働に最低限必要なリソースは以下の通りです。実際のトラフィックに応じてスケールアウトしてください。
| 項目 | 推奨スペック |
|---|---|
| K8s バージョン | 1.27 以上(公式サポート対象) |
| Control Plane | CPU 2コア、メモリ 4 GiB 以上 |
| Data Plane (ノード) | CPU 1コア、メモリ 2 GiB 以上(スケール可) |
| ストレージ | 永続化不要(ステートレス) |
ネットワーク接続と TLS 証明書の作成手順
Hybrid 接続は mTLS によって保護されます。以下に必須要件と自己署名 CA の作成例を示します。
- 接続要件
-
Control Plane がリッスンする
https://<CP_IP>:8444へ Data Plane からアクセス可能であること(VPC ピアリング、Transit Gateway、または Cloud VPN を使用)。 -
TLS 証明書作成例(OpenSSL)
|
1 2 3 4 5 6 7 8 9 10 11 |
# 1. CA の生成 openssl genrsa -out ca.key 4096 openssl req -x509 -new -nodes -key ca.key -subj "/CN=KongHybridCA" -days 3650 -out ca.crt # 2. Control Plane 用証明書 openssl genrsa -out control.key 2048 openssl req -new -key control.key -subj "/CN=control.kong.local" -out control.csr openssl x509 -req -in control.csr -CA ca.crt -CAkey ca.key -CAcreateserial -days 365 -out control.crt # 3. Data Plane 用証明書(同様に作成し、各クラウドへ配布) |
作成した ca.crt・control.crt·control.key を Control Plane に、Data Plane 用証明書はそれぞれの環境へ配置します。
Control Plane のデプロイ方法
Control Plane は管理機能の集約ポイントです。検証用には Docker Compose、本番向けには Helm Chart が推奨されます。本節では両方の手順を簡潔に示します。
Docker Compose での検証環境構築
開発・テスト段階では以下の docker‑compose.yml を利用すると数分で起動できます。ポイントは Enterprise ライセンス と TLS 証明書 のマウントです。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
version: "3.8" services: kong-control-plane: image: kong/kong-gateway:3.5-enterprise-alpine environment: - KONG_ROLE=control_plane - KONG_DATABASE=off - KONG_LICENSE_DATA=${KONG_LICENSE} - KONG_CLUSTER_CERT=/etc/kong/certs/control.crt - KONG_CLUSTER_CERT_KEY=/etc/kong/certs/control.key ports: - "8444:8444" # Control Plane API (TLS) - "8002:8002" # Kong Manager UI volumes: - ./certs:/etc/kong/certs |
export KONG_LICENSE=$(cat enterprise_license)で環境変数を設定。docker compose up -dを実行し、https://localhost:8444にブラウザでアクセスして証明書が有効か確認。
Helm を用いた本番向けデプロイ
公式 Helm リポジトリから Enterprise 用チャートを取得し、必要パラメータを上書きします。以下は推奨設定例です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
helm repo add kong https://charts.konghq.com helm repo update helm install kong-control-plane kong/kong \ --namespace kong-enterprise \ --create-namespace \ --set enterprise.enabled=true \ --set enterprise.licenseSecret=kong-license \ --set role=control_plane \ --set admin.guiUrl=http://0.0.0.0:8002 \ --set env.kong_cluster_cert=/etc/kong/certs/control.crt \ --set env.kong_cluster_cert_key=/etc/kong/certs/control.key \ -f values-controlplane.yaml |
values-controlplane.yaml の主な項目は次の通りです。
|
1 2 3 4 5 6 7 |
replicaCount: 2 # 高可用性確保 service: type: LoadBalancer # 外部から 8444/8002 にアクセス可能にする env: KONG_DATABASE: "off" KONG_PROMETHEUS_EXPORTER_ENABLED: "true" |
デプロイ完了後は kubectl get svc -n kong-enterprise で LoadBalancer の外部 IP を取得し、https://<IP>:8444 にアクセスして Control Plane が起動していることを確認します。
Data Plane のデプロイと接続設定
Data Plane は各クラウドの Kubernetes クラスタやオンプレミス VM にインストールし、先ほど作成した TLS 証明書と Hybrid トークンで Control Plane と結びつけます。
各クラウド環境での Kong Ingress Controller インストール(共通手順)
Helm を利用すれば AWS・GCP・Azure いずれでも同一チャートでデプロイ可能です。以下は必須パラメータだけを抜粋した例です。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
helm repo add kong https://charts.konghq.com helm repo update helm install kong-dataplane-${CLOUD} kong/kong \ --namespace ${CLOUD}-kong \ --create-namespace \ --set ingressController.enabled=true \ --set role=data_plane \ --set env.kong_cluster_control_plane=https://<CP_IP>:8444 \ --set env.kong_hybrid_token=${HYBRID_TOKEN} \ -f values-dataplane.yaml |
| クラウド | values-dataplane.yaml のポイント |
|---|---|
| AWS (EKS) | service.type=LoadBalancer → ELB が自動作成。 |
| GCP (GKE) | service.annotations.cloud.google.com/load-balancer-type: "Internal" で内部 LB を利用可能。 |
| Azure (AKS) | service.loadBalancerIP に固定パブリック IP を設定し、外部から安定アクセスを実現。 |
VM へのインストール手順
レガシーアプリやオンプレミス環境ではバイナリ配布が有効です。
- バイナリ取得(Enterprise 用)
bash
curl -L https://download.konghq.com/gateway-3.x/kong-enterprise-linux-amd64.tar.gz | tar xz
sudo mv kong /opt/kong - 証明書配置
bash
sudo mkdir -p /etc/kong/certs
sudo cp data-plane.crt /etc/kong/certs/
sudo cp data-plane.key /etc/kong/certs/ - 環境変数設定(
/etc/kong/kong.confに記載しても可)
bash
export KONG_ROLE=data_plane
export KONG_DATABASE=off
export KONG_CLUSTER_CONTROL_PLANE=https://<CP_IP>:8444
export KONG_HYBRID_TOKEN=${HYBRID_TOKEN} - 起動
bash
sudo /opt/kong/kong start -c /etc/kong/kong.conf
起動後、curl -k https://<VM_IP>:8001/status | jq . が { "status": "healthy" } を返せば接続成功です。
Hybrid トークンの発行と接続確認
Hybrid 接続はトークンベースで相互認証を行います。以下の手順で安全にトークンを生成し、各 Data Plane に配布します。
- Control Plane からトークン生成(Kong Manager の「Hybrid」メニューか CLI)
bash
kong hybrid token generate --name dataplane-aws --ttl 365d > hybrid-token-aws.txt - トークンの配布
- Helm デプロイ時に
--set env.kong_hybrid_token=$(cat hybrid-token-aws.txt)を指定。 -
VM 環境では環境変数
KONG_HYBRID_TOKENに設定。 -
接続テスト(Data Plane 側)
bash
curl -k https://<CP_IP>:8444/status | jq .
出力が{ "status":"healthy" }であれば、Control Plane と Data Plane の通信は確立しています。
Service / Route の作成とプラグイン適用
Hybrid 環境でも API 定義の流れは従来と同様です。ここでは Admin API を直接呼び出す例と、Kong Ingress Controller(KIC)で Kubernetes リソースから自動生成する方法を示します。
Admin API を利用した定義例
まず Service を作成し、その上に Route とプラグインを付与します。以下は要点だけを箇条書きにした手順です。
- Service 作成
bash
curl -i -X POST https://<CP_IP>:8444/services \
-d "name=orders-service" \
-d "url=http://orders-backend.default.svc.cluster.local:8080" - Route 作成(/api/orders にマッピング)
bash
curl -i -X POST https://<CP_IP>:8444/services/orders-service/routes \
-d "paths[]=/api/orders" \
-d "methods[]=GET" - プラグイン適用例(key‑auth)
bash
curl -i -X POST https://<CP_IP>:8444/services/orders-service/plugins \
-d "name=key-auth"
主要プラグインの設定例
| プラグイン | 用途 | 設定例 |
|---|---|---|
| key‑auth | API キー認証 | curl -X POST https://<CP_IP>:8444/services/orders-service/plugins -d "name=key-auth" |
| oauth2 | OAuth2 認可コードフロー | -d "name=oauth2" -d "config.scopes[]=read" |
| rate‑limiting | 秒間リクエスト数制限 | -d "name=rate-limiting" -d "config.minute=60" |
プラグインは Service、Route、または Global(全体)レベルで適用できます。Hybrid 環境では Control Plane から一括管理できるため、個別 Data Plane の設定変更は不要です。
Ingress アノテーションによる自動生成例
KIC を利用すれば Kubernetes の Ingress オブジェクトだけで Service/Route とプラグインが自動作成されます。以下は典型的なマニフェストです。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: orders-ingress namespace: production annotations: konghq.com/plugins: "key-auth,rate-limiting" konghq.com/strip-path: "true" spec: ingressClassName: kong rules: - host: api.example.com http: paths: - path: /orders pathType: Prefix backend: service: name: orders-service # Kubernetes Service 名 port: number: 80 |
konghq.com/pluginsにカンマ区切りでプラグイン名を列挙すると、KIC が自動的に Kong の Plugin 設定を生成。- 開発者は Kubernetes リソースだけで API 管理が完結するため、運用コストが大幅に削減されます。
Observability と運用・障害対策
Hybrid 構成では Data Plane が分散しているため、可視化と障害検知の仕組みを整えることが必須です。本節では Prometheus/Grafana の連携、Kong Manager のモニタリング活用、およびマルチクラウドでのフェイルオーバー戦略をまとめます。
Prometheus / Grafana 連携手順
- Exporter 有効化(Control Plane と Data Plane 共通)
Helmvalues.yamlに次を追加:
yaml
env:
KONG_PROMETHEUS_EXPORTER_ENABLED: "true" - ServiceMonitor 作成(Prometheus Operator 使用時)
yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: kong-control-plane
labels:
release: prometheus
spec:
selector:
matchLabels:
app.kubernetes.io/name: kong
endpoints:- port: admin
path: /metrics
scheme: https
tlsConfig:
insecureSkipVerify: true
- port: admin
- Grafana ダッシュボードインポート
Kong が公式 GitHub に公開している JSON ダッシュボード(kong-gateway-dashboard.json)を Grafana に取り込み、主要指標kong_http_requests_total,kong_latency_msなどを可視化。
Kong Manager のモニタリング活用ポイント
- Analytics ページでリアルタイムのリクエスト数・エラーレート・トップ API が確認できる。Hybrid 環境でも Control Plane に集約されたデータが表示されます。
- RBAC 設定により、閲覧権限だけを持つオペレーター用ロール(Viewer)を作成し、誤操作リスクを低減。
マルチクラウドでのトラフィック最適化とフェイルオーバー戦略
- DNS ヘルスチェック:Route53(AWS)や Cloud DNS(GCP)のヘルスチェック機能で各 Data Plane のステータスを監視し、障害時に自動的に別リージョンへ切り替える。
- Geo‑Based Routing:Cloudflare Workers や Azure Front Door でユーザーの所在地に応じた最適ルートを選択し、レイテンシーを削減。
- フェイルオーバー手順(概要)
- Data Plane の
/statusエンドポイントが失敗したら、ロードバランサのプールから自動除外。 - Control Plane が
kong_hybrid_data_planeステータスを監視し、障害検知時に Helm で代替 Data Plane をローリングデプロイ。
代表的な障害シナリオと対処法
| 障害シナリオ | 主な原因 | 推奨対策 |
|---|---|---|
| Control Plane への接続エラー | TLS 証明書不一致・ネットワーク ACL がブロック | 証明書チェーンを再確認し、ポート 8444 のアウトバウンド許可を追加 |
| プラグイン競合(同名が二重登録) | Declarative Config と Admin API が混在 | 設定方式を一本化し、kong config db_import で一括適用 |
| バージョン不整合 | Data Plane が古いバージョンで稼働中 | 全 Data Plane を同一バージョンへローリングアップグレード(Helm の --set image.tag=<ver>) |
| ヘルスチェック失敗によるフェイルオーバー遅延 | /status エンドポイント未実装 |
各 Data Plane に /status を有効化し、ロードバランサのヘルスパスを https://<IP>:8444/status に設定 |
障害発生時はまず Kong のログ(/usr/local/kong/logs/error.log)と Prometheus アラート履歴を確認し、原因切り分けを行うことが重要です。
まとめ
- Hybridモードは Control Plane と Data Plane を分離し、マルチクラウド・マルチリージョンで統一された API ガバナンスとスケーラビリティを実現します。
- 必要な 前提条件 は Enterprise ライセンス取得、Kubernetes の最低スペック確保、そして mTLS 用証明書の作成です。
- Control Planeは Docker Compose(検証)または Helm(本番)でデプロイし、Kong Manager で管理者設定・トークン生成を行います。
- 各クラウドや VM に Data Plane をインストールし、Hybrid トークンと TLS 証明書で接続すれば即座に API 管理が開始できます。
- Service/Route と主要プラグインは Admin API または Ingress アノテーションで簡潔に定義でき、KIC が自動的に Kong の設定へ変換します。
- Observability は Prometheus/Grafana と Kong Manager を組み合わせ、マルチクラウドのヘルスチェック・フェイルオーバーを実装すれば安定運用が可能です。
以上の手順とベストプラクティスに沿って構築すれば、読者は自社環境に最適な Kong Gateway Hybrid 構成を設計・デプロイし、継続的な API 管理と可観測性を確保できるでしょう。