Cloud Service Mesh e Traffic Director sono ora Cloud Service Mesh. Per saperne di più, consulta la panoramica di Cloud Service Mesh.

Questa pagina è stata tradotta dall'API Cloud Translation.

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

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 instradi 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 di Cloud Service Mesh. Questa limitazione esiste finché questa funzionalità è disponibile in anteprima pubblica.

Prima di iniziare

Le seguenti sezioni presuppongono che tu disponga di quanto segue:

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

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.
- CLUSTER_LOCATION è la regione o la zona del cluster.

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 di progetto del tuo progetto.
PROJECT_ID è l'ID progetto.

Configura IAM

Per richiamare i servizi Cloud Run, i controlli Cloud Run Identity and Access Management (IAM) devono essere superati. Devi concedere il ruolo Invoker di Cloud Run al service account Google. Devi anche configurare il service account Kubernetes (KSA) di GKE per rappresentare l'account di servizio Google.

Segui questi passaggi per consentire a un service account Kubernetes di rappresentare un service account Google.

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 la KSA default.

Annota il account di servizio:

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

Concedi il ruolo Invoker di Cloud Run al service account 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 carichi di lavoro GKE utilizzando GCPBackend. GCPBackend è composto da:

Informazioni sul frontend, in particolare l'hostname e la porta che i carichi di lavoro GKE utilizzerebbero per chiamare questo GCPBackend.
Informazioni di backend: i dettagli del servizio Cloud Run, come il nome del servizio, la posizione e il numero di progetto.

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

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

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.

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

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.

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 (da alto a basso) è Kubernetes Service, istio ServiceEntry 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) ed è risolvibile a livello globale tramite DNS. 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 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 e/o la regola di destinazione Istio

Puoi configurare il servizio virtuale Istio o la regola di destinazione Istio per il nome host GCPBackend per impostare criteri di consumer o client per le richieste a GCPBackend.

L'esempio seguente inserisce un ritardo da 5 secondi al 50% delle richieste e un errore (stato HTTP 503) al 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 con Cloud Service Mesh e Cloud Run.

Log di Cloud Run Sidecar

Gli errori di Envoy vengono registrati in Cloud Logging.

Ad esempio, se al 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 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

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