Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

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-Version der v1alpha2 API zur allgemein verfügbaren v1 API migrieren.

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

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

Hinweis

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

Nach vorhandenen v1alpha2-APIs suchen

Mit den folgenden Befehlen können Sie prüfen, ob Sie die v1alpha2 GKE Inference Gateway API 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 beiden 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 Ausfallzeit): Dieser Pfad ist schneller und einfacher, führt aber zu einer kurzen Ausfallzeit. Dies ist der empfohlene Weg, wenn Sie keine Migration ohne Ausfallzeiten benötigen.
Migration ohne Ausfallzeiten:Dieser Pfad ist für Nutzer gedacht, die sich keine Unterbrechung des Dienstes leisten können. Dabei werden sowohl v1alpha2- als auch v1-Stacks parallel ausgeführt und der Traffic wird schrittweise umgeleitet.

Einfache Migration (mit Ausfallzeit)

In diesem Abschnitt wird beschrieben, wie Sie eine einfache Migration mit Ausfallzeit 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 das HTTPRoute, um das backendRef zu entfernen, das auf das v1alpha2 InferencePool verweist.
- Löschen Sie die InferencePool v1alpha2, alle InferenceModel-Ressourcen, die darauf verweisen, sowie die entsprechende Endpoint Picker (EPP)-Bereitstellung und den entsprechenden Dienst.
Nachdem alle benutzerdefinierten v1alpha2-Ressourcen gelöscht wurden, entfernen Sie die benutzerdefinierten Ressourcendefinitionen (CRD) 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 Prozess umfasst Folgendes:
1. Installieren Sie die neuen benutzerdefinierten Ressourcendefinitionen (CRDs) für v1.
2. Erstellen Sie eine neue v1-InferencePool und entsprechende InferenceObjective-Ressourcen. Die Ressource InferenceObjective ist weiterhin in der v1alpha2 API definiert.
3. Erstellen Sie eine neue HTTPRoute, die Traffic an Ihre neue v1-InferencePool weiterleitet.

Bereitstellung überprüfen: Prüfen Sie nach einigen Minuten, ob Ihr neuer v1-Stack Traffic richtig bereitstellt.

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

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

Sie sollten eine erfolgreiche Antwort mit dem Antwortcode 200 erhalten.

Migration ohne Ausfallzeiten

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

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

API-Versionen mit kubectl unterscheiden

Während der Migration ohne Ausfallzeiten sind sowohl v1alpha2- als auch v1-CRDs in Ihrem Cluster installiert. Dies kann zu Unklarheiten führen, wenn Sie kubectl verwenden, um InferencePool-Ressourcen abzufragen. Damit 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 Bereitstellung von Version 1

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

Nachdem Sie alle Schritte in dieser Phase abgeschlossen haben, haben Sie die folgende Infrastruktur (siehe 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 ab 1.34.0-gke.1626000 nur die Alpha-InferenceObjective-CRD. Führen Sie dazu den folgenden Befehl aus:
```
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-Version 1.34.0-gke.1626000 verwaltet Google Kubernetes Engine automatisch die CRD v1 InferencePool. Sie müssen nur die Alpha-CRD InferenceObjective installieren. Wenn Sie versuchen, die v1-CRD InferencePool zu installieren, kann dies zu unerwarteten Problemen und einer Warnung führen.
Installieren Sie das v1 InferencePool.

Installieren Sie mit Helm eine neue v1 InferencePool mit einem eindeutigen Releasenamen, z. B. vllm-llama3-8b-instruct-ga. Das InferencePool muss mit inferencePool.modelServers.matchLabels.app auf dieselben Model Server-Pods wie das Alpha-InferencePool ausgerichtet sein.

Verwenden Sie zum Installieren von InferencePool den folgenden Befehl:
```
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-Charts für die v1 Gateway API Inference Extension, 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-API InferenceModel zur neuen API InferenceObjective 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-Verschiebung

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

HTTPRoute für die Aufteilung des Traffics aktualisieren.

Führen Sie den folgenden Befehl aus, um die HTTPRoute für die Aufteilung des Traffics 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

Überprüfen und überwachen

Beobachten Sie nach der Anwendung der Änderungen die Leistung und Stabilität des neuen v1-Stacks. Prüfen Sie, ob das inference-gateway-Gateway den PROGRAMMED-Status TRUE hat.

Phase 3: Abschluss und Bereinigung

Nachdem Sie überprüft haben, ob die v1 InferencePool stabil ist, können Sie den gesamten Traffic dorthin leiten und die alten v1alpha2-Ressourcen außer Betrieb nehmen.

100% des Traffics zur v1 InferencePool verschieben:

Führen Sie den folgenden Befehl aus, um 100 % des Traffics auf v1 InferencePool umzustellen:

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

Führen Sie die endgültige Bestätigung durch.

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