Se usó la API de Cloud Translation para traducir esta página.

Migra la puerta de enlace de GKE Inference de v1alpha2 a v1

Autopilot estándar

En esta página, se explica cómo migrar la configuración de tu puerta de enlace de GKE Inference de la API en versión preliminar v1alpha2 a la API v1 disponible de forma general.

Este documento está dirigido a los administradores de plataformas y especialistas en redes que usan la versión v1alpha2 de GKE Inference Gateway y desean actualizar a la versión v1 para usar las funciones más recientes.

Antes de comenzar la migración, asegúrate de conocer los conceptos y la implementación de la puerta de enlace de inferencia de GKE. Te recomendamos que revises Cómo implementar la puerta de enlace de GKE Inference.

Antes de comenzar

Antes de comenzar la migración, determina si necesitas seguir esta guía.

Verifica si existen APIs de v1alpha2

Para verificar si usas la API de v1alpha2 GKE Inference Gateway, ejecuta los siguientes comandos:

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

El resultado de estos comandos determina si necesitas migrar:

Si alguno de los comandos devuelve uno o más recursos InferencePool o InferenceModel, significa que estás usando la API de v1alpha2 y debes seguir esta guía.
Si ambos comandos devuelven No resources found, no estás usando la API de v1alpha2. Puedes continuar con una instalación nueva de la v1puerta de enlace de inferencia de GKE.

Rutas de migración

Existen dos rutas para migrar de v1alpha2 a v1:

Migración simple (con tiempo de inactividad): Esta ruta es más rápida y sencilla, pero genera un breve período de inactividad. Es la ruta recomendada si no necesitas una migración sin tiempo de inactividad.
Migración sin tiempo de inactividad: Esta ruta es para los usuarios que no pueden permitirse ninguna interrupción del servicio. Implica ejecutar las pilas de v1alpha2 y v1 de forma paralela y cambiar el tráfico de forma gradual.

Migración simple (con tiempo de inactividad)

En esta sección, se describe cómo realizar una migración simple con tiempo de inactividad.

Borrar recursos v1alpha2 existentes: Para borrar los recursos v1alpha2, elige una de las siguientes opciones:

Opción 1: Desinstala con Helm
```
helm uninstall HELM_PREVIEW_INFERENCEPOOL_NAME
```
Opción 2: Borra los recursos de forma manual

Si no usas Helm, borra manualmente todos los recursos asociados con tu implementación de v1alpha2:
- Actualiza o borra el HTTPRoute para quitar el backendRef que apunta al v1alpha2 InferencePool.
- Borra el v1alpha2 InferencePool, todos los recursos InferenceModel que lo señalen y la Deployment y el servicio correspondientes del Selector de extremos (EPP).
Después de borrar todos los recursos personalizados v1alpha2, quita las definiciones de recursos personalizados (CRD) de tu clúster:
```
kubectl delete -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v0.3.0/manifests.yaml
```
Instala recursos de la versión 1: Después de limpiar los recursos antiguos, instala la puerta de enlace de inferencia de GKE v1. Este proceso implica lo siguiente:
1. Instala las nuevas definiciones de recursos personalizados (CRD) de v1.
2. Crea un v1 InferencePool y los recursos InferenceObjective correspondientes. El recurso InferenceObjective aún se define en la API de v1alpha2.
3. Crea un nuevo HTTPRoute que dirija el tráfico a tu nuevo v1 InferencePool.

Verifica la implementación: Después de unos minutos, verifica que tu nueva pila de v1 entregue tráfico correctamente.

Confirma que el estado de la puerta de enlace sea PROGRAMMED:

kubectl get gateway -o wide

El resultado debe ser similar a este:

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

Envía una solicitud para verificar el extremo:

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

Asegúrate de recibir una respuesta exitosa con un código de respuesta 200.

Migración sin tiempo de inactividad

