Dirigir el tráfico de cargas de trabajo de Cloud Service Mesh a servicios de Cloud Run

En esta página se muestra cómo enrutar de forma segura el tráfico de red desde cargas de trabajo de Cloud Service Mesh en GKE a servicios de Cloud Run.

Ten en cuenta que, al enrutar el tráfico de GKE a Cloud Run, no es necesario que el servicio de Cloud Run se una a la malla de servicios de Cloud. Sin embargo, el servicio de Cloud Run debe estar en el mismo proyecto que el clúster de GKE de Cloud Service Mesh. Esta limitación se aplica mientras esta función está disponible en la versión preliminar pública.

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. Haber desplegado un servicio de Cloud Run.

También puedes ejecutar los siguientes comandos para desplegar un servicio de Cloud Run de ejemplo.

  1. Genera un contexto de kubeconfig para tu clúster:

    gcloud container clusters get-credentials CLUSTER_NAME --project=PROJECT_ID  --location=CLUSTER_LOCATION

    Donde:

    • CLUSTER_NAME es el nombre de tu clúster.
    • PROJECT_ID es el ID de tu proyecto.
    • CLUSTER_LOCATION es la región o zona de tu clúster.

  2. Despliega un servicio de Cloud Run de ejemplo:

    gcloud run deploy hello-world \
  --image=us-docker.pkg.dev/cloudrun/container/hello \
  --no-allow-unauthenticated \
  --port=8080 \
  --service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.com \
  --region=us-central1 \
  --project=PROJECT_ID

    Donde:

    • PROJECT_NUMBER es el número de proyecto.
    • PROJECT_ID es el ID de tu proyecto.

Configurar IAM

Para invocar servicios de Cloud Run, deben superarse las comprobaciones de Gestión de Identidades y Accesos (IAM) de Cloud Run. Debes conceder el rol de invocador de Cloud Run a la cuenta de servicio de Google. También debes configurar la cuenta de servicio de Kubernetes (KSA) de GKE para suplantar la cuenta de servicio de Google.

Sigue estos pasos para permitir que una cuenta de servicio de Kubernetes suplante a una cuenta de servicio de Google.

  1. Añade una vinculación de política de gestión de identidades y accesos a una cuenta de servicio de gestión de identidades y accesos:

    gcloud iam service-accounts add-iam-policy-binding PROJECT_NUMBER-compute@developer.gserviceaccount.com \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA]"

    Donde:

    • NAMESPACE es el nombre del espacio de nombres. Para los fines de esta guía, puedes usar el espacio de nombres default.
    • KSA es el nombre de la cuenta de servicio de Kubernetes. Para los fines de esta guía, puedes usar la KSA default.

  2. Anota la cuenta de servicio:

    kubectl annotate serviceaccount KSA \
  --namespace NAMESPACE \
  iam.gke.io/gcp-service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.com

  3. Asigna el rol de invocador de Cloud Run a la cuenta de servicio de Google:

    gcloud run services add-iam-policy-binding hello-world \
  --region=us-central1 \
  --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
  --role="roles/run.invoker"

Configurar un servicio de Cloud Run como GCPBackend

En esta sección, expondrás el servicio de Cloud Run a las cargas de trabajo de GKE mediante GCPBackend. GCPBackend consta de lo siguiente:

  1. Información del frontend, concretamente el nombre de host y el puerto que usarían las cargas de trabajo de GKE para llamar a este GCPBackend.
  2. Información de backend: detalles del servicio de Cloud Run, como el nombre del servicio, la ubicación y el número de proyecto.

GCPBackend contiene el nombre de host y los detalles del puerto, así como los detalles de Cloud Service (nombre del servicio, ubicación y número de proyecto). Las cargas de trabajo de GKE deben usar el nombre de host y el puerto de GCPBackend en sus solicitudes HTTP para acceder al servicio de Cloud Run.

Para que el DNS del nombre de host se pueda resolver en el clúster (de forma predeterminada, no se puede), debes configurar el DNS para que resuelva todos los hosts con un nombre de host elegido en una dirección IP arbitraria. Google Cloud Hasta que no configures esta entrada DNS, la solicitud fallará. La configuración de DNS es un proceso que se realiza una sola vez por cada dominio personalizado. Google Cloud

  1. Crea una zona gestionada:

    gcloud dns managed-zones create prod \
    --description="zone for gcpbackend" \
    --dns-name=gcpbackend \
    --visibility=private \
    --networks=default

    En este ejemplo, el nombre de DNS es gcpbackend y la red VPC es default.

  2. Configura el registro para que el dominio se pueda resolver:

    gcloud beta dns record-sets create *.gcpbackend \
  --ttl=3600 --type=A --zone=prod \
  --rrdatas=10.0.0.1

  3. Crea el GCPBackend con un nombre de host en el dominio anterior:

    cat <<EOF > gcp-backend.yaml
