Posted inDevOps

Kubernetesトラフィックのスケーリング：JWT、レート制限、オブザーバビリティのためのKongデプロイガイド

DevOps tutorial - IT technology blog
DevOps tutorial - IT technology blog

Kubernetesにおける最適なゲートウェイ戦略の選択

5つのマイクロサービスから50へとスケールする際、本当の苦労が始まります。数個 of サービスを管理するのは簡単ですが、認証やトラフィックのロジックをすべてのアプリに個別に組み込むと、膨大なメンテナンスの負債が生じます。レート制限のポリシーを異なる言語間で同期させようとして数週間を費やし、最終的にエッジでトラフィックを処理する中央集約的な方法が必要だと気づくチームを私は何度も見てきました。

Kubernetesのトラフィック戦略を立てる際、通常は以下の3つの選択肢に突き当たります。

  • 標準的なIngressコントローラー（Nginxなど）: これらは基本的なL7ルーティングとSSLのための主力ツールです。しかし、コンシューマー階層化や複雑なAPIキーなどの高度なロジックが必要な場合には力不足です。
  • サービスメッシュ（Istioなど）: これらは強力な武器です。サービス間の内部セキュリティには最適ですが、運用コストやサイドカーのオーバーヘッドは、導入したばかりのチームには高すぎることがよくあります。
  • API Gateway（Kongなど）: これが「スイートスポット」です。Kongは、100以上のプラグインライブラリを使用して、ノースサウス（ユーザーからサービスへ）のトラフィックを即座に管理できます。

実際、Kongが優れているのは、生のパフォーマンスと巨大なエコシステムのバランスが取れている点です。私は、ミリ秒以下のレイテンシが必須となる本番環境でこれをデプロイしてきました。Kubernetes Ingress Controller (KIC) モデルにより、このセットアップは後付けの追加機能ではなく、クラスターのネイティブな一部のように感じられます。

トレードオフ：なぜKongなのか？

選ばれる理由

  • プラグインエコシステム: JWT、OAuth2、CORSをYAML経由で切り替えられます。GoやJavaのサービスで繰り返しのボイラープレートコードを書く必要はもうありません。
  • 高いスループット: NginxとOpenRestyをベースに構築されたKongは、最小限のCPUジッターで数千の同時リクエストを処理します。
  • GitOps対応: 設定はカスタムリソース定義（CRD）として保存されます。つまり、ゲートウェイの設定がアプリケーションコードと並んでバージョン管理されることを意味します。

現実的な注意点

  • シンプルなアプリにはオーバーキル: サービスが2つしかなく、エッジでの認証が不要な場合は、基本的なNginxコントローラーの方がシンプルです。
  • 状態管理: Kongは伝統的にPostgresを必要としますが、KubernetesではDB-lessモードが推奨されます。ただし、設定の更新にはこれまでとは異なる考え方が必要です。

推奨される構成：DB-lessとCRD駆動

現代のKubernetes環境では、常にDB-lessモードを推奨しています。個別のPostgresインスタンスを維持する代わりに、Kubernetesを「信頼できる唯一の情報源（Source of Truth）」として扱います。設定はETCDに保存され、Kong Ingress Controllerが変更を監視してKongのメモリに直接反映します。

このアーキテクチャは軽量で回復力があります。ここでは、堅牢なAPIの3つの柱である「セキュリティ（JWT）」、「トラフィック制御（レート制限）」、「可視性（Prometheus/Grafana）」に焦点を当てます。

実装ガイド：Kongのセットアップ

1. Helmによるインストール

Helmは、複雑なRBACやサービス定義を管理してくれるため、ここでの標準です。専用のネームスペースでゲートウェイを起動しましょう。

helm repo add kong https://charts.konghq.com
helm repo update

# API管理用のネームスペースを作成
kubectl create namespace kong

# DB-lessモードでKongをインストール
helm install kong kong/kong -n kong \
  --set ingressController.enabled=true \
  --set env.database=off

2. テスト用サービスのデプロイ

ターゲットが必要です。このシンプルなechoサービスは、トラフィックが正しく流れているかを確認するための内部マイクロサービスとして機能します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo-service
spec:
  replicas: 1
  selector:
    matchLabels:
      app: echo
  template:
    metadata:
      labels:
        app: echo
    spec:
      containers:
      - name: echo
        image: ealen/echo-server
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: echo-service
spec:
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: echo

3. レート制限によるバックエンドの保護

本番環境の安定性を高めるための手軽な方法は、ブルートフォース攻撃や暴走したスクリプトを防ぐことです。このデモでは、リクエストを1分間に5回に制限するKongPluginを定義します。本番環境では、キャパシティに応じてこれを毎秒1,000回などに設定することになるでしょう。

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: global-rate-limit
  namespace: kong
config:
  minute: 5
  policy: local
plugin: rate-limiting
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: echo-ingress
  annotations:
    konghq.com/plugins: global-rate-limit
spec:
  ingressClassName: kong
  rules:
  - http:
      paths:
      - path: /echo
        pathType: ImplementationSpecific
        backend:
          service:
            name: echo-service
            port:
              number: 80

4. JWT認証のオフロード

認証ロジックをゲートウェイに移動することで、サービスをクリーンに保てます。まず JWTプラグインを有効にし、次にAPIの呼び出しを許可されたエンティティである「Consumer（コンシューマー）」を作成します。

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: jwt-auth
  namespace: kong
plugin: jwt
---
apiVersion: configuration.konghq.com/v1
kind: KongConsumer
metadata:
  name: mobile-app-user
  namespace: kong
username: mobile-app-user
credentials:
- mobile-app-jwt-secret
---
apiVersion: v1
kind: Secret
metadata:
  name: mobile-app-jwt-secret
  namespace: kong
type: Opaque
stringData:
  kongCredType: jwt
  key: "issuer-77" # JWT内の 'iss' クレームと一致させる
  secret: "非常に機密性の高いシークレット文字列"

Ingressのアノテーションを更新してjwt-authを含めると、Kongは有効なトークンのないリクエストをブロックします。バックエンドは、不正なトラフィックを目にすることさえありません。

5. Prometheusによる可視化

本番環境のトラフィックにおいて、オブザーバビリティ（可視性）はオプションではありません。私は常にKongをPrometheusにリンクさせ、レイテンシや4xx/5xxエラー率を追跡しています。Kongは、これらのメトリクスを即座に公開するネイティブプラグインを提供しています。

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: prometheus-metrics
  namespace: kong
plugin: prometheus
config:
  per_consumer: true

これを適用すると、Kongはポート8001でメトリクスエンドポイントを提供します。Prometheusのスケーラーをそこに向けます。プロフェッショナルなモニタリングを素早く行うには、GrafanaダッシュボードID 7424をインポートして、トラフィック量と健全性をリアルタイムで確認してください。

スケーリングに関する最終的な考察

以前は、ネットワークパスにホップを増やすことを心配していました。しかし、セキュリティとトラフィック制御を中央集約化するメリットは、わずかなレイテンシの増加をはるかに上回ります。DB-lessにすることで、データベース接続のボトルネックのリスクを排除し、ゲートウェイを真にエフェメラル（一時的）な状態に保つことができます。

将来的にOIDCやエンタープライズグレードのサポートが必要になった場合でも、このセットアップからの移行は簡単です。ほとんどのエンジニアリングチームにとって、このCRDベースのアプローチは、フルサービスメッシュのような運用の悪夢を避えつつ、完璧なコントロールのバランスを提供します。

Share:
Tags: