Migra Istio ServiceEntry a GCPBackend para Cloud Run

En esta página, se muestra cómo migrar de ServiceEntry a GCPBackend, y se demuestra cómo las capacidades de administración de tráfico de Istio pueden garantizar una transición fluida y segura.

La migración a GCPBackend ofrece los siguientes beneficios:

  1. Código de la aplicación simplificado: Puedes eliminar la necesidad de la inserción manual de JWT de IAM en la aplicación, lo que reduce la complejidad y los posibles errores.
  2. Seguridad mejorada: Aprovecha la inserción automática de JWT de IAM para una comunicación más segura entre GKE y Cloud Run.
  3. 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.
  4. Administración mejorada: Benefíciate de la configuración y la administración optimizadas.

Antes de comenzar

En las siguientes secciones, se da por sentado que ya hiciste lo siguiente:

  1. Un clúster de GKE con Cloud Service Mesh habilitado.
  2. Es una entrada de servicio de Istio.
  3. Recurso GCPBackend configurado para el servicio de Cloud Run.

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 si hay problemas.

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 del tráfico para enviar una copia del tráfico a GCPBackend y, al mismo tiempo, dirigir principalmente el tráfico 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 Istio Virtual Service.

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

Para realizar pruebas fuera de tu aplicación, puedes implementar un cliente curl. Si la solicitud se enruta a Cloud Run con la API de GCPBackend, no necesita un token de IAM adjunto de forma explícita, 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.