Instradare il traffico dai carichi di lavoro Cloud Service Mesh ai servizi Cloud Run

Anteprima

Questo prodotto o funzionalità è soggetto ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici del servizio. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Nota: questa guida supporta solo Cloud Service Mesh con le API Istio e non supporta le API Google Cloud . Per ulteriori informazioni, consulta la panoramica di Cloud Service Mesh.

Questa pagina mostra come instradare in modo sicuro il traffico di rete dai workload Cloud Service Mesh su GKE ai servizi Cloud Run.

Tieni presente che, quando indirizzi il traffico da GKE a Cloud Run, non è necessario che il servizio Cloud Run si unisca a Cloud Service Mesh. Tuttavia, il servizio Cloud Run deve trovarsi nello stesso progetto del cluster GKE Cloud Service Mesh. Questa limitazione è valida finché la funzionalità è disponibile in anteprima pubblica.

Prima di iniziare

Le seguenti sezioni presuppongono che tu disponga di quanto segue:

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

In alternativa, puoi eseguire i seguenti 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 cluster.
   • PROJECT_ID è l'ID progetto.
   • CLUSTER_LOCATION è la regione o la zona del 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=[e-mail] \
     --region=us-central1 \
     --project=PROJECT_ID
   

   Dove:

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

Configura IAM

Per invocare i servizi Cloud Run, i controlli di Identity and Access Management (IAM) di Cloud Run devono essere superati. Devi concedere il ruolo Invoker di Cloud Run all'account di servizio Google. Devi anche configurare l'account di servizio Kubernetes (KSA) GKE per rubare l'identità dell'account di servizio Google.

Esegui i seguenti passaggi per consentire a un account di servizio Kubernetes di rubare l'identità di un account di servizio Google.

1. Aggiungi un'associazione del criterio IAM a un account di servizio IAM:

   gcloud iam service-accounts add-iam-policy-binding [e-mail] \
     --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 dell'account di servizio Kubernetes. Ai fini di questa guida, puoi utilizzare il default dell'Arabia Saudita.

2. Aggiungi un'annotazione all'account di servizio:

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

3. Concedi il ruolo Invoker di Cloud Run all'account di servizio Google:

   gcloud run services add-iam-policy-binding hello-world \
     --region=us-central1 \
     --member="serviceAccount:[e-mail]" \
     --role="roles/run.invoker"
   

Configurare un servizio Cloud Run come GCPBackend

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

1. Informazioni sul frontend, in particolare l'hostname e la porta che GKE Workloads utilizzerà per chiamare questo GCPBackend.
2. Informazioni sul backend: i dettagli del servizio Cloud Run, come nome, posizione e numero del progetto.

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

Per rendere il nome host DNS risolvibile all'interno del cluster (per impostazione predefinita non è risolvibile), devi configurare il DNS di Google Cloud in modo che risolva tutti gli host di 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 di Google Cloud è una configurazione una tantum per ogni 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 il dominio risolvibile:

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

3. Crea 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 carichi di lavoro 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 (dall'alto verso il basso) è Servizio Kubernetes, ServiceEntry di 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 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) ed è risolvibile tramite DNS 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 carichi di lavoro 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 per impostare i criteri di consumer o client per le richieste al servizio GCPBackend.

L'esempio seguente inserisce un ritardo di 5 secondi nel 50% delle richieste e interrompe (stato HTTP 503) il 10% delle richieste inviate 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 gli errori comuni di Cloud Service Mesh e Cloud Run.

Log del sidecar Cloud Run

Gli errori di Envoy vengono registrati in Cloud Logging.

Ad esempio, se all'account di servizio Cloud Run non viene assegnato il ruolo client trafficdirector nel progetto mesh, verrà registrato un errore come il 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 trafficdirector può essere recuperato utilizzando CSDS:

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

Passaggi successivi

• Instradare il traffico dai servizi Cloud Run ai carichi di lavoro Cloud Service Mesh su GKE