Migrar Istio ServiceEntry para GCPBackend em VMs do Compute Engine

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. Descoberta de endpoints: os endpoints de VM no serviço de back-end são atualizados automaticamente quando instâncias de VM são adicionadas ou removidas.
  2. Verificação de integridade centralizada: os endpoints de VM são verificados, e o tráfego é automaticamente roteado de back-ends não íntegros para í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/v1.24/docs/service-routing/advanced-load-balancing-overview e https://cloud.google.com/service-mesh/v1.24/docs/service-routing/advanced-load-balancing-overview para mais detalhes.
  4. 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.
  5. 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 VM do Compute Engine.

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