Esegui la migrazione di GKE Inference Gateway dalla versione v1alpha2 alla v1

Questa pagina spiega come eseguire la migrazione della configurazione di GKE Inference Gateway dall' API v1alpha2 in anteprima all'API v1 disponibile a livello generale.

Questo documento è destinato agli amministratori di piattaforme e agli specialisti di networking che utilizzano la versione v1alpha2 di GKE Inference Gateway e vogliono eseguire l'upgrade alla versione v1 per utilizzare le funzionalità più recenti.

Prima di iniziare la migrazione, assicurati di conoscere i concetti e il deployment di GKE Inference Gateway. Ti consigliamo di consultare la pagina Eseguire il deployment di GKE Inference Gateway.

Prima di iniziare

Prima di iniziare la migrazione, determina se devi seguire questa guida.

Verificare la presenza di API v1alpha2 esistenti

Per verificare se utilizzi l'API v1alpha2 di GKE Inference Gateway, esegui i seguenti comandi:

kubectl get inferencepools.inference.networking.x-k8s.io --all-namespaces
kubectl get inferencemodels.inference.networking.x-k8s.io --all-namespaces

L'output di questi comandi determina se devi eseguire la migrazione:

• Se uno dei due comandi restituisce una o più risorse InferencePool o InferenceModel, significa che utilizzi l'API v1alpha2 e devi seguire questa guida.
• Se entrambi i comandi restituiscono No resources found, significa che non utilizzi l'API v1alpha2. Puoi procedere con una nuova installazione di v1 GKE Inference Gateway.

Percorsi di migrazione

Esistono due percorsi per la migrazione da v1alpha2 a v1:

• Migrazione semplice (con tempi di inattività): questo percorso è più veloce e semplice, ma comporta un breve periodo di inattività. È il percorso consigliato se non hai bisogno di una migrazione senza tempi di inattività.
• Migrazione senza tempi di inattività: questo percorso è destinato agli utenti che non possono permettersi interruzioni del servizio. Comporta l'esecuzione di stack v1alpha2 e v1 affiancati e lo spostamento graduale del traffico.

Migrazione semplice (con tempi di inattività)

Questa sezione descrive come eseguire una migrazione semplice con tempi di inattività.

1. Elimina le risorse v1alpha2 esistenti: per eliminare le v1alpha2 risorse, scegli una delle seguenti opzioni:

   Opzione 1: disinstallare utilizzando Helm

   helm uninstall HELM_PREVIEW_INFERENCEPOOL_NAME
   

   Opzione 2: eliminare manualmente le risorse

   Se non utilizzi Helm, elimina manualmente tutte le risorse associate al deployment v1alpha2:

   • Aggiorna o elimina HTTPRoute per rimuovere backendRef che rimanda a v1alpha2 InferencePool.
   • Elimina v1alpha2 InferencePool, tutte le risorse InferenceModel che rimandano a questa risorsa e il deployment e il servizio Endpoint Picker (EPP) corrispondenti.

   Dopo aver eliminato tutte le risorse personalizzate v1alpha2, rimuovi le definizioni di risorse personalizzate (CRD) dal cluster:

   kubectl delete -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v0.3.0/manifests.yaml
   

2. Installa le risorse v1: dopo aver liberato spazio dalle vecchie risorse, installa v1 GKE Inference Gateway. Questa procedura prevede quanto segue:

   1. Installa le nuove definizioni di risorse personalizzate (CRD) v1.
   2. Crea una nuova risorsa v1 InferencePool e le risorse InferenceObjective corrispondenti. La risorsa InferenceObjective è ancora definita nell'API v1alpha2.
   3. Crea una nuova risorsa HTTPRoute che indirizzi il traffico al nuovo v1 InferencePool.

3. Verifica il deployment: dopo qualche minuto, verifica che il nuovo v1 stack gestisca correttamente il traffico.

   1. Verifica che lo stato del gateway sia PROGRAMMED:

      kubectl get gateway -o wide
      

      L'output dovrebbe essere simile a questo:

      NAME                CLASS                            ADDRESS        PROGRAMMED   AGE
      inference-gateway   gke-l7-regional-external-managed   <IP_ADDRESS>   True         10m
      

   2. Verifica l'endpoint inviando una richiesta:

      IP=$(kubectl get gateway/inference-gateway -o jsonpath='{.status.addresses[0].value}')
      PORT=80
      curl -i ${IP}:${PORT}/v1/completions -H 'Content-Type: application/json' -d '{"model": "<var>YOUR_MODEL</var>","prompt": "<var>YOUR_PROMPT</var>","max_tokens": 100,"temperature": 0}'
      

   3. Assicurati di ricevere una risposta positiva con un codice di risposta 200.

