Migrar Istio ServiceEntry a GCPBackend para Cloud Run

En esta página se explica cómo migrar de ServiceEntry a GCPBackend y se muestra cómo las funciones de gestión del tráfico de Istio pueden asegurar una transición fluida y segura.

Migrar a GCPBackend ofrece las siguientes ventajas:

  1. Código de aplicación simplificado: puedes eliminar la necesidad de inyectar manualmente JWT de gestión de identidades y accesos en la aplicación, lo que reduce la complejidad y los posibles errores.
  2. Seguridad mejorada: aprovecha la inyección automática de JWT de IAM para que la comunicación entre GKE y Cloud Run sea más segura.
  3. Migración fluida: utiliza la división y la creación de reflejos del tráfico para migrar el tráfico de forma segura sin interrumpir la aplicación.
  4. Mayor facilidad de gestión: aprovecha la configuración y la gestión optimizadas.

Antes de empezar

En las siguientes secciones se presupone que tienes lo siguiente:

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

Crea o modifica el VirtualService para que incluya tanto el ServiceEntry como el GCPBackend como destinos.

Puedes usar la división del tráfico para cambiar gradualmente el tráfico de ServiceEntry a GCPBackend. Deberías empezar con un pequeño porcentaje del tráfico dirigido a GCPBackend y aumentarlo gradualmente mientras monitorizas si hay algún problema.

En el siguiente ejemplo se describe cómo migrar el 10% de las solicitudes a GCPBackend.

cat <<EOF > virtual-service.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: cr-gcpbackend-migration
  namespace: NAMESPACE
spec:
  hosts:
  - cr-service-entry.com
  http:
  - route:
    - destination:
        host: cr-gcpbackend.com
      weight: 10 # 10% traffic to gcp backend.
    - destination:
        host: cr-service-entry.com
      weight: 90 # 90% traffic to service entry
EOF
kubectl apply -f virtual-service.yaml

Donde:

  • NAMESPACE es el nombre del espacio de nombres.

En este ejemplo:

  • VIRTUAL_SERVICEE es cr-gcpbackend-migration.
  • SERVICE_ENTRY_HOSTNAME es cr-service-entry.com.
  • GCP_BACKEND_HOSTNAME es =cr-gcpbackend.com.

(Opcional) Configurar VirtualService para la replicación de tráfico

Para que la transición sea aún más fluida, 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. De esta forma, se pueden probar y validar las configuraciones de GCPBackend sin que afecten al flujo de tráfico principal. Para obtener más información, consulte la API Virtual Service de Istio.

Validar la funcionalidad

Consulta los registros de tu aplicación o las métricas de Cloud Service Mesh para comprobar la tasa de errores de las solicitudes a $SERVICE_ENTRY_HOSTNAME. No debería haber ningún error.

Para hacer pruebas fuera de tu aplicación, puedes implementar un cliente curl. Si la solicitud se enruta a Cloud Run mediante la API GCPBackend, no es necesario adjuntar explícitamente un token de IAM 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"

La salida debe ser una respuesta HTTP 200 válida.