Migre Istio ServiceEntry para 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 suave e segura.

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

  1. Deteção de pontos finais: os pontos finais 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 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. 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 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 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 utilização da API GCPBackend, não precisa de um token IAM anexado explicitamente 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.