Migra ServiceEntry de Istio a GCPBackend para VMs de Compute Engine
En esta página, se muestra cómo migrar de ServiceEntry a GCPBackend, lo que demuestra cómo las capacidades de administración de tráfico de Istio pueden garantizar una transición segura y sin problemas.
La migración a GCPBackend proporciona los siguientes beneficios:
- Detección de extremos: Los extremos de VM en el servicio de backend se actualizan automáticamente cuando se agregan o quitan instancias de VM.
- Verificación de estado centralizada: Se verifica el estado de los extremos de VM y el tráfico se enruta automáticamente de los backends en mal estado a los backends en buen estado.
- Balanceo de cargas global y algoritmos avanzados de balanceo de cargas: Los extremos de VM se pueden implementar en varias regiones. Usa nuestros algoritmos de balanceo de cargas para configurar el comportamiento del balanceo de cargas en estas regiones. Consulta https://cloud.google.com/service-mesh/v1.25/docs/service-routing/advanced-load-balancing-overview y https://cloud.google.com/service-mesh/v1.25/docs/service-routing/advanced-load-balancing-overview para obtener más detalles.
- Migración sin problemas: Utiliza la división y la duplicación del tráfico para migrar el tráfico de forma segura sin interrumpir la aplicación.
- Administración mejorada: Benefíciate de la configuración y la administración optimizadas.
Antes de comenzar
En las siguientes secciones, se supone que tienes lo siguiente:
- Un clúster de GKE con Cloud Service Mesh habilitado.
- Una entrada de servicio de Istio
- Recurso GCPBackend configurado para la VM de Compute Engine
Crea o modifica el VirtualService existente para incluir ServiceEntry y GCPBackend como destinos
Puedes usar la división del tráfico para cambiar gradualmente el tráfico de ServiceEntry a GCPBackend. Debes comenzar con un pequeño porcentaje de tráfico dirigido a GCPBackend y aumentarlo gradualmente mientras supervisas cualquier problema.
En el siguiente ejemplo, se describe la migración del 10% de las solicitudes a 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
Aquí:
- NAMESPACE es el nombre del espacio de nombres.
En este ejemplo:
- VIRTUAL_SERVICE es
gcpbackend-migration. - SERVICE_ENTRY_HOSTNAME es
service-entry.com. - GCP_BACKEND_HOSTNAME es
gcpbackend.com.
(Opcional) Configura VirtualService para la duplicación de tráfico
Para garantizar aún más una transición sin problemas, puedes configurar la duplicación de tráfico para enviar una copia del tráfico a GCPBackend mientras sigues dirigiendo el tráfico principalmente a ServiceEntry. Esto permite probar y validar la configuración de GCPBackend sin afectar el flujo de tráfico principal. Para obtener más información, consulta la API de Virtual Service de Istio.
Valida la funcionalidad
Consulta los registros de tu aplicación o las métricas de Cloud Service Mesh para verificar la tasa de errores de las solicitudes a $SERVICE_ENTRY_HOSTNAME. No debería haber ningún error.
Para realizar pruebas fuera de tu aplicación, puedes implementar un cliente de curl. Si la solicitud se enruta a través de la API de GCPBackend, no necesita un token de IAM adjunto de forma explícita a la solicitud, ya que Cloud Service Mesh lo adjunta automáticamente.
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"
El resultado debe ser una respuesta HTTP 200 válida.