Migre o Istio ServiceEntry para o GCPBackend para VMs do Compute Engine

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 simples e segura.

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

  1. Deteção de pontos finais: os pontos finais de VMs 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 funcionamento centralizada: os pontos finais de VMs são verificados quanto ao funcionamento e o tráfego é encaminhado automaticamente dos back-ends não saudáveis para os saudáveis.
  3. Balanceamento de carga global e algoritmos de balanceamento de carga avançados: os pontos finais de VMs podem ser implementados em várias regiões. Use os nossos algoritmos de balanceamento de carga para configurar o comportamento do balanceamento de carga nestas 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 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.
  5. Facilidade de gestão melhorada: 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 VM do Compute Engine.

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 do 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 a replicação 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 existir nenhum erro.

Para testar fora da sua aplicação, pode implementar um cliente curl. Se o pedido for encaminhado para utilização 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.