Instrada il traffico dai workload Cloud Service Mesh ai servizi Cloud Run

L'integrazione di Cloud Run con Cloud Service Mesh ti consente di instradare in modo sicuro il traffico dai workload GKE ai backend serverless. I tuoi servizi Cloud Run non devono essere aggiunti al mesh di servizi per ricevere traffico.

Questa integrazione supporta Cloud Service Mesh con le API Istio e non supporta le APIGoogle Cloud . Mentre questa funzionalità è in anteprima pubblica, il servizio Cloud Run deve risiedere nello stesso progetto Google Cloud del cluster GKE.

Prima di iniziare

Le seguenti sezioni presuppongono che tu disponga di quanto segue:

  1. Un cluster GKE con Cloud Service Mesh abilitato.
  2. Hai eseguito il deployment di un servizio Cloud Run.

In alternativa, puoi eseguire questi comandi per eseguire il deployment di un servizio Cloud Run di esempio.

  1. Genera un contesto kubeconfig per il tuo cluster:

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

    Dove:

    • CLUSTER_NAME è il nome del tuo cluster.
    • PROJECT_ID è l'ID progetto del tuo progetto.
    • CLUSTER_LOCATION è la regione o la zona del tuo cluster.

  2. Esegui il deployment di un servizio Cloud Run di esempio:

    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

    Dove:

    • PROJECT_NUMBER è il numero del tuo progetto.
    • PROJECT_ID è l'ID progetto del tuo progetto.

Configura IAM

Per richiamare i servizi Cloud Run, i controlli di Cloud Run Identity and Access Management (IAM) devono avere esito positivo. Devi concedere il ruolo Cloud Run Invoker al service account Google. Devi anche configurare il service account Kubernetes (KSA) di GKE per assumere l'identità del service account Google.

Per consentire a un service account Kubernetes di assumere l'identità di un service account Google, segui questi passaggi.

  1. Aggiungi un'associazione di policy IAM a un service account 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]"

    Dove:

    • NAMESPACE è il nome dello spazio dei nomi. Ai fini di questa guida, puoi utilizzare lo spazio dei nomi default.
    • KSA è il nome del service account Kubernetes. Ai fini di questa guida, puoi utilizzare l'agente di servizio Kubernetes default.

  2. Annota il account di servizio:

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

  3. Concedi il ruolo Cloud Run Invoker all'account di servizio 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 servizio Cloud Run come GCPBackend

In questa sezione, esponi il servizio Cloud Run ai workload GKE utilizzando GCPBackend. GCPBackend è composto da:

  1. Informazioni sul frontend, in particolare il nome host e la porta che i workload GKE utilizzerebbero per chiamare questo GCPBackend.
  2. Informazioni sul backend: i dettagli del servizio Cloud Run, come il nome del servizio, la località e il numero del progetto.

GCPBackend contiene i dettagli del nome host e della porta, nonché i dettagli del servizio Cloud (nome del servizio, località e numero di progetto). I workload GKE devono utilizzare il nome host e la porta di GCPBackend nelle richieste HTTP per accedere al servizio Cloud Run.

Per rendere risolvibile il DNS del nome host all'interno del cluster (per impostazione predefinita non è risolvibile), devi configurare il DNS Google Cloud per risolvere tutti gli host con un nome host scelto in un indirizzo IP arbitrario. Finché non configuri questa voce DNS, la richiesta non va a buon fine. La configurazione DNS Google Cloud è una configurazione una tantum per dominio personalizzato.

  1. Crea una zona gestita:

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

    In questo esempio, il nome DNS è gcpbackend e la rete VPC è default.

  2. Configura il record per rendere risolvibile il dominio:

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

  3. Crea il GCPBackend con un nome host nel dominio precedente:

    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

    In questo esempio, GCP_BACKEND_NAME è cr-gcp-backend.

  4. Crea un pod di test per verificare la connettività da 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

    Ora i tuoi workload GKE possono accedere al servizio Cloud Run inviando richieste HTTP a hello-world.gcpbackend/hello.

Devi utilizzare nomi distinti per GCPBackend per evitare conflitti con i servizi Kubernetes o le voci di servizio Istio esistenti. In caso di conflitto, l'ordine di precedenza (dal più alto al più basso) è Servizio Kubernetes, ServiceEntry Istio e GCPBackend.

Tieni presente che il servizio virtuale e GCPBackend devono trovarsi nello stesso spazio dei nomi e il servizio Cloud Run deve trovarsi nello stesso progetto del cluster GKE di Cloud Service Mesh.

(Facoltativo) Utilizza il nome host di Cloud Run anziché Cloud DNS

A ogni servizio Cloud Run viene assegnato un nome host (ad esempio hello-world.us-central1.run.app) e il DNS è risolvibile a livello globale. Puoi utilizzare questo nome host direttamente nel nome host GCPBackend e saltare la configurazione di 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

Ora i tuoi workload GKE possono accedere al servizio Cloud Run inviando richieste HTTP a hello-world.us-central1.run.app.

(Facoltativo) Configura il servizio virtuale Istio e/o la regola di destinazione

Puoi configurare il servizio virtuale Istio o la regola di destinazione Istio per il nome host GCPBackend in modo da impostare le policy per i consumer o i client per le richieste al GCPBackend.

L'esempio seguente inserisce un ritardo di 5 secondi nel 50% delle richieste e interrompe (stato HTTP 503) il 10% delle richieste indirizzate 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

In questo esempio, VIRTUAL_SERVICE_NAME è cr-virtual-service.

Risoluzione dei problemi

Questa sezione mostra come risolvere i problemi comuni di Cloud Service Mesh e Cloud Run.

Log sidecar di Cloud Run

Gli errori di Envoy vengono registrati in Cloud Logging.

Ad esempio, se al account di servizio Cloud Run non viene assegnato il ruolo client Traffic Director nel progetto mesh, verrà registrato un errore simile al seguente:

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

Lo stato del client Traffic Director può essere recuperato utilizzando CSDS:

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

Passaggi successivi