Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

GKE Inference Gateway von v1alpha2 zu v1 migrieren

Autopilot Standard

Auf dieser Seite wird beschrieben, wie Sie Ihre GKE Inference Gateway-Einrichtung von der Preview-v1alpha2API zur allgemein verfügbaren v1API migrieren.

Dieses Dokument richtet sich an Plattformadministratoren und Netzwerkspezialisten, die die v1alpha2-Version des GKE Inference Gateway verwenden und auf die `v1`-Version aktualisieren möchten, um die neuesten Funktionen zu nutzen.

Bevor Sie mit der Migration beginnen, sollten Sie mit den Konzepten und der Bereitstellung des GKE Inference Gateway vertraut sein. Wir empfehlen Ihnen, die Informationen unter GKE Inference Gateway bereitstellen zu lesen.

Hinweis

Bevor Sie mit der Migration beginnen, prüfen Sie, ob Sie dieser Anleitung folgen müssen.

Nach vorhandenen `v1alpha2`-APIs suchen

Führen Sie die folgenden Befehle aus, um zu prüfen, ob Sie die v1alpha2-API des GKE Inference Gateway verwenden:

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

Die Ausgabe dieser Befehle bestimmt, ob Sie migrieren müssen:

Wenn einer der Befehle eine oder mehrere InferencePool- oder InferenceModel-Ressourcen zurückgibt, verwenden Sie die v1alpha2-API und müssen dieser Anleitung folgen.
Wenn beide Befehle No resources found zurückgeben, verwenden Sie die v1alpha2-API nicht. Sie können mit einer Neuinstallation des v1-GKE Inference Gateway fortfahren.

Migrationspfade

Es gibt zwei Möglichkeiten, von v1alpha2 zu v1 zu migrieren:

Einfache Migration (mit Ausfallzeiten) : Dieser Pfad ist schneller und einfacher, führt aber zu einer kurzen Ausfallzeit. Er wird empfohlen, wenn Sie keine Migration ohne Ausfallzeiten benötigen.
Migration ohne Ausfallzeiten:Dieser Pfad ist für Nutzer gedacht, die sich keine Dienstunterbrechung leisten können. Dabei werden sowohl v1alpha2- als auch v1-Stacks parallel ausgeführt und der Traffic wird schrittweise verlagert.

Einfache Migration (mit Ausfallzeiten)

In diesem Abschnitt wird beschrieben, wie Sie eine einfache Migration mit Ausfallzeiten durchführen.

Vorhandene v1alpha2 Ressourcen löschen: Wählen Sie eine der folgenden Optionen aus, um die v1alpha2 Ressourcen zu löschen:

Option 1: Mit Helm deinstallieren
```
helm uninstall HELM_PREVIEW_INFERENCEPOOL_NAME
```
Option 2: Ressourcen manuell löschen

Wenn Sie Helm nicht verwenden, löschen Sie alle Ressourcen, die mit Ihrer v1alpha2-Bereitstellung verknüpft sind, manuell:
- Aktualisieren oder löschen Sie die HTTPRoute, um die backendRef zu entfernen, die auf den v1alpha2-InferencePool verweist.
- Löschen Sie den v1alpha2-InferencePool, alle InferenceModel-Ressourcen, die darauf verweisen, und die entsprechende Endpoint Picker (EPP)-Bereitstellung und den entsprechenden Dienst.
Nachdem alle v1alpha2 benutzerdefinierten Ressourcen gelöscht wurden, entfernen Sie die benutzerdefinierten Ressourcendefinitionen (CRDs) aus Ihrem Cluster:
```
kubectl delete -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v0.3.0/manifests.yaml
```
v1-Ressourcen installieren: Nachdem Sie die alten Ressourcen bereinigt haben, installieren Sie das v1 GKE Inference Gateway. Dieser Vorgang umfasst Folgendes:
1. Installieren Sie die neuen benutzerdefinierten v1-Ressourcendefinitionen (CRDs).
2. Erstellen Sie einen neuen v1-InferencePool und die entsprechenden InferenceObjective-Ressourcen. Die InferenceObjective-Ressource ist weiterhin in der v1alpha2-API definiert.
3. Erstellen Sie eine neue HTTPRoute, die den Traffic an Ihren neuen v1-InferencePool weiterleitet.

Bereitstellung prüfen: Prüfen Sie nach einigen Minuten, ob Ihr neuer v1 Stack den Traffic korrekt verarbeitet.

Prüfen Sie, ob der Gateway-Status PROGRAMMED ist:

kubectl get gateway -o wide

Die Ausgabe sollte ungefähr so aussehen:

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

Prüfen Sie den Endpunkt, indem Sie eine Anfrage senden:

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}'

Achten Sie darauf, dass Sie eine erfolgreiche Antwort mit dem Antwortcode 200 erhalten.

Migration ohne Ausfallzeiten

Dieser Migrationspfad ist für Nutzer gedacht, die sich keine Dienstunterbrechung leisten können. Das folgende Diagramm zeigt, wie das GKE Inference Gateway die Bereitstellung mehrerer generativer KI-Modelle ermöglicht. Dies ist ein wichtiger Aspekt einer Migrationsstrategie ohne Ausfallzeiten.

