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:
- 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.
- 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.
- 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.
- 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.
- Gerenciamento aprimorado: aproveite a configuração e o gerenciamento simplificados.
Antes de começar
As seções a seguir consideram que você tem:
- Um cluster do GKE com o Cloud Service Mesh ativado.
- Uma entrada de serviço do Istio.
- 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.