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 conveniente, 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 o lançamento 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 inference-gateway tem o estado PROGRAMMED TRUE.

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.

Desvie 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.

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": "YOUR_MODEL,
"prompt": YOUR_PROMPT,
"max_tokens": 100,
"temperature": 0
}'

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

Limpe os recursos da versão v1alpha2.

Depois de confirmar que a pilha v1 está totalmente operacional, remova em segurança os recursos v1alpha2 antigos.
Verifique se existem recursos do v1alpha2 restantes.

Agora que migrou para a API v1 InferencePool, pode eliminar em segurança os CRDs antigos. Verifique se existem APIs v1alpha2 para garantir que já não tem recursos v1alpha2 em utilização. Se ainda tiver alguns restantes, pode continuar o processo de migração para esses.
Elimine os CRDs v1alpha2.

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
```
Após concluir todos os passos, a sua infraestrutura deve ser semelhante ao seguinte diagrama:

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

O que se segue?

Saiba como implementar o GKE Inference Gateway.
- Explore outras funcionalidades de rede do GKE.