Contents
- 1 Kong Gateway の概要と主要機能
- 2 2026 年時点のバージョン情報とリリース確認方法
- 3 Docker Compose によるローカル開発環境の構築
- 4 Helm Chart を用いた本番クラスターへのデプロイ
- 5 データベース選択と推奨構成
- 6 Admin API の安全な公開と認証設定
- 7 GUI の選択肢 – Enterprise の Kong Manager と OSS 向け代替
- 8 主要プラグインの有効化手順（CLI と GUI の併用例）
- 9 API ルーティング作成・テスト手順とセキュリティベストプラクティス
- 10 可観測性 – Prometheus エクスポートと Grafana ダッシュボード
- 11 記事全体のまとめ
Kong Gateway の概要と主要機能
Kong Gateway はオープンソースで提供される API 管理基盤で、マイクロサービス間のリクエストを統一的にルーティング・認証・レートリミットなどで保護します。軽量かつプラグイン駆動という設計は、スモールスタートから大規模本番環境まで段階的に拡張できる点が特徴です。本節では OSS と Enterprise の違いを整理し、導入判断の材料となるポイントを示します。
OSS と Enterprise の機能比較
| 項目 | Kong Gateway OSS | Kong Enterprise |
|---|---|---|
| ライセンス | Apache 2.0（無償） | 商用ライセンス（年額課金） |
| データベース | PostgreSQL / Cassandra | 同上＋Enterprise 用拡張 DB |
| 標準プラグイン | 認証・レートリミット等の基本セット | 基本に加えて有料プラグイン (OAuth2, ACL など) |
| GUI（管理画面） | OSS 向け UI は公式には提供されず、Konga 等サードパーティ製を利用 | Kong Manager（Enterprise 専用）と Dev Portal が標準搭載 |
| RBAC / SSO | 限定的（プラグインで代替可） | 完全なロールベースアクセス制御とシングルサインオン |
| サポート体制 | コミュニティフォーラム、GitHub Issues | SLA に基づく公式サポートと 24 時間対応 |
注：OSS 版でもプラグイン機構はフルに利用可能ですが、公式 UI（Kong Manager）は Enterprise 限定です。OSS 環境で GUI が必要な場合は Konga や Kong Dashboard といったオープンソース製品を別途導入してください。[1]
2026 年時点のバージョン情報とリリース確認方法
Kong の公式イメージや Helm Chart は頻繁に更新されますが、執筆時点（2026 年 7 月）での正確な最新バージョンは公式 Docker Hub と Helm リポジトリで直接確認する必要があります。以下に確認手順と参考リンクを示します。
- Docker イメージ
bash
docker pull kong/kong:latest # 最新タグの取得
docker manifest inspect kong/kong:latest | jq .RepoDigests - Helm Chart
bash
helm repo add kong https://charts.konghq.com
helm search repo kong/kong --versions | head -n 5
公式ドキュメントは随時更新されるため、導入前に必ず最新版をチェックしてください。
[2] https://docs.konghq.com/gateway/latest/installation/kubernetes/
Docker Compose によるローカル開発環境の構築
このセクションでは、Kong と PostgreSQL を組み合わせたシンプルなスタックを数分で立ち上げる手順を解説します。Docker Compose は学習や CI パイプラインに最適です。
docker‑compose.yml の作成
以下は「公式イメージの latest タグ」を利用した例です。バージョン固定が必要な場合は kong/kong:3.x 等、実際に確認したタグへ置き換えてください。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
version: "3.8" services: postgres: image: postgres:15-alpine environment: POSTGRES_USER: kong POSTGRES_PASSWORD: kong POSTGRES_DB: kong volumes: - pgdata:/var/lib/postgresql/data kong: image: kong/kong:latest # 最新イメージを使用 depends_on: - postgres environment: KONG_DATABASE: "postgres" KONG_PG_HOST: "postgres" KONG_PG_USER: "kong" KONG_PG_PASSWORD: "kong" KONG_ADMIN_LISTEN: "0.0.0.0:8001, 0.0.0.0:8444 ssl" ports: - "8000:8000" # プロキシ - "8443:8443" # TLS プロキシ - "8001:8001" # Admin API - "8444:8444" # Admin API (TLS) command: > kong migrations bootstrap && kong start volumes: pgdata: |
起動と確認
|
1 2 3 |
docker compose up -d curl -i http://localhost:8001/ # 200 が返れば成功 |
ベストプラクティス：開発環境では
KONG_ADMIN_GUI_URLを設定しないことで、誤って Enterprise UI にアクセスするリスクを回避できます。
Helm Chart を用いた本番クラスターへのデプロイ
Kubernetes 上で高可用性を確保したい場合は、公式 Helm Chart が推奨されます。ここでは PostgreSQL バックエンドを前提にした最小構成を示します。
values.yaml のポイント解説
| フィールド | 説明 |
|---|---|
env.database |
使用データベース（postgres） |
env.pg_user・pg_password・pg_host |
PostgreSQL 接続情報 |
replicaCount |
Kong の Pod 数。最低 2 本で冗長化が可能 |
service.type |
LoadBalancer 推奨（外部公開）。内部だけなら ClusterIP に変更可 |
ingressController.enabled |
Ingress コントローラとして Kong を利用する場合は true |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
env: database: "postgres" pg_user: "kong" pg_password: "kong" pg_host: "postgres.kong.svc.cluster.local" replicaCount: 2 service: type: LoadBalancer ports: - name: proxy-http port: 80 targetPort: 8000 - name: proxy-https port: 443 targetPort: 8443 - name: admin-api port: 8001 targetPort: 8001 ingressController: enabled: true |
デプロイ手順
|
1 2 3 4 5 |
helm repo add kong https://charts.konghq.com helm repo update helm install kong-gateway kong/kong -f values.yaml --namespace kong --create-namespace kubectl get pods -n kong # 全て Running であれば完了 |
注意：Enterprise 機能（Kong Manager, Dev Portal 等）を有効にしたい場合は、別途
enterprise.enabled: trueとライセンス情報の設定が必要です。[3]
データベース選択と推奨構成
Kong がサポートするデータストアは PostgreSQL と Cassandra の 2 種類ですが、2026 年時点では運用コスト・エコシステムの成熟度から PostgreSQL がデフォルトで推奨されています。
PostgreSQL のメリット
- ACID 特性により設定変更が確実に永続化
- 豊富なバックアップ/リカバリツール（pg_dump, PITR）
- Kubernetes 環境では
Bitnami/postgresqlなどの Helm Chart と相性良好
Cassandra の適用シーン
| 条件 | 推奨度 |
|---|---|
| 超大規模トラフィック（数十万 RPS） | 高 |
| 書き込みが頻繁でスキーマ変更が少ない | 中 |
| 運用チームに Cassandra の専門知識がある | 必須 |
結論：新規導入はまず PostgreSQL を選択し、将来的な水平スケール要件が明確になった段階で Cassandra への移行を検討してください。
Admin API の安全な公開と認証設定
Admin API は Kong の内部管理インタフェースであり、外部から直接アクセスさせないことが基本的なセキュリティ要件です。以下に安全に構築するための手順を示します。
Admin API のバインド設定例（Docker / Helm 共通）
|
1 2 3 |
# Docker Compose でも Helm values.yaml でも同様に設定可能 KONG_ADMIN_LISTEN: "0.0.0.0:8001, 0.0.0.0:8444 ssl" |
- 内部ネットワーク限定：
0.0.0.0は全インタフェースを意味しますが、実運用では127.0.0.1またはクラスター内プライベート IP に絞る方が安全です。 - TLS の有効化：
sslオプションで HTTPS を必須にし、自己署名証明書でも暗号化は確保できます。
認証プラグインによる保護
- Basic Auth（簡易）
bash
curl -i -X POST http://localhost:8001/plugins \
-d name=basic-auth - Key Authentication（推奨）
bash
curl -i -X POST http://localhost:8001/consumers \
-d username=admin_user
curl -i -X POST http://localhost:8001/consumers/admin_user/key-auth \
-d key=$(openssl rand -hex 16)
ベストプラクティス：本番環境では IP フィルタリング（NetworkPolicy）と組み合わせ、認証プラグインは必ず有効化してください。
GUI の選択肢 – Enterprise の Kong Manager と OSS 向け代替
Kong Manager は Enterprise ライセンスに含まれる公式管理画面です。一方 OSS では次のようなオープンソース UI が利用可能です。
| 製品 | 提供元 | 主な特徴 |
|---|---|---|
| Kong Manager | Kong Inc. (Enterprise) | サービス/ルート/プラグイン管理、Dev Portal、RBAC 完全対応 |
| Konga | コミュニティ（GitHub） | シンプルなダッシュボード、Basic Auth／JWT による認証、Docker イメージが公式提供 |
| Kong Dashboard | Kong Inc. (OSS) | 2024 年にリリースされた軽量 UI。プラグイン管理は限定的 |
注意点：Konga 等は公式サポート対象外であり、機能更新のタイミングが Kong 本体とずれる可能性があります。[1]
主要プラグインの有効化手順（CLI と GUI の併用例）
ここでは実務で頻繁に使用される Key Auth / JWT、Rate Limiting、Logging を具体的に示します。
Key Authentication
|
1 2 3 4 5 6 7 8 |
# サービスにプラグインを追加 curl -i -X POST http://localhost:8001/services/demo-service/plugins \ -d name=key-auth # コンシューマ作成とキー発行 curl -i -X POST http://localhost:8001/consumers -d username=app_user curl -i -X POST http://localhost:8001/consumers/app_user/key-auth -d key=$(openssl rand -hex 16) |
JWT
|
1 2 3 4 5 6 7 8 9 10 |
curl -i -X POST http://localhost:8001/services/demo-service/plugins \ -d name=jwt \ -d "config.claims_to_verify=exp" # 公開鍵登録例（RSA） curl -i -X POST http://localhost:8001/consumers/app_user/jwt \ -d algorithm=RS256 \ -d key=my-key-id \ -d rsa_public_key=@public.pem |
Rate Limiting
|
1 2 3 4 |
curl -i -X POST http://localhost:8001/services/demo-service/plugins \ -d name=rate-limiting \ -d "config.minute=100" |
ロギング（File / HTTP）
|
1 2 3 4 5 6 7 8 9 10 |
# File log curl -i -X POST http://localhost:8001/services/demo-service/plugins \ -d name=file-log \ -d "config.path=/var/log/kong/access.log" # HTTP log (例：Datadog) curl -i -X POST http://localhost:8001/services/demo-service/plugins \ -d name=http-log \ -d "config.http_endpoint=https://http-intake.logs.datadoghq.com/v1/input/<API_KEY>" |
GUI での操作：Konga の「Plugins」メニューから同様の項目を選択し、パラメータを入力するだけで有効化できます。
API ルーティング作成・テスト手順とセキュリティベストプラクティス
API を公開するまでの流れと、運用時に必須となる TLS/HTTPS 設定、RBAC の適用例をまとめます。
サービスとルートの作成（CLI）
|
1 2 3 4 5 6 7 8 9 |
# Service 作成 curl -i -X POST http://localhost:8001/services \ -d name=demo-service \ -d url=http://httpbin.org # Route 作成（/api/v1 にマッピング） curl -i -X POST http://localhost:8001/services/demo-service/routes \ -d "paths[]=/api/v1" |
動作確認（curl）
|
1 2 |
curl -i http://localhost:8000/api/v1/get # 200 が返れば成功 |
TLS 終端設定例（Kubernetes の ConfigMap）
|
1 2 3 4 |
env: ssl_cert: "/etc/kong/ssl/tls.crt" ssl_cert_key: "/etc/kong/ssl/tls.key" |
- 証明書は Let’s Encrypt と
cert-managerを併用すれば自動更新が可能です。
RBAC の基本構成（Enterprise）
|
1 2 3 4 5 6 7 8 9 10 11 |
rbac: enabled: true roles: - name: admin permissions: ["*"] - name: developer permissions: - "services:read" - "routes:create" - "plugins:manage" |
ポイント：OSS 環境でも
aclプラグインやrole-based-access-controlの代替として外部 IdP と連携することで、同様の権限管理が実現できます。
可観測性 – Prometheus エクスポートと Grafana ダッシュボード
Kong 3.x 系からは Prometheus プラグインがバンドルされており、メトリクスを簡単に取得できます。
メトリクス有効化（values.yaml）
|
1 2 3 |
env: plugins: "bundled, prometheus" |
- 有効化後は
http://<kong-host>:8001/metricsが Prometheus フォーマットで情報を提供します。
Grafana ダッシュボードの導入手順
- Grafana の「Import」画面で公式ダッシュボード ID 7425 を入力。
- データソースに先ほど設定した Prometheus インスタンスを選択。
- 「Kong – Proxy Traffic」「Kong – Plugin Errors」等のパネルが自動的に表示されます。
運用上のヒント：アラートは
rate(kong_http_requests_total[1m]) > 1000のように設定し、異常トラフィックを即座に検知できる体制を整えておくと安心です。
記事全体のまとめ
- Kong Gateway は OSS と Enterprise が明確に分かれ、OSS でも本格的な API 管理が可能。ただし GUI は Enterprise 限定であり、OSS 用 UI は Konga 等を別途導入する必要があります。
- バージョン確認は公式 Docker Hub / Helm リポジトリで必ず行う。執筆時点の情報は参考程度に留めてください。
- Docker Compose と Helm Chart の両方を提示したので、ローカル開発から本番クラスターまでシームレスに移行できます。
- PostgreSQL が推奨データベースであり、Admin API は内部限定・認証プラグインで保護するのが基本です。
- 主要プラグインは CLI と GUI の両方から簡単に有効化でき、Key Auth / JWT / Rate Limiting / Logging が代表的な活用例です。
- TLS/HTTPS、RBAC、Prometheus/Grafana による可観測性を組み合わせれば、セキュアかつ運用しやすい API 基盤が完成します。
以上の手順とベストプラクティスに沿って構築すれば、2026 年以降も安定した API 管理基盤として活用できるでしょう。
参考文献
- Kong Manager は Enterprise のみ提供。OSS 向け UI としては Konga 等が一般的。Kong Docs – UI Options
- Docker イメージと Helm Chart の最新バージョン確認方法（公式）。Docker Hub – kong/kong / Helm Repository – kong/charts
- Enterprise ライセンス有効化の設定例。[Kong Enterprise Installation Guide]