Configura il gruppo di endpoint di rete tra progetti

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

Anteprima

Questo prodotto o funzionalità è soggetto ai "Termini delle Offerte pre-GA" nella sezione Termini di servizio generali dei Termini specifici dei servizi. 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.

La funzionalità di gruppo di endpoint di rete (NEG) tra progetti consente ai clienti di collegare i NEG di un altro progetto a un BackendService Traffic Director/Cloud Service Mesh, consentendo i seguenti casi d'uso:

• In un deployment multiprogetto, BackendServices insieme ai criteri di routing e traffico associati in un progetto centralizzato, con endpoint di backend di progetti diversi.

• In un deployment multi-progetto, puoi gestire tutte le tue risorse di calcolo (VM Compute Engine, NEG GKE e così via) in un unico progettoGoogle Cloud centrale, mentre i team di servizio possiedono i propri progetti di servizio Google Cloud , in cui definiscono le norme di servizio espresse in BackendServicese le route di routing dei servizi nel rispettivo progetto di servizio. In questo modo delegano la gestione dei propri servizi mantenendo un controllo stretto sulle risorse di calcolo che possono essere condivise tra diversi team di servizio.

Questa pagina mostra come creare una configurazione di base con due progetti in cui il NEG nel progetto A (denominato progetto del workload) è collegato a BackendService nel progetto B (denominato progetto delle policy). Il seguente esempio configura le VM del workload nella rete VPC predefinita nel progetto del workload e dimostra che il client può eseguire il routing nel progetto del workload in base alle configurazioni nel progetto dei criteri.

In una configurazione più sofisticata, è necessaria una soluzione come il VPC condiviso per un piano dati interconnesso in più progetti. Ciò implica anche che gli endpoint NEG hanno IP univoci. Questa configurazione di esempio può essere estesa a scenari più complessi in cui i carichi di lavoro si trovano in una rete VPC condiviso che si estende su più progetti.

Limitazioni

Si applicano le limitazioni generali di Traffic Director e le limitazioni di BackendService/NetworkEndpointGroup.

Si applicano anche le seguenti limitazioni, che potrebbero non essere specifiche di una configurazione multi-progetto:

• Un singolo BackendService può supportare fino a 50 backend(inclusi NEG e MIG).
• Sono supportati solo i NEG di zona di tipo GCP_VM_IP_PORT.
• Il riferimento tra progetti BackendServices ai gruppi di istanze (gestiti o non gestiti) non è supportato.
• L'elenco dei NEG tra progetti che possono essere collegati a un determinato BackendService non è supportato.
• L'elenco dei BackendService tra progetti che utilizzano un NEG specifico non è supportato.

Prima di iniziare

Prima di poter configurare i NEG tra progetti, devi completare i seguenti prerequisiti.

Abilita le API richieste

Per completare questa guida sono necessarie le seguenti API:

• osconfig.googleapis.com
• trafficdirector.googleapis.com
• compute.googleapis.com
• networkservices.googleapis.com

Esegui questo comando per abilitare le API richieste sia nel progetto del workload sia nel progetto delle norme:

gcloud services enable --project PROJECT_ID \
    osconfig.googleapis.com \
    trafficdirector.googleapis.com \
    compute.googleapis.com \
    networkservices.googleapis.com

Concedi le autorizzazioni IAM richieste

Per completare questa guida, devi disporre di autorizzazioni IAM (Identity and Access Management) sufficienti. Se disponi del ruolo di proprietario o editor (roles/owner o roles/editor) nel progetto in cui stai abilitando Cloud Service Mesh, hai automaticamente le autorizzazioni corrette.

In caso contrario, devi concedere tutti i seguenti ruoli IAM. Se disponi di questi ruoli, hai anche le autorizzazioni associate, come descritto nella documentazione IAM di Compute Engine.

I seguenti ruoli sono necessari sia nel progetto del workload sia in quello dei criteri:

• roles/iam.serviceAccountAdmin
• roles/serviceusage.serviceUsageAdmin
• roles/compute.networkAdmin

I seguenti ruoli sono obbligatori solo nel progetto workload:

• roles/compute.securityAdmin
• roles/container.admin
• Qualsiasi ruolo che includa le seguenti autorizzazioni. Il ruolo predefinito più granulare che include tutte le autorizzazioni richieste per collegare un NEG a un BackendService è roles/compute.loadBalancerServiceUser
  • compute.networkEndpointGroups.get
  • compute.networkEndpointGroups.use

Inoltre, i client xDS gestiti da Traffic Director (come il proxy Envoy) devono disporre delle autorizzazioni in roles/trafficdirector.client. A scopo dimostrativo, puoi utilizzare il seguente comando per concedere questa autorizzazione nel progetto policy aaccount di serviziont di Compute predefinito del progetto workload:

gcloud projects add-iam-policy-binding POLICY_PROJECT_ID \
    --member "serviceAccount:[e-mail]" \
    --role "roles/trafficdirector.client"

dove

• POLICY_PROJECT_ID è l'ID del progetto di criteri.
• WORKLOAD_PROJECT_NUMBER è il numero di progetto del progetto del carico di lavoro.

Configura un backend del servizio nel progetto del workload

1. Esegui questo comando per indirizzare Google Cloud CLI al progetto policy e impostare la zona di calcolo Google Cloud preferita:

   gcloud config set project WORKLOAD_PROJECT_ID
   gcloud config set compute/zone ZONE
   

   dove

   • WORKLOAD_PROJECT_ID è l'ID del progetto del carico di lavoro.
   • ZONE è la zona del cluster GKE, ad esempio us-central1.

