Enruta el tráfico de las cargas de trabajo de Cloud Service Mesh a los servicios de Cloud Run

Vista previa

Este producto o función está sujeto a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones específicas del Servicio. Los productos y las funciones que se encuentran en la fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Nota: Esta guía solo admite la malla de servicios de Cloud con las APIs de Istio y no las de Google Cloud . Para obtener más información, consulta la descripción general de Cloud Service Mesh.

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

Ten en cuenta que, cuando enrutas el tráfico de GKE a Cloud Run, no es necesario que el servicio de Cloud Run se una a Cloud Service Mesh. 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 existe mientras la función está disponible en la versión preliminar pública.

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

Como alternativa, puedes ejecutar los siguientes comandos para implementar un servicio de Cloud Run de muestra.

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

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

   Aquí:

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

2. Implementa un servicio de Cloud Run de muestra:

   gcloud run deploy hello-world \
     --image=us-docker.pkg.dev/cloudrun/container/hello \
     --no-allow-unauthenticated \
     --port=8080 \
     --service-account=[e-mail] \
     --region=us-central1 \
     --project=PROJECT_ID
   

   Aquí:

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

Configura IAM

Para invocar servicios de Cloud Run, las verificaciones de Identity and Access Management (IAM) de Cloud Run deben aprobarse. Debes otorgar 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 que actúe en nombre de la cuenta de servicio de Google.

Sigue estos pasos para permitir que una cuenta de servicio de Kubernetes actúe en nombre de una cuenta de servicio de Google.

1. Agrega una vinculación de política de IAM a una cuenta de servicio de IAM:

   gcloud iam service-accounts add-iam-policy-binding [e-mail] \
     --role roles/iam.workloadIdentityUser \
     --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA]"
   

   Aquí:

   • 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 el default de Arabia Saudita.

2. Anota la cuenta de servicio:

   kubectl annotate serviceaccount KSA \
     --namespace NAMESPACE \
     iam.gke.io/gcp-service-account=[e-mail]
   

3. Otorga 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:[e-mail]" \
     --role="roles/run.invoker"
   

Configura un servicio de Cloud Run como GCPBackend

En esta sección, expones el servicio de Cloud Run a las cargas de trabajo de GKE con GCPBackend. GCPBackend consta de lo siguiente:

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

GCPBackend contiene los detalles del nombre de host y el puerto, así como los detalles del servicio de Cloud (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 dentro del clúster (de forma predeterminada, no se puede resolver), debes configurar el DNS de Google Cloud para que resuelva todos los hosts de un nombre de host elegido en una dirección IP arbitraria. La solicitud fallará hasta que configures esta entrada de DNS. La configuración de DNS de Google Cloud es una configuración única por dominio personalizado.

1. Crea una zona administrada:

   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 de VPC es default.

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

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

3. Crea 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 existentes de Kubernetes o las entradas de servicio de Istio. Si hay un conflicto, el orden de prioridad (de alto a bajo) es el servicio de Kubernetes, ServiceEntry de Istio y GCPBackend.

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

(Opcional) Usa 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 a través de DNS a nivel global. Puedes usar este nombre de host directamente en el nombre de host de GCPBackend y omitir 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) Configura el servicio virtual o la regla de destino de Istio

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

En el siguiente ejemplo, se inserta una demora de 5 s en el 50% de las solicitudes y se aborta (código de estado HTTP 503) el 10% de las solicitudes que se envían 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.

Soluciona problemas

En esta sección, se muestra cómo solucionar problemas comunes 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 a la cuenta de servicio de Cloud Run no se le otorga el rol de cliente de trafficdirector 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 trafficdirector se puede recuperar con CSDS:

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

¿Qué sigue?

• Enruta el tráfico de los servicios de Cloud Run a las cargas de trabajo de Cloud Service Mesh en GKE