Anfragen anhand von Modellname und Priorität an verschiedene Modelle weiterleiten — **Abbildung:** GKE Inference Gateway leitet Anfragen basierend auf dem Modellnamen und der Priorität an verschiedene generative KI-Modelle weiter.

API-Versionen mit kubectl unterscheiden

Während der Migration ohne Ausfallzeiten werden sowohl v1alpha2 als auch v1 CRDs in Ihrem Cluster installiert. Dies kann zu Unklarheiten führen, wenn Sie kubectl verwenden, um InferencePool-Ressourcen abzufragen. Um sicherzustellen, dass Sie mit der richtigen Version interagieren, müssen Sie den vollständigen Ressourcennamen verwenden:

Für v1alpha2:

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

Für v1:

kubectl get inferencepools.inference.networking.k8s.io

Die v1-API bietet auch einen praktischen Kurznamen, infpool, mit dem Sie speziell v1-Ressourcen abfragen können:

kubectl get infpool

Phase 1: Parallele `v1`-Bereitstellung

In dieser Phase stellen Sie den neuen `v1`-InferencePool-Stack neben dem vorhandenen `v1alpha2`-Stack bereit, was eine sichere, schrittweise Migration ermöglicht.

Nachdem Sie alle Schritte in dieser Phase abgeschlossen haben, haben Sie die folgende Infrastruktur im folgenden Diagramm:

Installieren Sie die erforderlichen benutzerdefinierten Ressourcendefinitionen (CRDs) in Ihrem GKE-Cluster:
- Führen Sie für GKE-Versionen vor 1.34.0-gke.1626000 den folgenden Befehl aus, um sowohl die `v1`-InferencePool- als auch die Alpha-InferenceObjective-CRDs zu installieren:
```
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v1.0.0/manifests.yaml
```
- Installieren Sie für GKE-Versionen 1.34.0-gke.1626000 oder höher nur die Alpha-InferenceObjective-CRD, indem Sie den folgenden Befehl ausführen:
```
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
```
Hinweis: Ab GKE-Versionen 1.34.0-gke.1626000 verwaltet Google Kubernetes Engine automatisch die `v1`-InferencePool-CRD. Sie müssen nur die Alpha-InferenceObjective-CRD installieren. Wenn Sie versuchen, die `v1`-InferencePool-CRD zu installieren, können unerwartete Probleme auftreten und eine Warnung wird angezeigt.
Installieren Sie den v1 InferencePool.

Verwenden Sie Helm, um einen neuen v1 InferencePool mit einem eindeutigen Releasenamen, wie vllm-llama3-8b-instruct-ga zu installieren. Der InferencePool muss mit inferencePool.modelServers.matchLabels.app auf dieselben Modellserver-Pods wie der Alpha-InferencePool ausgerichtet sein.

Verwenden Sie den folgenden Befehl, um den InferencePool zu installieren:
```
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
```
Ersetzen Sie Folgendes:
- MODEL_SERVER_DEPLOYMENT_LABEL: Das Label, das von Ihren vorhandenen Modellserver-Pods verwendet wird (z. B. vllm-llama3-8b-instruct-preview).
- RELEASE: Die Version des Helm-Diagramms für die Inference Extension der v1-Gateway API, die Sie installieren möchten

v1alpha2 InferenceObjective-Ressourcen erstellen.

Im Rahmen der Migration zur Version 1.0 der Gateway API Inference Extension müssen wir auch von der Alpha-InferenceModel-API zur neuen InferenceObjective-API migrieren.

Wenden Sie die folgende YAML-Datei an, um die InferenceObjective-Ressourcen zu erstellen:

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

Phase 2: Traffic verlagern

Wenn beide Stacks ausgeführt werden, können Sie den Traffic von v1alpha2 zu v1 verlagern, indem Sie die HTTPRoute aktualisieren, um den Traffic aufzuteilen. In diesem Beispiel wird eine Aufteilung von 50:50 gezeigt.

`HTTPRoute` für die Trafficaufteilung aktualisieren.

Führen Sie den folgenden Befehl aus, um die HTTPRoute für die Trafficaufteilung zu aktualisieren:

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

Prüfen und beobachten.

Beobachten Sie nach dem Anwenden der Änderungen die Leistung und Stabilität des neuen v1-Stacks. Prüfen Sie, ob der Status von inference-gateway PROGRAMMED und TRUE ist.

Phase 3: Abschluss und Bereinigung

Nachdem Sie sich vergewissert haben, dass der v1 InferencePool stabil ist, können Sie den gesamten Traffic darauf umleiten und die alten v1alpha2 Ressourcen außer Betrieb nehmen.

100% des Traffics an den v1 InferencePool verlagern.

Führen Sie den folgenden Befehl aus, um 100 % des Traffics an den v1 InferencePool zu verlagern:

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

Abschließende Prüfung durchführen.

Nachdem Sie den gesamten Traffic an den v1-Stack weitergeleitet haben, prüfen Sie, ob er den gesamten Traffic wie erwartet verarbeitet.