Body ベースのルーティングを構成する

HTTP リクエストの本文からモデル名を直接抽出して推論リクエストをルーティングできる GKE Inference Gateway の機能である本文ベースのルーティングを構成する方法について説明します。

これは、OpenAI API などの仕様に準拠するアプリケーションで特に役立ちます。このようなアプリケーションでは、モデル識別子がヘッダーや URL パスではなく、リクエスト ペイロードに埋め込まれていることがよくあります。

身体ベースのルーティングの仕組み

GKE Inference Gateway は、Envoy プロキシの ext_proc 拡張機能として本文ベースのルーティングを実装します。リクエスト フローは、既存の Gateway API 構成とシームレスに統合するように設計されています。

  1. リクエストの受信: レイヤ 7 ロードバランサが受信した推論リクエストを受け取ります。
  2. 本文パラメータの抽出: レイヤ 7 ロードバランサは、リクエストを Body to Header 拡張機能に転送します。この拡張機能は、HTTP リクエストの本文から標準の model パラメータを抽出します。
  3. ヘッダー挿入: 抽出されたモデル パラメータの値が、新しいリクエスト ヘッダー（キー X-Gateway-Model-Name）として挿入されます。
  4. ルーティングの決定: リクエスト ヘッダーでモデル名が使用可能になったため、GKE Inference Gateway は既存の Gateway API HTTPRoute 構造体を使用してルーティングの決定を行うことができます。たとえば、HTTPRoute ルールは挿入されたヘッダーと照合して、トラフィックを適切な InferencePool に転送できます。
  5. エンドポイントの選択: レイヤ 7 ロードバランサが適切な InferencePool（BackendService）とエンドポイントのグループを選択します。次に、リクエストとエンドポイントの情報を Endpoint Picker 拡張機能に転送し、選択したプール内でエンドポイントをきめ細かく選択します。
  6. 最終ルーティング: リクエストは、エンドポイント選択拡張機能によって選択された特定のモデルレプリカにルーティングされます。

このプロセスにより、モデル情報がリクエスト本文の奥深くに埋め込まれている場合でも、GKE Inference Gateway はトラフィックを正しいバックエンド サービスにインテリジェントに転送できます。

ボディベースのルーティングを構成する

GKE Inference Gateway の Body-Based Routing（BBR）拡張機能は、Kubernetes クラスタ内で管理するサービスとして実行されます。レイヤ 7 ロードバランサの観点から見ると、BBR 拡張機能は外部 gRPC サーバーです。ロードバランサがリクエスト本文を検査してモデル名を特定する必要がある場合、BBR サービスに対して gRPC 呼び出しを行います。BBR サービスはリクエストを処理し、ルーティング用に挿入するヘッダーなどの情報をロードバランサに返します。

ボディベースのルーティングを有効にするには、BBR 拡張機能を Pod としてデプロイし、GCPRoutingExtension リソースと HTTPRoute リソースを使用して統合します。

前提条件

  • GKE クラスタ（バージョン 1.32 以降）があることを確認します。

  • メインガイドに沿って GKE Inference Gateway を構成します。

ボディベースのルーターをデプロイする

ボディベースのルーティング拡張機能は、クラスタ内の GCPRoutingExtension リソースとともに、Kubernetes Deployment と Service としてデプロイされます。Helm を使用すると、インストールを簡素化できます。

ボディベースのルーターに必要なリソースをデプロイするには、次のコマンドを実行します。

helm install body-based-router oci://registry.k8s.io/gateway-api-inference-extension/charts/body-based-routing \
    --set provider.name=gke \
    --set inferenceGateway.name=GATEWAY_NAME

GATEWAY_NAME は、Gateway リソースの名前に置き換えます。

このコマンドは、次のリソースをデプロイします。

  • Body-Based Routing 拡張機能の Service と Deployment。
  • Body-Based Routing 拡張機能を GKE Gateway リソースに接続するための GCPRoutingExtension リソースと GCPHealthCheckPolicy リソース。

モデル認識ルーティング用に HTTPRoute を構成する

拡張機能をデプロイして構成したら、挿入されたヘッダー（X-Gateway-Model-Name）をルーティングの決定に使用する HTTPRoute リソースを定義できます。

次に、モデル認識ルーティングの HTTPRoute マニフェストの例を示します。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: routes-to-llms
spec:
  parentRefs:
  - name: GATEWAY_NAME
  rules:
  - matches:
    - headers:
      - type: Exact
        name: X-Gateway-Model-Name
        value: chatbot # Matches the extracted model name
      path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: gemma # Target InferencePool for 'chatbot' model
      kind: InferencePool
      group: "inference.networking.k8s.io"
  - matches:
    - headers:
      - type: Exact
        name: X-Gateway-Model-Name
        value: sentiment # Matches another extracted model name
      path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: llama # Target InferencePool for 'sentiment' model
      kind: InferencePool
      group: "inference.networking.k8s.io"

このマニフェストをクラスタに適用するには、httproute-for-models.yaml として保存し、次のコマンドを実行します。

kubectl apply -f httproute-for-models.yaml

考慮事項と制限事項

Body-Based Routing の実装を計画する際は、次の点を考慮してください。

  • フェイルクローズ動作: Body-Based Routing 拡張機能は、「フェイルクローズ」モードで動作するように設計されています。拡張機能が使用できない場合や、リクエストの処理に失敗した場合は、誤ったルーティングではなく、エラー（デフォルトのバックエンドが構成されていない場合は 404 または 503 レスポンス コードなど）が発生します。デプロイを高可用性にして、サービスの信頼性を維持します。

  • リクエスト本文のサイズとストリーミング: 大規模な HTTP リクエスト本文の処理（特にストリーミングが有効になっている場合）は、複雑さを増す可能性があります。Envoy プロキシがリクエスト本文のストリーミングを強制される場合（通常は 250 KB を超える本文の場合）、新しいヘッダーを挿入できないことがあります。これにより、ルーティング エラーが発生する可能性があります（たとえば、ヘッダー一致ルールを適用できない場合は 404 エラーが発生します）。

  • 長期メンテナンス: Body-Based Routing 拡張機能は、GKE クラスタ内のコンポーネントとして実行されます。アップグレード、セキュリティ パッチ、継続的な運用の確保など、ライフサイクル管理はお客様の責任で行っていただきます。

次のステップ