Migre Istio ServiceEntry para GCPBackend para o Cloud Run

Esta página mostra como migrar de ServiceEntry para GCPBackend, demonstrando como as capacidades de gestão de tráfego do Istio podem garantir uma transição suave e segura.

A migração para o GCPBackend oferece as seguintes vantagens:

  1. Código da aplicação simplificado: pode eliminar a necessidade de injeção manual de JWTs de IAM na aplicação, o que reduz a complexidade e os potenciais erros.
  2. Segurança melhorada: tire partido da injeção automática de JWTs do IAM para uma comunicação mais segura entre o GKE e o Cloud Run.
  3. Migração integrada: use a divisão e a replicação de tráfego para migrar o tráfego em segurança sem interromper a aplicação.
  4. Maior capacidade de gestão: tire partido da configuração e da gestão simplificadas.

Antes de começar

As secções seguintes pressupõem que:

  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 existente para incluir o ServiceEntry e o GCPBackend como destinos

Pode usar a divisão de tráfego para mudar gradualmente o tráfego de ServiceEntry para o GCPBackend. Deve começar com uma pequena percentagem de tráfego direcionado para o GCPBackend e aumentá-la gradualmente enquanto monitoriza eventuais problemas.

O exemplo seguinte descreve a migração de 10% dos pedidos 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

Onde:

  • NAMESPACE é o nome do espaço de nomes.

Neste exemplo:

  • VIRTUAL_SERVICE é gcpbackend-migration.
  • SERVICE_ENTRY_HOSTNAME é service-entry.com.
  • GCP_BACKEND_HOSTNAME é gcpbackend.com.

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

Para garantir ainda mais uma transição sem problemas, pode configurar o espelhamento de tráfego para enviar uma cópia do tráfego para o GCPBackend enquanto continua a direcionar principalmente o tráfego para o ServiceEntry. Isto 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.

Valide a funcionalidade

Consulte os registos da sua aplicação ou as métricas da Cloud Service Mesh para verificar a taxa de erros de pedidos para $SERVICE_ENTRY_HOSTNAME. Não deve haver erros.

Para testar fora da sua aplicação, pode implementar um cliente curl. Se o pedido for encaminhado para o CloudRun através da API GCPBackend, não precisa de um token IAM explicitamente anexado ao pedido, porque o Cloud Service Mesh anexa-o 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 deve ser uma resposta HTTP 200 válida.