apiVersion: networking.gke.io/v1
kind: GCPBackend
metadata:
  name: cr-gcp-backend
  namespace: NAMESPACE
spec:
  hostname: hello-world.gcpbackend
  type: CloudRun
  cloudrun:
    service: hello-world
    regions: [us-central1]
EOF
kubectl apply -f gcp-backend.yaml

    En este ejemplo, GCP_BACKEND_NAME es cr-gcp-backend.

  4. Crea un pod de prueba para verificar la conectividad de GKE a Cloud Run:

    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 http://hello-world.gcpbackend/hello

    Ahora, tus cargas de trabajo de GKE pueden acceder al servicio de Cloud Run enviando solicitudes HTTP a hello-world.gcpbackend/hello.

Debes usar nombres distintos para GCPBackend para evitar conflictos con los servicios de Kubernetes o las entradas de servicio de Istio. Si hay un conflicto, el orden de precedencia (de mayor a menor) es Kubernetes Service, Istio ServiceEntry y GCPBackend.

Ten en cuenta que el servicio virtual y el GCPBackend deben estar en el mismo espacio de nombres, y que el servicio de Cloud Run debe estar en el mismo proyecto que el clúster de GKE de Cloud Service Mesh.

(Opcional) Usar el nombre de host de Cloud Run en lugar de Cloud DNS

A cada servicio de Cloud Run se le asigna un nombre de host (por ejemplo, hello-world.us-central1.run.app) y se puede resolver mediante DNS en todo el mundo. Puedes usar este nombre de host directamente en el nombre de host de GCPBackend y saltarte la configuración de Cloud DNS.

cat <<EOF | kubectl apply -f -
apiVersion: networking.gke.io/v1
kind: GCPBackend
metadata:
  name: cr-gcp-backend
  namespace: NAMESPACE
spec:
  hostname: hello-world.us-central1.run.app
  type: CloudRun
  cloudrun:
    service: hello-world
    region: [us-central1]
EOF

Ahora, tus cargas de trabajo de GKE pueden acceder al servicio de Cloud Run enviando solicitudes HTTP a hello-world.us-central1.run.app.

(Opcional) Configurar un servicio virtual o una regla de destino de Istio

Puedes configurar el servicio virtual de Istio o la regla de destino de Istio para el nombre de host de GCPBackend con el fin de definir políticas de consumidor o de cliente para las solicitudes a GCPBackend.

En el siguiente ejemplo, se inserta un retraso de 5 segundos en el 50% de las solicitudes y se cancela (estado HTTP 503) el 10% de las solicitudes que se dirigen a GCPBackend.

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: cr-virtual-service
  namespace: NAMESPACE
spec:
  hosts:
  - hello-world.us-central1.run.app
  gateways:
  - mesh
  http:
  - fault:
      delay:
        percentage:
          value: 50  # Delay 50% of requests
        fixedDelay: 5s
      abort:
        percentage:
          value: 10  # Abort 10% of requests
        httpStatus: 503
  - route:
    - destination:
        host: hello-world.us-central1.run.app
EOF

En este ejemplo, VIRTUAL_SERVICE_NAME es cr-virtual-service.

Solución de problemas

En esta sección se muestra cómo solucionar errores habituales con Cloud Service Mesh y Cloud Run.

Registros de Sidecar de Cloud Run

Los errores de Envoy se registran en Cloud Logging.

Por ejemplo, se registrará un error como el siguiente si no se asigna el rol de cliente trafficdirector a la cuenta de servicio de Cloud Run en el proyecto de malla:

StreamAggregatedResources gRPC config stream to trafficdirector.googleapis.com:443 closed: 7, Permission 'trafficdirector.networks.getConfigs' denied on resource '//trafficdirector.googleapis.com/projects/525300120045/networks/mesh:test-mesh/nodes/003fb3e0c8927482de85f052444d5e1cd4b3956e82b00f255fbea1e114e1c0208dbd6a19cc41694d2a271d1ab04b63ce7439492672de4499a92bb979853935b03d0ad0' (or it may not exist).

CSDS

El estado del cliente de Traffic Director se puede obtener mediante CSDS:

gcloud alpha container fleet mesh debug proxy-status --membership=<CLUSTER_MEMBERSHIP> --location=<CLUSTER_LOCATION>
External Clients:
....

Siguientes pasos