Migrazione senza tempi di inattività

Questo percorso di migrazione è progettato per gli utenti che non possono permettersi interruzioni del servizio. Il seguente diagramma illustra come GKE Inference Gateway facilita la gestione di più modelli di AI generativa, un aspetto fondamentale di una strategia di migrazione senza tempi di inattività.

Distinguere le versioni dell'API con kubectl

Durante la migrazione senza tempi di inattività, nel cluster vengono installate sia le CRD v1alpha2 sia le CRD v1. Questo può creare ambiguità quando utilizzi kubectl per eseguire query sulle risorse InferencePool. Per assicurarti di interagire con la versione corretta, devi utilizzare il nome completo della risorsa:

• Per v1alpha2:

  kubectl get inferencepools.inference.networking.x-k8s.io
  

• Per v1:

  kubectl get inferencepools.inference.networking.k8s.io
  

L'API v1 fornisce anche un nome breve pratico, infpool, che puoi utilizzare per eseguire query specifiche sulle risorse v1:

kubectl get infpool

Fase 1: deployment v1 affiancato

In questa fase, esegui il deployment del nuovo stack v1 InferencePool insieme allo stack v1alpha2 esistente, il che consente una migrazione graduale e sicura.

Dopo aver completato tutti i passaggi di questa fase, avrai la seguente infrastruttura nel seguente diagramma:

1. Installa le definizioni di risorse personalizzate (CRD) necessarie nel cluster GKE:

   • Per le versioni di GKE precedenti a 1.34.0-gke.1626000, esegui il comando seguente per installare sia le CRD InferencePool v1 sia le CRD InferenceObjective alpha:

   kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v1.0.0/manifests.yaml
   

   • Per le versioni di GKE 1.34.0-gke.1626000 o successive, installa solo la CRD InferenceObjective alpha eseguendo il comando seguente:

   kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/raw/v1.0.0/config/crd/bases/inference.networking.x-k8s.io_inferenceobjectives.yaml
   

2. Installa v1 InferencePool.

   Utilizza Helm per installare un nuovo v1 InferencePool con un nome di release distinto, ad esempio vllm-llama3-8b-instruct-ga. InferencePool deve avere come target gli stessi pod del server dei modelli di InferencePool alpha utilizzando inferencePool.modelServers.matchLabels.app.

   Per installare InferencePool, utilizza il comando seguente:

   helm install vllm-llama3-8b-instruct-ga \
   --set inferencePool.modelServers.matchLabels.app=MODEL_SERVER_DEPLOYMENT_LABEL \
   --set provider.name=gke \
   --version RELEASE \
   oci://registry.k8s.io/gateway-api-inference-extension/charts/inferencepool
   

   Sostituisci quanto segue:

   • MODEL_SERVER_DEPLOYMENT_LABEL: l'etichetta utilizzata dai pod del server dei modelli esistenti (ad esempio, vllm-llama3-8b-instruct-preview).
   • RELEASE: la versione del grafico Helm dell'estensione di inferenza dell'API Gateway v1 che vuoi installare

3. Crea risorse v1alpha2 InferenceObjective.

   Nell'ambito della migrazione alla release v1.0 dell'estensione di inferenza dell'API Gateway, dobbiamo anche eseguire la migrazione dall'API InferenceModel alpha alla nuova API InferenceObjective.

   1. Applica il seguente YAML per creare le risorse InferenceObjective:

      kubectl apply -f - <<EOF
      ---
      apiVersion: inference.networking.x-k8s.io/v1alpha2
      kind: InferenceObjective
      metadata:
        name: food-review
      spec:
        priority: 2
        poolRef:
          group: inference.networking.k8s.io
          name: vllm-llama3-8b-instruct-ga
      ---
      apiVersion: inference.networking.x-k8s.io/v1alpha2
      kind: InferenceObjective
      metadata:
        name: base-model
      spec:
        priority: 2
        poolRef:
          group: inference.networking.k8s.io
          name: vllm-llama3-8b-instruct-ga
      ---
      EOF
      

