Migrar Istio ServiceEntry a GCPBackend para máquinas virtuales de Compute Engine

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. Detección de endpoints: los endpoints de las VMs del servicio de backend se actualizan automáticamente cuando se añaden o se eliminan instancias de VM.
  2. Comprobación del estado centralizada: se comprueba el estado de los endpoints de las VMs y el tráfico se dirige automáticamente de los backends en mal estado a los que están en buen estado.
  3. Balanceo de carga global y algoritmos de balanceo de carga avanzados: los endpoints de VM se pueden desplegar en varias regiones. Usa nuestros algoritmos de balanceo de carga para configurar el comportamiento del balanceo de carga en estas regiones. Consulta https://cloud.google.com/service-mesh/v1.24/docs/service-routing/advanced-load-balancing-overview y https://cloud.google.com/service-mesh/v1.24/docs/service-routing/advanced-load-balancing-overview para obtener más información.
  4. 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.
  5. 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. Una entrada de servicio de Istio.
  3. Se ha configurado el recurso GCPBackend para máquina virtual de Compute Engine.

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: 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

Donde:

  • 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) 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 mediante la API GCPBackend, no necesita que se adjunte explícitamente un token de IAM, 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.