Esta página foi traduzida pela API Cloud Translation.

Migre o GKE Inference Gateway da versão v1alpha2 para a v1

Autopilot Padrão

Esta página explica como migrar a configuração do GKE Inference Gateway da API de pré-visualização v1alpha2 para a API v1 geralmente disponível.

Este documento destina-se a administradores de plataformas e especialistas em redes que estão a usar a versão v1alpha2 do GKE Inference Gateway e querem atualizar para a versão v1 para usar as funcionalidades mais recentes.

Antes de iniciar a migração, certifique-se de que conhece os conceitos e a implementação do GKE Inference Gateway. Recomendamos que reveja o artigo Implemente o gateway de inferência do GKE.

Antes de começar

Antes de iniciar a migração, determine se tem de seguir este guia.

Verifique se existem APIs v1alpha2

Para verificar se está a usar a v1alpha2API GKE Inference Gateway, execute os seguintes comandos:

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

O resultado destes comandos determina se tem de fazer a migração:

Se qualquer um dos comandos devolver um ou mais recursos InferencePool ou InferenceModel, está a usar a API v1alpha2 e tem de seguir este guia.
Se ambos os comandos devolverem No resources found, não está a usar a API v1alpha2. Pode prosseguir com uma nova instalação do v1 GKE Inference Gateway.

Caminhos de migração

Existem dois caminhos para migrar de v1alpha2 para v1:

Migração simples (com tempo de inatividade): este caminho é mais rápido e simples, mas resulta num breve período de inatividade. É o caminho recomendado se não precisar de uma migração sem tempo de inatividade.
Migração sem indisponibilidade: este caminho destina-se a utilizadores que não podem ter nenhuma interrupção do serviço. Envolve a execução de ambas as pilhas v1alpha2 e v1 lado a lado e a mudança gradual do tráfego.

Migração simples (com tempo de inatividade)

Esta secção descreve como fazer uma migração simples com tempo de inatividade.

Eliminar recursos v1alpha2 existentes: para eliminar os recursos v1alpha2, escolha uma das seguintes opções:

Opção 1: desinstale através do Helm
```
helm uninstall HELM_PREVIEW_INFERENCEPOOL_NAME
```
Opção 2: elimine recursos manualmente

Se não estiver a usar o Helm, elimine manualmente todos os recursos associados à sua implementação do v1alpha2:
- Atualize ou elimine o HTTPRoute para remover o backendRef que aponta para o v1alpha2 InferencePool.
- Elimine o v1alpha2 InferencePool, todos os recursos InferenceModel que apontam para ele e a implementação e o serviço do selecionador de pontos finais (EPP) correspondentes.
Depois de eliminar todos os recursos personalizados v1alpha2, remova as definições de recursos personalizados (CRD) do cluster:
```
kubectl delete -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v0.3.0/manifests.yaml
```
Instale recursos da v1: depois de limpar os recursos antigos, instale o v1 GKE Inference Gateway. Este processo envolve o seguinte:
1. Instale as novas v1definições de recursos personalizados (CRDs).
2. Crie um novo v1 InferencePool e os recursos InferenceObjective correspondentes. O recurso InferenceObjective ainda está definido na API v1alpha2.
3. Crie um novo HTTPRoute que direcione o tráfego para o seu novo v1 InferencePool.

Valide a implementação: após alguns minutos, valide se a nova v1 estrutura está a publicar corretamente o tráfego.

Confirme se o estado do gateway é PROGRAMMED:

kubectl get gateway -o wide

O resultado deve ser semelhante ao seguinte:

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

Valide o ponto final enviando um pedido:

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

Certifique-se de que recebe uma resposta bem-sucedida com um código de resposta 200.

Migração sem tempo de inatividade

Este caminho de migração foi concebido para utilizadores que não podem ter nenhuma interrupção do serviço. O diagrama seguinte ilustra como o GKE Inference Gateway facilita a publicação de vários modelos de IA generativa, um aspeto fundamental de uma estratégia de migração sem tempo de inatividade.

Encaminhar pedidos para diferentes modelos com base no nome do modelo e na prioridade — **Figura:** pedidos de encaminhamento do GKE Inference Gateway para diferentes modelos de IA generativa com base no nome e na prioridade do modelo

Distinguir versões da API com o kubectl

Durante a migração sem tempo de inatividade, os CRDs v1alpha2 e v1 são instalados no cluster. Isto pode criar ambiguidade quando usa kubectl para consultar recursos InferencePool. Para garantir que está a interagir com a versão correta, tem de usar o nome completo do recurso:

Para v1alpha2:

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

Para v1:

kubectl get inferencepools.inference.networking.k8s.io

A API v1 também fornece um nome abreviado útil, infpool, que pode usar para consultar recursos v1 especificamente:

kubectl get infpool

Fase 1: implementação lado a lado da versão 1

Nesta fase, implementa a nova pilha InferencePool v1 juntamente com a pilha v1alpha2 existente, o que permite uma migração segura e gradual.

Depois de concluir todos os passos desta fase, tem a seguinte infraestrutura no diagrama seguinte:

Instale as definições de recursos personalizados (CRDs) necessárias no seu cluster do GKE:
- Para versões do GKE anteriores à 1.34.0-gke.1626000, execute o seguinte comando para instalar os CRDs InferencePool v1 e InferenceObjective alfa:
```
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/download/v1.0.0/manifests.yaml
```
- Para as versões do GKE 1.34.0-gke.1626000 ou posteriores, instale apenas o CRD alfa InferenceObjective executando o seguinte 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 das versões 1.34.0-gke.1626000 do GKE, o Google Kubernetes Engine gere automaticamente o CRD v1 InferencePool. Só tem de instalar o CRD alfa. InferenceObjective A tentativa de instalação do CRD v1 pode causar problemas inesperados e resultar num aviso.
InferencePool
Instale o v1 InferencePool.

Use o Helm para instalar um novo v1 InferencePool com um nome de lançamento distinto, como vllm-llama3-8b-instruct-ga. O InferencePool tem de segmentar os mesmos pods do servidor de modelos que o InferencePool alfa usando inferencePool.modelServers.matchLabels.app.

Para instalar o InferencePool, use o seguinte 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
```

Crie recursos v1alpha2 InferenceObjective.

Como parte da migração para a versão v1.0 da extensão de inferência da API Gateway, também temos de migrar da API InferenceModel alfa para a nova API InferenceObjective.

Aplique o YAML seguinte para criar os 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

Fase 2: mudança de tráfego

Com ambas as pilhas em execução, pode começar a transferir tráfego de v1alpha2 para v1 atualizando o HTTPRoute para dividir o tráfego. Este exemplo mostra uma divisão de 50/50.

Atualize o HTTPRoute para a divisão de tráfego.

Para atualizar o HTTPRoute para a divisão do tráfego, execute o seguinte 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

Validar e monitorizar.

Depois de aplicar as alterações, monitorize o desempenho e a estabilidade da nova v1 pilha. Verifique se o gateway tem um PROGRAMMED estado de TRUE.inference-gateway

Fase 3: finalização e limpeza

Depois de verificar que o v1 InferencePool está estável, pode direcionar todo o tráfego para o mesmo e desativar os recursos v1alpha2 antigos.

Mude 100% do tráfego para o v1 InferencePool.

Para transferir 100% do tráfego para o v1 InferencePool, execute o seguinte 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

Faça a validação final.

Depois de direcionar todo o tráfego para a pilha v1, verifique se está a processar todo o tráfego conforme esperado.