Migrar o Istio ServiceEntry para o GCPBackend para Cloud Run

Visualização

Este produto ou recurso está sujeito aos "Termos das ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos do serviço. Os produtos e recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Para mais informações, consulte Visão geral do Cloud Service Mesh.

Esta página mostra como migrar de ServiceEntry para GCPBackend, demonstrando como os recursos de gerenciamento de tráfego do Istio podem garantir uma transição tranquila e segura.

A migração para o GCPBackend oferece os seguintes benefícios:

1. Código do aplicativo simplificado: você pode eliminar a necessidade de injetar manualmente o JWT do IAM no aplicativo, reduzindo a complexidade e os possíveis erros.
2. Segurança aprimorada: aproveite a injeção automática de JWT do IAM para uma comunicação mais segura entre o GKE e o Cloud Run.
3. Migração perfeita: use a divisão e o espelhamento de tráfego para migrar o tráfego com segurança sem interromper o aplicativo.
4. Gerenciabilidade aprimorada: aproveite a configuração e o gerenciamento simplificados.

Antes de começar

As seções a seguir pressupõem que você:

1. Um cluster do GKE com o Cloud Service Mesh ativado.
2. Um serviço do Cloud Run como entrada de serviço do Istio.
3. Recurso GCPBackend configurado.

Crie ou modifique o VirtualService atual para incluir o ServiceEntry e o GCPBackend como destinos

Você pode usar a divisão de tráfego para transferir gradualmente o tráfego do ServiceEntry para o GCPBackend. Comece com uma pequena porcentagem de tráfego direcionado ao GCPBackend e aumente gradualmente enquanto monitora possíveis problemas.

O exemplo a seguir descreve a migração de 10% das solicitações para o GCPBackend.

cat <<EOF > virtual-service.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: cr-gcpbackend-migration
  namespace: NAMESPACE
spec:
  hosts:
  - cr-service-entry.com
  http:
  - route:
    - destination:
        host: cr-gcpbackend.com
      weight: 10 # 10% traffic to gcp backend.
    - destination:
        host: cr-service-entry.com
      weight: 90 # 90% traffic to service entry
EOF
kubectl apply -f virtual-service.yaml

Em que:

• NAMESPACE é o nome do namespace.

Neste exemplo:

• VIRTUAL_SERVICEE é cr-gcpbackend-migration.
• SERVICE_ENTRY_HOSTNAME é cr-service-entry.com.
• GCP_BACKEND_HOSTNAME é =cr-gcpbackend.com.

(Opcional) Configurar o VirtualService para espelhamento de tráfego

Para garantir uma transição tranquila, configure o espelhamento de tráfego para enviar uma cópia do tráfego para o GCPBackend, direcionando o tráfego principalmente para a ServiceEntry. Isso permite testar e validar a configuração do GCPBackend sem afetar o fluxo de tráfego principal. Para mais informações, consulte a API Istio Virtual Service.

Validar a funcionalidade

Consulte os registros do aplicativo ou as métricas do Cloud Service Mesh para verificar a taxa de erros de solicitações para $SERVICE_ENTRY_HOSTNAME. Não deve haver erros.

Para testar fora do seu aplicativo, implante um cliente curl. Se a solicitação for roteada para o CloudRun usando a API GCPBackend, ela não precisará de um token do IAM anexado explicitamente, porque o Cloud Service Mesh o anexa automaticamente.

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: testcurl
  namespace: default
spec:
  containers:
  - name: curl
    image: curlimages/curl
    command: ["sleep", "3000"]
EOF

kubectl exec testcurl -c curl -- curl "$SERVICE_ENTRY_HOSTNAME"

A saída precisa ser uma resposta HTTP 200 válida.