Migrar a ServiceEntry do Istio para o GCPBackend para VMs do Compute Engine

Esta página mostra como migrar do ServiceEntry para o 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. Detecção de endpoint: os endpoints de VM no serviço de back-end são atualizados automaticamente quando as instâncias de VM são adicionadas ou removidas.
  2. Verificação de integridade centralizada: os endpoints da VM são verificados e o tráfego é roteado automaticamente de back-ends não íntegros para back-ends íntegros.
  3. Balanceamento de carga global e algoritmos avançados de balanceamento de carga: os endpoints de VM podem ser implantados em várias regiões. Use nossos algoritmos de balanceamento de carga para configurar o comportamento do balanceamento de carga nessas regiões. Consulte https://cloud.google.com/service-mesh/docs/service-routing/advanced-load-balancing-overview e https://cloud.google.com/service-mesh/docs/service-routing/advanced-load-balancing-overview para mais detalhes.
  4. 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.
  5. 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. Uma entrada de serviço do Istio.
  3. Recurso GCPBackend configurado para VM do Compute Engine.

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: 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 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 usar 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 deve ser uma resposta HTTP 200 válida.