Configurare il routing basato sul corpo

Scopri come configurare il routing basato sul corpo, una funzionalità di GKE Inference Gateway che ti consente di instradare le richieste di inferenza estraendo il nome del modello direttamente dal corpo della richiesta HTTP.

Questa funzionalità è particolarmente utile per le applicazioni che rispettano specifiche come l'API OpenAI, in cui l'identificatore del modello è spesso incorporato nel payload della richiesta anziché nelle intestazioni o nei percorsi URL.

Come funziona il routing basato sul corpo

GKE Inference Gateway implementa il routing basato sul corpo come estensione ext_proc del proxy Envoy. Il flusso delle richieste è progettato per integrarsi perfettamente con le configurazioni dell'API Gateway esistenti:

  1. Ricezione della richiesta: il bilanciatore del carico di livello 7 riceve una richiesta di inferenza in entrata.
  2. Estrazione dei parametri del corpo: il bilanciatore del carico di livello 7 inoltra la richiesta all'estensione Body to Header. Questa estensione estrae il parametro model standard dal corpo della richiesta HTTP.
  3. Inserimento dell'intestazione: il valore del parametro del modello estratto viene quindi inserito come nuova intestazione della richiesta (con la chiave X-Gateway-Model-Name).
  4. Decisione di routing: ora che il nome del modello è disponibile in un'intestazione della richiesta, GKE Inference Gateway può utilizzare i costrutti HTTPRoute dell'API Gateway esistenti per prendere decisioni di routing. Ad esempio, le regole HTTPRoute possono corrispondere all'intestazione inserita per indirizzare il traffico all'oggetto InferencePool appropriato.
  5. Selezione dell'endpoint: il bilanciatore del carico di livello 7 seleziona l'oggetto appropriato InferencePool (BackendService) e il gruppo di endpoint. Quindi inoltra le informazioni sulla richiesta e sull'endpoint all'estensione Endpoint Picker per la selezione granulare dell'endpoint all'interno del pool scelto.
  6. Routing finale: la richiesta viene instradata alla replica del modello specifica selezionata dall'estensione Endpoint Picker.

Questo processo contribuisce a garantire che, anche quando le informazioni sul modello si trovano in profondità nel corpo della richiesta, GKE Inference Gateway possa instradare in modo intelligente il traffico ai servizi di backend corretti.

Configurare il routing basato sul corpo

L'estensione di routing basato sul corpo (BBR) per GKE Inference Gateway viene eseguita come servizio gestito all'interno del cluster Kubernetes. Dal punto di vista del bilanciatore del carico di livello 7, l'estensione BBR è un server gRPC esterno. Quando il bilanciatore del carico deve ispezionare il corpo di una richiesta per determinare il nome del modello, effettua una chiamata gRPC al servizio BBR. Il servizio BBR elabora quindi la richiesta e restituisce informazioni al bilanciatore del carico, ad esempio le intestazioni da inserire per il routing.

Per abilitare il routing basato sul corpo, esegui il deployment dell'estensione BBR come pod e integrala utilizzando le risorse GCPRoutingExtension e HTTPRoute.

Prerequisiti

Eseguire il deployment del router basato sul corpo

L'estensione di routing basato sul corpo viene sottoposta a deployment come deployment e servizio Kubernetes, insieme a una risorsa GCPRoutingExtension all'interno del cluster. Puoi utilizzare Helm per un'installazione semplificata.

Per eseguire il deployment delle risorse richieste per il router basato sul corpo, esegui il comando seguente:

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

Sostituisci GATEWAY_NAME con il nome della risorsa Gateway.

Questo comando esegue il deployment delle seguenti risorse:

  • Un servizio e un deployment per l'estensione di routing basato sul corpo.
  • Una risorsa GCPRoutingExtension e una risorsa GCPHealthCheckPolicy per collegare l'estensione di routing basato sul corpo alla risorsa GKE Gateway.

Configurare HTTPRoute per il routing basato sul modello

Dopo aver eseguito il deployment e la configurazione dell'estensione, puoi definire le risorse HTTPRoute che utilizzano l'intestazione inserita (X-Gateway-Model-Name) per le decisioni di routing.

Di seguito è riportato un esempio di manifest HTTPRoute per il routing basato sul modello:

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"

Per applicare questo manifest al cluster, salvalo come httproute-for-models.yaml ed esegui il comando seguente:

kubectl apply -f httproute-for-models.yaml

Considerazioni e limitazioni

Quando pianifichi l'implementazione del routing basato sul corpo, tieni presente quanto segue:

  • Comportamento di chiusura in caso di errore: l'estensione di routing basato sul corpo è progettata per operare in modalità "chiusura in caso di errore". Se l'estensione non è disponibile o non riesce a elaborare una richiesta, genera un errore (ad esempio, un codice di risposta 404 o 503 se non è configurato alcun backend predefinito) anziché instradare in modo errato. Assicurati che i deployment siano a elevata disponibilità per mantenere l'affidabilità del servizio.

  • Dimensioni del corpo della richiesta e streaming: l'elaborazione di corpi di richieste HTTP di grandi dimensioni, soprattutto con lo streaming abilitato, può introdurre complessità. Se il proxy Envoy è costretto a eseguire lo streaming del corpo della richiesta (in genere per i corpi superiori a 250 KB), potrebbe non essere in grado di inserire nuove intestazioni. Ciò può causare errori di routing (ad esempio, un errore 404 se non è possibile applicare le regole di corrispondenza delle intestazioni).

  • Manutenzione a lungo termine: l'estensione di routing basato sul corpo viene eseguita come componente all'interno dei cluster GKE. Sei responsabile della gestione del ciclo di vita, inclusi upgrade, patch di sicurezza e funzionamento continuo.

Passaggi successivi