Anthos Service Mesh y Traffic Director ahora son Cloud Service Mesh. Para obtener más información, consulta la descripción general de Cloud Service Mesh.

Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

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

La integración de Cloud Run con Cloud Service Mesh te permite enrutar el tráfico de forma segura desde las cargas de trabajo de GKE hasta los backends sin servidores. Tus servicios de Cloud Run no necesitan unirse a la malla de servicios para recibir tráfico.

Esta integración admite Cloud Service Mesh con las APIs de Istio y no admite las APIs deGoogle Cloud . Mientras esta función esté en versión preliminar pública, el servicio de Cloud Run debe residir en el mismo proyecto de Google Cloud que tu clúster de GKE.

Antes de comenzar

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

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

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.

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=PROJECT_NUMBER-compute@developer.gserviceaccount.com \
  --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, se deben aprobar las verificaciones de Identity and Access Management (IAM) de Cloud Run. 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 use la identidad de una cuenta de servicio de Google.

Agrega una vinculación de política de IAM a una cuenta de servicio de IAM:
```
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]"
```
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 la KSA default.

Anota la cuenta de servicio:

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

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:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
  --role="roles/run.invoker"

Configura un servicio de Cloud Run como un GCPBackend

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

Información de frontend, específicamente, el nombre de host y el puerto que las cargas de trabajo de GKE usarían para llamar a este GCPBackend.
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 del 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 en un nombre de host elegido en una dirección IP arbitraria. Hasta que configures esta entrada de DNS, la solicitud fallará. La configuración de DNS de Google Cloud es un proceso único por dominio personalizado.

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.

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

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.

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

Ten en cuenta que el servicio virtual y el 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.

Usa el nombre de host de Cloud Run en lugar de Cloud DNS (opcional)

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 con DNS de forma 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.

Configura el servicio virtual de Istio o la regla de destino (opcional)

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

En el siguiente ejemplo, se inserta un retraso de 5 s al 50% de las solicitudes y se anula (estado HTTP 503) el 10% de las solicitudes que van al 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 no se otorga el rol de cliente de Traffic Director 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 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