Fase 2: spostamento del traffico

Con entrambi gli stack in esecuzione, puoi iniziare a spostare il traffico da v1alpha2 a v1 aggiornando HTTPRoute per suddividere il traffico. Questo esempio mostra una suddivisione 50-50.

1. Aggiorna HTTPRoute per la suddivisione del traffico.

   Per aggiornare HTTPRoute per la suddivisione del traffico, esegui il comando seguente:

   kubectl apply -f - <<EOF
   ---
   apiVersion: gateway.networking.k8s.io/v1
   kind: HTTPRoute
   metadata:
     name: llm-route
   spec:
     parentRefs:
     - group: gateway.networking.k8s.io
       kind: Gateway
       name: inference-gateway
     rules:
     - backendRefs:
       - group: inference.networking.x-k8s.io
         kind: InferencePool
         name: vllm-llama3-8b-instruct-preview
         weight: 50
       - group: inference.networking.k8s.io
         kind: InferencePool
         name: vllm-llama3-8b-instruct-ga
         weight: 50
   ---
   EOF
   

2. Verifica e monitora.

   Dopo aver applicato le modifiche, monitora le prestazioni e la stabilità del nuovo stack v1. Verifica che il gateway inference-gateway abbia uno stato PROGRAMMED di TRUE.

Fase 3: finalizzazione e pulizia

Dopo aver verificato che v1 InferencePool sia stabile, puoi indirizzare tutto il traffico a questa risorsa e dismettere le vecchie risorse v1alpha2.

1. Sposta il 100% del traffico su v1 InferencePool.

   Per spostare il 100% del traffico su v1 InferencePool, esegui il comando seguente:

   kubectl apply -f - <<EOF
   ---
   apiVersion: gateway.networking.k8s.io/v1
   kind: HTTPRoute
   metadata:
     name: llm-route
   spec:
     parentRefs:
     - group: gateway.networking.k8s.io
       kind: Gateway
       name: inference-gateway
     rules:
     - backendRefs:
       - group: inference.networking.k8s.io
         kind: InferencePool
         name: vllm-llama3-8b-instruct-ga
         weight: 100
   ---
   EOF
   

2. Esegui la verifica finale.

   Dopo aver indirizzato tutto il traffico allo stack v1, verifica che gestisca tutto il traffico come previsto.

   1. Verifica che lo stato del gateway sia PROGRAMMED:

      kubectl get gateway -o wide
      

      L'output dovrebbe essere simile a questo:

      NAME                CLASS                              ADDRESS           PROGRAMMED   AGE
      inference-gateway   gke-l7-regional-external-managed   <IP_ADDRESS>   True                     10m
      

   2. Verifica l'endpoint inviando una richiesta:

      IP=$(kubectl get gateway/inference-gateway -o jsonpath='{.status.addresses[0].value}')
      PORT=80
      curl -i ${IP}:${PORT}/v1/completions -H 'Content-Type: application/json' -d '{
      "model": "YOUR_MODEL",
      "prompt": "YOUR_PROMPT",
      "max_tokens": 100,
      "temperature": 0
      }'
      

   3. Assicurati di ricevere una risposta positiva con un codice di risposta 200.

3. Esegui la pulizia delle risorse v1alpha2.

   Dopo aver verificato che lo stack v1 sia completamente operativo, rimuovi in sicurezza le vecchie v1alpha2 risorse.

4. Verifica la presenza di risorse v1alpha2 rimanenti.

   Ora che hai eseguito la migrazione all'API InferencePool v1, puoi eliminare le vecchie CRD in sicurezza. Verifica la presenza di API v1alpha2 esistenti per assicurarti di non avere più risorse v1alpha2 in uso. Se ne hai ancora alcune, puoi continuare la procedura di migrazione per queste risorse.

5. Elimina v1alpha2 CRD.

   Dopo aver eliminato tutte le risorse personalizzate v1alpha2, rimuovi le definizioni di risorse personalizzate (CRD) dal cluster:

   kubectl delete -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v0.3.0/manifests.yaml
   

   Dopo aver completato tutti i passaggi, la tua infrastruttura dovrebbe essere simile al seguente diagramma:

   

Passaggi successivi

• Scopri di più su come eseguire il deployment di GKE Inference Gateway.
  • Esplora altre funzionalità di networking di GKE.