2. Creare un cluster GKE. A scopo dimostrativo, il seguente comando crea un cluster GKE zonale. Tuttavia, questa funzionalità funziona anche sui cluster GKE regionali.

   gcloud container clusters create test-cluster \
       --scopes=https://www.googleapis.com/auth/cloud-platform
       --zone=ZONE
   

3. Crea una regola firewall:

   gcloud compute firewall-rules create http-allow-health-checks \
       --network=default \
       --action=ALLOW \
       --direction=INGRESS \
       --source-ranges=35.191.0.0/16,130.211.0.0/22 \
       --rules=tcp:80
   

   Una regola firewall consente al control plane Google Cloud di inviare probe del controllo di integrità ai backend nella rete VPC predefinita.

4. Modifica il contesto attuale per kubectl nel cluster appena creato:

   gcloud container clusters get-credentials test-cluster \
       --zone=ZONE
   

5. Crea ed esegui il deployment dell'app di esempio whereami:

   kubectl apply -f - <<EOF
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: whereami
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: whereami
     template:
       metadata:
         labels:
           app: whereami
       spec:
         containers:
         - name: whereami
           image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1
           ports:
           - containerPort: 8080
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: whereami
     annotations:
       cloud.google.com/neg: '{"exposed_ports":{"8080":{"name": "example-neg"}}}'
   spec:
     selector:
       app: whereami
     ports:
     - port: 8080
       targetPort: 8080
   EOF
   

6. Esegui questo comando per archiviare il riferimento al NEG in una variabile:

   NEG_LINK=$(gcloud compute network-endpoint-groups describe example-neg --format="value(selfLink)")
   

   Il controller NEG crea automaticamente un NetworkEndpointGroup a livello di zona per i backend del servizio in ogni zona. In questo esempio, il nome del NEG è codificato in modo permanente in example-neg. Memorizzarlo come variabile sarà utile nella sessione successiva quando collegherai questo NEG a un BackendService nel progetto dei criteri.

   Se ad esempio utilizzi $NEG_LINK, il risultato dovrebbe essere simile al seguente:

   $ echo ${NEG_LINK}
   https://www.googleapis.com/compute/v1/projects/WORKLOAD_PROJECT/zones/ZONE/networkEndpointGroups/example-neg
   

   In alternativa, puoi recuperare l'URL NEG leggendo l'annotazione neg-status sul servizio:

   kubectl get service whereami -o jsonpath="{.metadata.annotations['cloud\.google\.com/neg-status']}"
   NEG_LINK="https://www.googleapis.com/compute/v1/projects/WORKLOAD_PROJECT_ID/zones/ZONE/networkEndpointGroups/example-neg"
   

Configura le risorse di networking Google Cloud nel progetto policy

1. Punta Google Cloud CLI al progetto delle norme:

   gcloud config set project POLICY_PROJECT_ID
   

2. Configura una risorsa mesh:

   gcloud network-services meshes import example-mesh --source=- --location=global << EOF
   name: example-mesh
   EOF
   

   Il nome della risorsa mesh è la chiave utilizzata dai proxy sidecar per richiedere la configurazione delmesh di servizih.

3. Configura una baseline BackendService con un controllo di integrità:

   gcloud compute health-checks create http http-example-health-check
   
   gcloud compute backend-services create example-service \
     --global \
     --load-balancing-scheme=INTERNAL_SELF_MANAGED \
     --protocol=HTTP \
     --health-checks http-example-health-check
   

4. Collega NetworkEndpointGroup creato nella sezione precedente a BackendService:

   gcloud compute backend-services add-backend example-service --global \
     --network-endpoint-group=${NEG_LINK} \
     --balancing-mode=RATE \
     --max-rate-per-endpoint=5
   

5. Crea un HTTPRoute per indirizzare tutte le richieste HTTP con l'intestazione host example-service al server nel progetto del workload:

   gcloud network-services http-routes import example-route --source=- --location=global << EOF
   name: example-route
   hostnames:
   - example-service
   meshes:
   - projects/POLICY_PROJECT_NUMBER/locations/global/meshes/example-mesh
   rules:
   - action:
       destinations:
       - serviceName: "projects/POLICY_PROJECT_NUMBER/locations/global/backendServices/example-service"
   EOF
   

   dove POLICY_PROJECT_NUMBER è il numero di progetto del progetto di criteri.

Verifica la configurazione

Puoi verificare la configurazione inviando una richiesta HTTP con l'intestazione HOST impostata su example-service a un VIP dietro un proxy sidecar gestito da Traffic Director:

curl -H "Host: example-service" http://10.0.0.1/

L'output è simile al seguente:

{"cluster_name":"test-cluster","gce_instance_id":"4879146330986909656","gce_service_account":"...","host_header":"example-service","pod_name":"whereami-7fbffd489-nhkfg","pod_name_emoji":"...","project_id":"...","timestamp":"2024-10-15T00:42:22","zone":"us-west1-a"}

Tieni presente che tutto il traffico in uscita dai pod viene intercettato da un sidecar Envoy in un mesh di servizi e che l'HTTPRoute precedente è configurato per inviare tutto il traffico al servizio Kubernetes "whereami" esclusivamente in base all'attributo L7 (intestazione host). A scopo esemplificativo, il VIP in questo comando è 10.0.0.1, ma può essere qualsiasi IP.

Il proxy sidecar deve richiedere le configurazioni associate alla risorsa mesh nel progetto delle norme. A tal fine, assicurati che l'ID nodo sia impostato nel seguente formato:

projects/POLICY_PROJECT_NUMBER/networks/mesh:example-mesh/nodes/UUID"

Passaggi successivi

• Configurare la route mesh tra progetti