Esta ruta de migración está diseñada para los usuarios que no pueden permitirse ninguna interrupción del servicio. En el siguiente diagrama, se ilustra cómo GKE Inference Gateway facilita la entrega de varios modelos de IA generativa, un aspecto clave de una estrategia de migración sin tiempo de inactividad.

Enrutamiento de solicitudes a diferentes modelos según el nombre y la prioridad del modelo — **Figura:** GKE Inference Gateway enruta solicitudes a diferentes modelos de IA generativa según el nombre y la prioridad del modelo

Cómo distinguir las versiones de la API con kubectl

Durante la migración sin tiempo de inactividad, se instalan los CRD de v1alpha2 y v1 en tu clúster. Esto puede generar ambigüedad cuando se usa kubectl para consultar recursos InferencePool. Para asegurarte de interactuar con la versión correcta, debes usar el nombre completo del recurso:

Para v1alpha2:

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

Para v1:

kubectl get inferencepools.inference.networking.k8s.io

La API de v1 también proporciona un nombre corto conveniente, infpool, que puedes usar para consultar recursos de v1 específicamente:

kubectl get infpool

Etapa 1: Implementación de la versión 1 en paralelo

En esta etapa, implementas la nueva pila de InferencePool v1 junto con la pila existente de v1alpha2, lo que permite una migración segura y gradual.

Después de completar todos los pasos de esta etapa, tendrás la siguiente infraestructura, como se muestra en el siguiente diagrama:

Instala las definiciones de recursos personalizados (CRD) necesarias en tu clúster de GKE:
- Para las versiones de GKE anteriores a 1.34.0-gke.1626000, ejecuta el siguiente comando para instalar los CRD de v1 InferencePool y alfa InferenceObjective:
```
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v1.0.0/manifests.yaml
```
- Para las versiones de GKE 1.34.0-gke.1626000 o posteriores, instala solo la CRD InferenceObjective alfa ejecutando el siguiente comando:
```
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
```
Nota: A partir de las versiones 1.34.0-gke.1626000 de GKE, Google Kubernetes Engine administra automáticamente el CRD InferencePool de la versión 1. Solo debes instalar la CRD InferenceObjective alfa. Si intentas instalar la CRD InferencePool v1, es posible que se produzcan problemas inesperados y se muestre una advertencia.
Instala el v1 InferencePool.

Usa Helm para instalar un nuevo v1 InferencePool con un nombre de versión distinto, como vllm-llama3-8b-instruct-ga. El InferencePool debe segmentarse para los mismos pods de Model Server que el InferencePool alfa con inferencePool.modelServers.matchLabels.app.

Para instalar InferencePool, usa el siguiente comando:
```
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
```

Crea recursos v1alpha2 InferenceObjective.

Como parte de la migración a la versión 1.0 de la extensión de inferencia de la API de Gateway, también debemos migrar de la API de InferenceModel alfa a la nueva API de InferenceObjective.

Aplica el siguiente YAML para crear los recursos 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

Etapa 2: Transferencia del tráfico

Con ambas pilas en ejecución, puedes comenzar a transferir el tráfico de v1alpha2 a v1 actualizando HTTPRoute para dividir el tráfico. En este ejemplo, se muestra una división del 50%.

Actualiza HTTPRoute para la división del tráfico.

Para actualizar el HTTPRoute para la división del tráfico, ejecuta el siguiente comando:

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

Verifica y supervisa.

Después de aplicar los cambios, supervisa el rendimiento y la estabilidad de la nueva pila de v1. Verifica que la puerta de enlace inference-gateway tenga el estado PROGRAMMED de TRUE.

Etapa 3: Finalización y limpieza

Una vez que hayas verificado que el v1 InferencePool es estable, puedes dirigir todo el tráfico a él y retirar los recursos v1alpha2 antiguos.

Transfiere el 100% del tráfico a v1 InferencePool.

Para dirigir el 100% del tráfico a v1 InferencePool, ejecuta el siguiente comando:

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

Realiza la verificación final.

Después de dirigir todo el tráfico a la pila v1, verifica que esté controlando todo el tráfico según lo esperado.