Body-Based Routing konfigurieren

Hier erfahren Sie, wie Sie Body-Based Routing konfigurieren. Diese Funktion von GKE Inference Gateway ermöglicht es Ihnen, Inferenzanfragen weiterzuleiten, indem Sie den Modellnamen direkt aus dem HTTP-Anfragetext extrahieren.

Dies ist besonders nützlich für Anwendungen, die Spezifikationen wie die OpenAI API einhalten, bei denen die Modell-ID häufig in die Anfrage-Payload eingebettet ist und nicht in Headern oder URL-Pfaden.

So funktioniert das körperbasierte Routing

GKE Inference Gateway implementiert Body-Based Routing als ext_proc-Erweiterung des Envoy-Proxys. Der Anfragefluss ist so konzipiert, dass er sich nahtlos in Ihre vorhandenen Gateway API-Konfigurationen einfügt:

  1. Empfang von Anfragen: Der Layer-7-Load Balancer empfängt eine eingehende Inferenzanfrage.
  2. Extrahieren von Parametern aus dem Text: Der Layer-7-Load-Balancer leitet die Anfrage an die Erweiterung „Body to Header“ weiter. Diese Erweiterung extrahiert den Standardparameter model aus dem HTTP-Anfragetext.
  3. Header-Injection: Der Wert des extrahierten Modellparameters wird dann als neuer Anfrageheader (mit dem Schlüssel X-Gateway-Model-Name) eingefügt.
  4. Routing-Entscheidung: Da der Modellname jetzt in einem Anfrageheader verfügbar ist, kann das GKE Inference Gateway vorhandene Gateway API-HTTPRoute-Konstrukte verwenden, um Routing-Entscheidungen zu treffen. Beispiel: HTTPRoute-Regeln können mit dem eingefügten Header abgeglichen werden, um Traffic an die entsprechende InferencePool weiterzuleiten.
  5. Endpunktauswahl: Der Layer 7-Load-Balancer wählt die entsprechende InferencePool (BackendService) und Gruppe von Endpunkten aus. Anschließend werden Anfragen und Endpunktinformationen an die Erweiterung „Endpoint Picker“ weitergeleitet, um eine detaillierte Endpunktauswahl innerhalb des ausgewählten Pools zu ermöglichen.
  6. Finales Routing: Die Anfrage wird an das spezifische Modellreplikat weitergeleitet, das von der Endpoint Picker-Erweiterung ausgewählt wurde.

So kann Ihr GKE Inference Gateway Traffic intelligent an die richtigen Backend-Dienste weiterleiten, auch wenn sich Modellinformationen tief im Anfragebody befinden.

Body-basiertes Routing konfigurieren

Die BBR-Erweiterung (Body-Based Routing) für das GKE Inference Gateway wird als Dienst ausgeführt, den Sie in Ihrem Kubernetes-Cluster verwalten. Aus Sicht des Layer-7-Load-Balancers ist die BBR-Erweiterung ein externer gRPC-Server. Wenn der Load Balancer den Anfragetext untersuchen muss, um den Modellnamen zu ermitteln, führt er einen gRPC-Aufruf an den BBR-Dienst aus. Der BBR-Dienst verarbeitet dann die Anfrage und gibt Informationen an den Load Balancer zurück, z. B. Header, die für das Routing eingefügt werden sollen.

Wenn Sie Body-Based Routing aktivieren möchten, stellen Sie die BBR-Erweiterung als Pod bereit und binden Sie sie mit den Ressourcen GCPRoutingExtension und HTTPRoute ein.

Vorbereitung

Body-basierten Router bereitstellen

Die Erweiterung für das Body-basierte Routing wird als Kubernetes-Deployment und -Dienst zusammen mit einer GCPRoutingExtension-Ressource in Ihrem Cluster bereitgestellt. Sie können Helm für eine vereinfachte Installation verwenden.

Führen Sie den folgenden Befehl aus, um die erforderlichen Ressourcen für den körperbasierten Router bereitzustellen:

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

Ersetzen Sie GATEWAY_NAME durch den Namen Ihrer Gateway-Ressource.

Mit diesem Befehl werden die folgenden Ressourcen bereitgestellt:

  • Ein Dienst und ein Deployment für die Erweiterung „Body-Based Routing“.
  • Eine GCPRoutingExtension-Ressource und eine GCPHealthCheckPolicy-Ressource, um die Body-Based Routing-Erweiterung an Ihre GKE Gateway-Ressource anzuhängen.

HTTPRoute für modellbasiertes Routing konfigurieren

Nachdem die Erweiterung bereitgestellt und konfiguriert wurde, können Sie HTTPRoute-Ressourcen definieren, die den eingefügten Header (X-Gateway-Model-Name) für Routingentscheidungen verwenden.

Das folgende Beispiel zeigt ein HTTPRoute-Manifest für das modellbasierte Routing:

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"

Wenn Sie dieses Manifest auf Ihren Cluster anwenden möchten, speichern Sie es als httproute-for-models.yaml und führen Sie den folgenden Befehl aus:

kubectl apply -f httproute-for-models.yaml

Überlegungen und Einschränkungen

Beachten Sie bei der Planung der Implementierung des Body-Based Routing Folgendes:

  • Fail-closed-Verhalten:Die Erweiterung für körperbasierte Weiterleitung ist so konzipiert, dass sie im „Fail-closed“-Modus funktioniert. Wenn die Erweiterung nicht verfügbar ist oder eine Anfrage nicht verarbeiten kann, führt dies zu einem Fehler (z. B. einem 404- oder 503-Antwortcode, wenn kein Standard-Backend konfiguriert ist) und nicht zu einem falschen Routing. Sorgen Sie dafür, dass Ihre Bereitstellungen hochverfügbar sind, um die Zuverlässigkeit des Dienstes zu gewährleisten.

  • Größe und Streaming des Anfragetexts:Die Verarbeitung großer HTTP-Anfragetexte, insbesondere wenn Streaming aktiviert ist, kann komplex sein. Wenn der Envoy-Proxy gezwungen ist, den Anfragetext zu streamen (in der Regel bei Texten, die größer als 250 KB sind), kann er möglicherweise keine neuen Header einfügen. Dies kann zu Routingfehlern führen, z. B. zu einem 404-Fehler, wenn die Regeln für den Headerabgleich nicht angewendet werden können.

  • Langfristige Wartung:Die Body-Based Routing-Erweiterung wird als Komponente in Ihren GKE-Clustern ausgeführt. Sie sind für die Verwaltung des Lebenszyklus verantwortlich, einschließlich Upgrades, Sicherheitspatches und der Sicherstellung des Betriebs.

Nächste Schritte