Configurare un 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 ulteriori informazioni, consulta la panoramica di Cloud Service Mesh.

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.

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

• In un deployment multi-project, BackendServices insieme ai relativi criteri di routing e traffico associati in un progetto centralizzato. con endpoint di backend da progetti diversi.

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

Questa pagina mostra come creare una configurazione di base di due progetti in cui il NEG nel progetto A (chiamato progetto del workload) è collegato al BackendService nel progetto B (chiamato progetto della policy). L'esempio seguente configura le VM del carico di lavoro nella rete VPC predefinita del progetto del carico di lavoro e dimostra che il client può eseguire il routing nel progetto del carico di lavoro in base alle configurazioni nel progetto del criterio.

In una configurazione più sofisticata, è necessaria una soluzione come VPC condiviso per un dataplane interconnesso in più progetti. Ciò implica anche che gli endpoint NEG hanno IP univoci. Questa configurazione di esempio può essere estesa a scenari più complicati in cui i carichi di lavoro si trovano in una rete VPC condiviso che copre 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 per una configurazione di più progetti:

• Un singolo BackendService può supportare fino a 50 backend(inclusi NEG e MIG).
• Sono supportati solo i NEG zonali di tipo GCP_VM_IP_PORT.
• Il riferimento ai gruppi di istanze (gestiti o non gestiti) di BackendServices tra progetti non è supportato.
• L'elenco di NEG tra progetti che possono essere collegati a un determinato BackendService non è supportato.
• L'elenco di servizi di backend 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 il seguente comando per abilitare le API richieste sia nel progetto di workload sia nel progetto di criteri:

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 oroles/editor) del progetto in cui stai attivando 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 obbligatori sia nei progetti di carichi di lavoro che nei progetti di criteri:

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

I seguenti ruoli sono obbligatori solo nel progetto del 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 l'attacco di un NEG a un servizio di backend è roles/compute.loadBalancerServiceUser.
  • compute.networkEndpointGroups.get
  • compute.networkEndpointGroups.use

Inoltre, i client xDS gestiti da Traffic Director (come il proxy Envoy) devono avere le autorizzazioni riportate in roles/trafficdirector.client. A scopo dimostrativo, puoi utilizzare il seguente comando per concedere questa autorizzazione nel progetto di criteri all'account di servizio Compute predefinito del progetto di carico di lavoro:

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 criterio.
• WORKLOAD_PROJECT_NUMBER è il numero del progetto di carico di lavoro.

Configura un backend di servizio nel progetto di carico di lavoro

1. Esegui il seguente comando per indirizzare la tua Google Cloud CLI al progetto di criteri 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 comando seguente 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 piano di controllo di Google Cloud di inviare probe di controllo di integrità'integrità ai backend nella rete VPC predefinita.

4. Modifica il contesto corrente di 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 gruppo di endpoint di rete a livello di zona per i backend dei servizi in ogni zona. In questo esempio, il nome NEG è hardcoded a example-neg. Memorizzarlo come variabile sarà utile nella sessione successiva quando collegherai questo NEG a un BackendService nel progetto del criterio.

   Se utilizzi $NEG_LINK, l'esempio 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 rete Google Cloud nel progetto di criteri

1. Indica a Google Cloud CLI il progetto di 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 del mesh è la chiave utilizzata dai proxy sidecar per richiedere la configurazione del mesh di servizi.

3. Configura un riferimento 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 il NetworkEndpointGroup creato nella sezione precedente al 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 parametro HTTPRoute per indirizzare tutte le richieste HTTP con intestazione dell'hostexample-service al server nel progetto del carico di lavoro:

   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 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, poiché tutto il traffico in uscita dai pod viene intercettato da un sidecar Envoy in un mesh di servizi e la route HTTP precedente è configurata per inviare tutto il traffico al servizio Kubernetes "whereami" esclusivamente in base all'attributo L7 (intestazione host), A scopo di esempio, l'IP virtuale 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 di criteri. Per farlo, 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