Migrar Istio ServiceEntry para GCPBackend no Cloud Run

Nesta página, mostramos 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 de aplicativo simplificado: você pode eliminar a necessidade de injeção manual de JWT do IAM no aplicativo, reduzindo a complexidade e 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 separação e o espelhamento de tráfego para migrar o tráfego com segurança sem interromper o aplicativo.
  4. Gerenciamento aprimorado: aproveite a configuração e o gerenciamento simplificados.

Antes de começar

As seções a seguir consideram que você tem:

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

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

É possível usar a divisão de tráfego para transferir gradualmente o tráfego da ServiceEntry para o GCPBackend. Comece com uma pequena porcentagem de tráfego direcionado ao GCPBackend e aumente gradualmente enquanto monitora 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: gcpbackend-migration
  namespace: NAMESPACE
spec:
  hosts:
  - service-entry.com
  http:
  - route:
    - destination:
        host: gcpbackend.com
      weight: 10 # 10% traffic to gcp backend.
    - destination:
        host: 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_SERVICE é gcpbackend-migration.
  • SERVICE_ENTRY_HOSTNAME é service-entry.com.
  • GCP_BACKEND_HOSTNAME é gcpbackend.com.

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

Para garantir ainda mais uma transição tranquila, é possível configurar o espelhamento de tráfego para enviar uma cópia do tráfego para o GCPBackend enquanto ainda direciona principalmente o tráfego para o 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 de aplicativos ou as métricas do Cloud Service Mesh para verificar a taxa de erros das solicitações para $SERVICE_ENTRY_HOSTNAME. Não deve haver erros.

Para testar fora do aplicativo, implante um cliente curl. Se a solicitação for roteada para o Cloud Run usando a API GCPBackend, ela não precisará de um token do IAM explicitamente anexado, porque a 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.