VPC diretto con una rete VPC

Puoi abilitare il servizio, la funzione, il job, il pool di worker o l'istanza Cloud Run utilizzando il traffico in uscita VPC diretto senza richiedere un connettore di accesso VPC serverless.

Alcune risorse, come i pool di worker e le istanze, possono anche ricevere traffico da una rete VPC utilizzando il traffico in entrata VPC diretto.

Cloud Run supporta le seguenti configurazioni VPC diretto:

Prima di iniziare

Limitazioni

Le seguenti limitazioni si applicano ai servizi e ai job , alle funzioni, ai job, ai pool di worker e alle istanze:

  • Quando utilizzi il VPC diretto in uscita, potresti riscontrare ritardi di un minuto o più nello stabilire la connessione all'avvio dell'istanza. Ti consigliamo di configurare un probe di avvio HTTP che verifichi una connessione a una destinazione in uscita utilizzata dall'applicazione prima che l'applicazione accetti le richieste. Questo test di connettività in uscita deve implementare i nuovi tentativi o il probe di avvio deve essere impostato con configurazioni di periodo e soglia appropriate per fungere da nuovo tentativo.
  • I job Cloud Run che vengono eseguiti per più di un'ora potrebbero subire interruzioni della connessione. Questi possono verificarsi durante gli eventi di manutenzione che eseguono la migrazione del job da una macchina all'altra. Il container riceve un segnale SIGTSTP 10 secondi prima dell'evento e un segnale SIGCONT dopo l'evento. Dopo che il container riceve il segnale SIGCONT, riprova a effettuare la connessione.
  • Con Cloud NAT, potresti riscontrare ritardi di avvio a freddo di 30 secondi o più all'avvio dell'istanza quando utilizzi il VPC diretto in uscita. Per prestazioni di avvio migliori, ti consigliamo di utilizzare i connettori di accesso VPC serverless con Cloud NAT.
  • Cloud Run supporta un throughput fino a 1 Gbps per singola istanza di container. Il superamento di questo importo comporta una limitazione delle prestazioni.

  • Una quota di utilizzo di Cloud Run limita il numero massimo di istanze di container che puoi configurare per l'utilizzo del traffico VPC diretto in uscita. Il numero massimo è configurato per revisione Cloud Run o esecuzione del job. Per aumentare i limiti predefiniti, consulta come aumentare le quote.

  • I servizi e i job servizi, job, pool di worker e istanze potrebbero subire interruzioni della connessione durante gli eventi di manutenzione dell'infrastruttura di networking. Ti consigliamo di utilizzare librerie client in grado di gestire occasionali reimpostazioni della connessione.
  • Network Intelligence Center supporta solo Connectivity Tests e Flow Analyzer per gli intervalli di subnet IPv4 e IPv6.
  • Anche se i pool di worker e le istanze Cloud Run supportano l'accesso VPC diretto, non puoi utilizzare i tag di rete per definire la destinazione di una regola firewall in entrata.
  • Il traffico in entrata verso i pool di worker e le istanze Cloud Run è supportato solo utilizzando il VPC diretto, non i connettori di accesso VPC serverless. I connettori non supportano il traffico in entrata.

I seguenti elementi non sono supportati dal traffico VPC diretto in uscita:

  • I log di flusso VPC non forniscono il nome della revisione Cloud Run.
  • Logging delle regole firewall VPC
  • Mirroring pacchetto
  • Tag di rete o identità di servizio nelle regole firewall in entrata.
  • Le regole firewall non possono utilizzare i tag di Resource Manager associati ai workload di Cloud Run.
  • Ispezione del traffico in uscita con Cloud Next Generation Firewall Enterprise, ad esempio il servizio di rilevamento delle intrusioni e prevenzione, il servizio di filtro degli URL e l'ispezione TLS.

Allocazione degli indirizzi IP

Per posizionare il servizio o il job servizio, job, pool di worker o istanzasu una rete VPC, specifica una rete VPC o una subnet o entrambe. Se specifichi solo una rete, la subnet utilizza lo stesso nome della rete. Cloud Run alloca gli indirizzi IP dalla tua subnet.

Gli indirizzi IP sono temporanei, quindi non creare policy basate su singoli IP. Se devi creare una policy basata sugli IP, ad esempio nelle regole firewall, devi utilizzare l'intervallo di indirizzi IP dell'intera subnet.

Per modificare la rete o la subnet utilizzata dalla risorsa Cloud Run, crea un nuovo deployment della revisione, delle attività del job o dell'istanza che utilizza i nuovi valori di rete e subnet.

Scale up e fare lo scale down

Per uno scale up più rapido durante un picco di traffico, Cloud Run prenota gli indirizzi IP in blocchi di 16 (subnet mask 28) alla volta. Scopri quali indirizzi IP sono stati allocati da Cloud Run. Per assicurarti di avere un numero sufficiente di indirizzi IPv4 disponibili per l'utilizzo in Cloud Run, l'intervallo di indirizzi IPv4 della subnet deve essere /26 o superiore.

Per l'efficienza dell'allocazione degli IP e la facilità di gestione, posiziona più risorse sulla stessa subnet. Se lo spazio di indirizzi IPv4 è limitato, consulta Intervalli IPv4 supportati per altre opzioni.

Per eliminare la subnet, devi prima eliminare o rifare il deployment dei servizi o dei jobservizi, job, pool di worker o istanze per interrompere l'utilizzo della subnet, quindi attendere 1-2 ore.

Consumo di indirizzi IP per servizi e pool di worker

In stato stabile, Cloud Run utilizza il doppio (2X) degli indirizzi IP rispetto al numero di istanze di container. Quando una revisione fa lo scale down, Cloud Run conserva i suoi indirizzi IP per un massimo di 20 minuti. In totale, prenota almeno il doppio del numero di indirizzi IP, più un buffer per tenere conto degli aggiornamenti delle revisioni.

Ad esempio, se esegui l'upgrade delle revisioni in modo che revision 1 passi da 100 istanze di container a zero, mentre revision 2 passa da zero a 100, Cloud Run conserva gli indirizzi IP revision 1 per un massimo di 20 minuti dopo lo scale down. Durante la finestra di conservazione di 20 minuti, devi prenotare almeno 400 indirizzi IP ((100 + 100) * 2).

Consumo di IP per i job

Per i job Cloud Run, ogni task utilizza un indirizzo IP per la durata della sua esecuzione più 7 minuti dopo il completamento. Assicurati che la tua subnet sia abbastanza grande da contenere tutte le esecuzioni di attività dei job simultanee, con una subnet di prenotazione minima /26 richiesta.

Ad esempio:

  • Un job con una singola attività che viene eseguito ogni giorno e viene sempre completato almeno 7 minuti prima dell'esecuzione successiva consuma al massimo un indirizzo IP nella subnet.
  • Un job di 10 attività eseguito ogni 10 minuti, con ogni attività eseguita per 15 minuti, consuma 1 indirizzo IP per 22 minuti per attività (3 esecuzioni consumano indirizzi IP contemporaneamente), come mostrato nell'esempio seguente. Il job utilizza quindi 30 indirizzi IP in stato stabile.
  • Un job con una singola attività che richiede 1 minuto per l'esecuzione e viene eseguito 100 volte al minuto richiede circa 800 indirizzi IP, a seconda dell'ora esatta di esecuzione.

Consumo di indirizzi IP per le istanze Cloud Run

Ogni istanza Cloud Run utilizza quattro indirizzi IP nella subnet per tutto il tempo in cui è connessa alla rete VPC.

Gli indirizzi IP non sono statici per nessuna risorsa Cloud Run, anche se le istanze Cloud Run hanno una lunga durata. Queste associazioni di indirizzi IP non vengono mantenute dopo arresti, riavvii o aggiornamenti. Quando arresti, riavvii o aggiorni un'istanza, viene assegnato un nuovo indirizzo IP privato all'istanza.

Intervalli IPv4 supportati

Cloud Run supporta i seguenti intervalli IPv4 per la subnet:

  • RFC 1918
    • 10.0.0.0/8
    • 172.16.0.0/12
    • 192.168.0.0/16
  • RFC 6598
    • 100.64.0.0/10
  • Classe E
    • 240.0.0.0/4

Configura le autorizzazioni IAM

Assicurati che Cloud Run abbia accesso alla rete VPC utilizzando uno dei seguenti metodi:

  • Ruolo Cloud Run Service Agent: per impostazione predefinita, il service agent Cloud Run dispone del ruolo Cloud Run Service Agent (roles/run.serviceAgent) che contiene le autorizzazioni necessarie.

  • Autorizzazioni personalizzate: per un controllo più granulare, concedi all'agente di servizio Cloud Run le seguenti autorizzazioni aggiuntive sul progetto:

    • compute.networks.get
    • compute.subnetworks.get
    • compute.subnetworks.use sul progetto o sulla subnet specifica
    • compute.addresses.get
    • compute.addresses.list
    • compute.addresses.create (obbligatorio solo per le subnet dual stack con IPv6 esterno)
    • compute.addresses.delete (obbligatorio solo per le subnet dual stack con IPv6 esterno)
    • compute.addresses.createInternal
    • compute.addresses.deleteInternal
    • compute.regionOperations.get

  • Ruolo Compute Network User: se non utilizzi il ruolo predefinito Cloud Run Service Agent o le autorizzazioni personalizzate, concedi il ruolo Compute Network User (roles/compute.networkUser) al account di servizio Cloud Run Service Agent. Le subnet con IPv6 esterno richiedono anche il ruolo Compute Public IP Admin (roles/compute.publicIpAdmin).

    Ad esempio, per concedere il ruolo Compute Network User, esegui questo comando:

    gcloud projects add-iam-policy-binding PROJECT_ID \
--member "serviceAccount:service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com" \
--role "roles/compute.networkUser"

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID progetto.
    • PROJECT_NUMBER: il numero del progetto in cui esegui il deployment della risorsa Cloud Run.

Connetti le risorse Cloud Run a una rete VPC

A seconda della risorsa Cloud Run di cui disponi, consulta le istruzioni in una delle seguenti sezioni:

Connetti un servizio a una rete VPC

Il traffico VPC diretto in uscita consente al servizio Cloud Run di inviare traffico a una rete VPC senza un connettore di accesso VPC serverless. I costi di rete scalano fino a zero, proprio come il servizio stesso. Puoi anche aggiungere tag di rete direttamente alle revisioni dei servizi Cloud Run per una sicurezza di rete più granulare, ad esempio applicando regole firewall VPC.

Puoi configurare il traffico VPC diretto con un servizio utilizzando la consoleGoogle Cloud , Google Cloud CLI, YAML o Terraform.

Console

  1. Nella console Google Cloud , vai a Cloud Run:

    Vai a Cloud Run

  2. Fai clic su Crea servizio se stai configurando un nuovo servizio di cui eseguire il deployment. Se stai configurando ed eseguendo il deployment di un servizio esistente, fai clic sul servizio.

  3. Se stai configurando un nuovo servizio, compila la pagina delle impostazioni iniziali del servizio in base alle tue esigenze, poi fai clic su Container, networking, sicurezza per espandere la pagina di configurazione del servizio.

  4. Fai clic sulla scheda Networking.

  5. Fai clic su Connettiti a un VPC per il traffico in uscita.

  6. Fai clic su Invia il traffico direttamente a un VPC.

  7. Nel campo Rete, seleziona la rete VPC a cui vuoi inviare il traffico.

  8. Nel campo Subnet, seleziona la subnet da cui il servizio riceve gli indirizzi IP. Puoi eseguire il deployment di più servizi nella stessa subnet.

  9. (Facoltativo) Inserisci i nomi dei tag di rete che vuoi associare ai tuoi servizi. I tag di rete sono specificati a livello di revisione. Ogni revisione del servizio può avere tag di rete diversi, ad esempio network-tag-2.

  10. In Routing del traffico, seleziona una delle seguenti opzioni:

    • Instrada al VPC solo richieste a IP privati per inviare solo il traffico agli indirizzi interni tramite la rete VPC.
    • Instrada al VPC tutto il traffico per inviare tutto il traffico in uscita tramite la rete VPC.

  11. Fai clic su Crea per un nuovo servizio. Fai clic su Visualizza differenze e fai di nuovo il deployment, quindi su Esegui il deployment delle modifiche per un servizio esistente.

  12. Per verificare che il servizio si trovi sulla tua rete VPC, fai clic sul servizio, quindi sulla scheda Networking. La rete e la subnet sono elencate nella scheda VPC.

    Ora puoi inviare richieste dal tuo servizio Cloud Run a qualsiasi risorsa della rete VPC, come consentito dalle regole del firewall.

gcloud

Servizio

Per eseguire il deployment di un servizio Cloud Run senza un connettore da Google Cloud CLI:

  1. Aggiorna i componenti di gcloud all'ultima versione:

    gcloud components update

  2. Assicurati che l'API Compute Engine sia abilitata per il tuo progetto:

    gcloud services enable compute.googleapis.com

  3. Esegui il deployment del servizio Cloud Run con il seguente comando:

    gcloud run deploy SERVICE_NAME \
    --image=IMAGE_URL \
    --network=NETWORK \
    --subnet=SUBNET \
    --network-tags=NETWORK_TAG_NAMES \
    --vpc-egress=EGRESS_SETTING \
    --region=REGION

    Sostituisci:

    • SERVICE_NAME con il nome del tuo servizio Cloud Run.
    • IMAGE_URLus-docker.pkg.dev/cloudrun/container/hello:latest. Se utilizzi Artifact Registry, il repository REPO_NAME deve essere già stato creato. L'URL segue il formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
    • NETWORK con il nome della tua rete VPC. Specifica una rete VPC o una subnet oppure entrambe. Se specifichi solo una rete, la subnet utilizza lo stesso nome della rete.
    • SUBNET con il nome della subnet. Specifica una rete VPC o una subnet oppure entrambe. Se specifichi solo una rete, la subnet utilizza lo stesso nome della rete. Puoi eseguire il deployment o l'esecuzione di più servizi, job, pool di worker o istanze nella stessa subnet.
    • (Facoltativo) NETWORK_TAG_NAMES con i nomi separati da virgole dei tag di rete che vuoi associare a un servizio. Per i servizi, i tag di rete vengono specificati a livello di revisione. Ogni revisione del servizio può avere tag di rete diversi, ad esempio network-tag-2.
    • EGRESS_SETTING con un valore dell'impostazione del traffico in uscita:
      • all-traffic: invia tutto il traffico in uscita tramite la rete VPC.
      • private-ranges-only: invia solo il traffico agli indirizzi interni tramite la rete VPC.
    • REGION con una regione per il tuo servizio.

  4. Per verificare che il servizio si trovi sulla tua rete VPC, esegui il seguente comando:

    gcloud run services describe SERVICE_NAME \
    --region=REGION

    Sostituisci:

    • SERVICE_NAME con il nome del tuo servizio.
    • REGION con la regione del servizio specificata nel passaggio precedente.

    L'output deve contenere il nome della rete, della subnet e dell'impostazione del traffico in uscita, ad esempio:

    VPC access:
  Network:       default
  Subnet:        subnet
  Egress:        private-ranges-only

Ora puoi inviare richieste dal tuo servizio Cloud Run a qualsiasi risorsa della rete VPC, come consentito dalle regole del firewall.

Funzione

Per eseguire il deployment di una funzione Cloud Run senza un connettore da Google Cloud CLI:

  1. Aggiorna i componenti di gcloud all'ultima versione:

    gcloud components update

  2. Assicurati che l'API Compute Engine sia abilitata per il tuo progetto:

    gcloud services enable compute.googleapis.com

  3. Esegui il deployment della funzione Cloud Run con il seguente comando:

    gcloud run deploy FUNCTION_NAME \
    --image=IMAGE_URL \
    --network=NETWORK \
    --subnet=SUBNET \
    --network-tags=NETWORK_TAG_NAMES \
    --vpc-egress=EGRESS_SETTING \
    --region=REGION \
    --function=FUNCTION_ENTRYPOINT

    Sostituisci:

    • FUNCTION_NAME con il nome della tua funzione Cloud Run.
    • IMAGE_URLus-docker.pkg.dev/cloudrun/container/hello:latest. Se utilizzi Artifact Registry, il repository REPO_NAME deve essere già stato creato. L'URL segue il formato LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
    • NETWORK con il nome della tua rete VPC. Specifica una rete VPC o una subnet oppure entrambe. Se specifichi solo una rete, la subnet utilizza lo stesso nome della rete.
    • SUBNET con il nome della subnet. Specifica una rete VPC o una subnet oppure entrambe. Se specifichi solo una rete, la subnet utilizza lo stesso nome della rete. Puoi eseguire il deployment o l'esecuzione di più servizi, job, pool di worker o istanze nella stessa subnet.
    • Facoltativo: NETWORK_TAG_NAMES con i nomi separati da virgole dei tag di rete che vuoi associare a una funzione. Per le funzioni, i tag di rete vengono specificati a livello di revisione. Ogni revisione può avere tag di rete diversi, ad esempio network-tag-2.
    • EGRESS_SETTING con un valore dell'impostazione del traffico in uscita:
      • all-traffic: invia tutto il traffico in uscita tramite la rete VPC.
      • private-ranges-only: invia solo il traffico agli indirizzi interni tramite la rete VPC.
    • REGION con una regione per la tua funzione.
    • (Facoltativo) FUNCTION_ENTRYPOINT con l'entry point della funzione nel codice sorgente. Questo è il codice che Cloud Run esegue quando viene eseguita la funzione. Il valore di questo flag deve essere un nome di funzione o un nome di classe completo esistente nel codice sorgente.

  4. Per verificare che la funzione si trovi sulla tua rete VPC, esegui questo comando:

    gcloud run services describe FUNCTION_NAME \
    --region=REGION

    Sostituisci:

    • FUNCTION_NAME con il nome della tua funzione.
    • REGION con la regione della funzione che hai specificato nel passaggio precedente.

    L'output deve contenere il nome della rete, della subnet e dell'impostazione del traffico in uscita, ad esempio:

    VPC access:
  Network:       default
  Subnet:        subnet
  Egress:        private-ranges-only

Ora puoi inviare richieste dalla tua funzione Cloud Run a qualsiasi risorsa della rete VPC, come consentito dalle regole del firewall.

YAML

  1. Se stai creando un nuovo servizio, salta questo passaggio. Se stai aggiornando un servizio esistente, scarica la relativa configurazione YAML:

    gcloud run services describe SERVICE --format export > service.yaml

  2. Aggiorna i seguenti attributi:

    apiVersion: serving.knative.dev/v1
  kind: Service
  metadata:
    name: SERVICE_NAME
    labels:
      cloud.googleapis.com/location: REGION
  spec:
    template:
      metadata:
        annotations:
          run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'
          run.googleapis.com/vpc-access-egress: EGRESS_SETTING
      spec:
        containers:
        - image: IMAGE

    Sostituisci:

    • SERVICE_NAME con il nome del tuo servizio Cloud Run. I nomi dei servizi devono avere una lunghezza massima di 49 caratteri ed essere univoci per regione e progetto.
    • REGION con la regione del tuo servizio Cloud Run, che deve corrispondere alla regione della tua subnet.
    • NETWORK con il nome della tua rete VPC. Specifica una rete VPC o una subnet oppure entrambe. Se specifichi solo una rete, la subnet utilizza lo stesso nome della rete.
    • SUBNET con il nome della subnet. Specifica una rete VPC o una subnet oppure entrambe. Se specifichi solo una rete, la subnet utilizza lo stesso nome della rete. Puoi eseguire il deployment o l'esecuzione di più servizi, job, pool di worker o istanze nella stessa subnet.
    • (Facoltativo) NETWORK_TAG_NAMES con i nomi dei tag di rete che vuoi associare a un servizio. Per i servizi, i tag di rete vengono specificati a livello di revisione. Ogni revisione del servizio può avere tag di rete diversi, ad esempio network-tag-2.
    • EGRESS_SETTING con un valore dell'impostazione del traffico in uscita:
      • all-traffic: invia tutto il traffico in uscita tramite la rete VPC.
      • private-ranges-only: invia solo il traffico agli indirizzi interni tramite la rete VPC.
    • IMAGE con l'URL dell'immagine container del servizio.

    Puoi anche specificare altre configurazioni, come variabili di ambiente o limiti di memoria.

  3. Crea o aggiorna il servizio utilizzando il seguente comando:

    gcloud run services replace service.yaml

Terraform

Per scoprire come applicare o rimuovere una configurazione Terraform, consulta Comandi Terraform di base.

  1. Aggiungi quanto segue al tuo file main.tf:

    /**
 * Copyright 2024 Google LLC
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

# Example configuration of a Cloud Run service with direct VPC

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service"
  location = "us-central1"

  deletion_protection = false # set to "true" in production

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"
    }
    vpc_access {
      network_interfaces {
        network    = "default"
        subnetwork = "default"
        tags       = ["tag1", "tag2", "tag3"]
      }
    }
  }
}

Facoltativamente, rendi pubblico il servizio se vuoi consentire l'accesso non autenticato al servizio.

Connetti un job a una rete VPC

Il traffico VPC diretto in uscita consente al job Cloud Run di inviare traffico a una rete VPC senza un connettore di accesso VPC serverless. Puoi anche aggiungere tag di rete direttamente ai job Cloud Run per una sicurezza di rete più granulare, ad esempio applicando regole firewall VPC.

Puoi configurare il traffico VPC diretto in uscita con un job utilizzando la consoleGoogle Cloud , Google Cloud CLI o YAML.

Console

  1. Vai a Cloud Run

  2. Se stai configurando un nuovo job, fai clic sulla scheda Job e compila la pagina delle impostazioni iniziali del job in base alle tue esigenze. Se stai configurando un job esistente, fai clic sul job, quindi su Modifica.

  3. Fai clic su Container, variabili e secret, connessioni, sicurezza per espandere la pagina delle proprietà del job.

  4. Fai clic sulla scheda Connessioni.

  5. Fai clic su Connettiti a un VPC per il traffico in uscita.

  6. Fai clic su Invia il traffico direttamente a un VPC.

  7. Nel campo Rete, seleziona la rete VPC a cui vuoi inviare il traffico.

  8. Nel campo Subnet, seleziona la subnet da cui il job riceve gli indirizzi IP. Puoi eseguire più job sulla stessa subnet.

  9. In Routing del traffico, seleziona una delle seguenti opzioni:

    • Instrada al VPC solo richieste a IP privati per inviare solo il traffico agli indirizzi interni tramite la rete VPC.
    • Instrada al VPC tutto il traffico per inviare tutto il traffico in uscita tramite la rete VPC.

  10. (Facoltativo) Inserisci i nomi dei tag di rete che vuoi associare ai tuoi servizi. I tag di rete sono specificati a livello di revisione. Ogni revisione del servizio può avere tag di rete diversi, ad esempio network-tag-2.

  11. (Facoltativo) Inserisci i nomi dei tag di rete che vuoi associare ai tuoi job. Per i job, i tag di rete vengono specificati a livello di esecuzione. Ogni esecuzione del job può avere tag di rete diversi, ad esempio network-tag-2.

  12. Fai clic su Crea o Aggiorna.

  13. Per verificare che il job si trovi sulla tua rete VPC, fai clic sul job, quindi sulla scheda Configurazione. La rete e la subnet sono elencate nella scheda VPC.

    Ora puoi eseguire il job Cloud Run e inviare richieste dal job a qualsiasi risorsa della rete VPC, come consentito dalle regole firewall.

gcloud

Per creare un job Cloud Run senza un connettore da Google Cloud CLI:

  1. Aggiorna i componenti di gcloud all'ultima versione:

    gcloud components update

  2. Assicurati che l'API Compute Engine sia abilitata per il tuo progetto:

    gcloud services enable compute.googleapis.com

  3. Crea un job Cloud Run con il seguente comando:

    gcloud run jobs create JOB_NAME \
--image=IMAGE_URL \
--network=NETWORK \
--subnet=SUBNET \
--network-tags=NETWORK_TAG_NAMES \
--vpc-egress=EGRESS_SETTING \
--region=REGION

    Sostituisci:

    • JOB_NAME con il nome del tuo job Cloud Run.
    • IMAGE_URL: un riferimento all'immagine container, ad esempio us-docker.pkg.dev/cloudrun/container/job:latest
    • NETWORK con il nome della tua rete VPC. Specifica una rete VPC o una subnet, o entrambe. Se specifichi solo una rete, la subnet utilizza lo stesso nome della rete.
    • SUBNET con il nome della subnet. Specifica una rete VPC o una subnet oppure entrambe. Se specifichi solo una rete, la subnet utilizza lo stesso nome della rete. Puoi eseguire il deployment o l'esecuzione di più servizi, job, pool di worker o istanze nella stessa subnet.
    • (Facoltativo) NETWORK_TAG_NAMES con i nomi dei tag di rete che vuoi associare a un job. Per i job, i tag di rete vengono specificati a livello di esecuzione. Ogni esecuzione del job può avere tag di rete diversi, ad esempio network-tag-2.
    • EGRESS_SETTING con un valore dell'impostazione del traffico in uscita:
      • all-traffic: invia tutto il traffico in uscita tramite la rete VPC.
      • private-ranges-only: invia solo il traffico agli indirizzi interni tramite la rete VPC.
    • REGION con una regione per il job.

  4. Per verificare che il job si trovi sulla tua rete VPC, esegui questo comando:

    gcloud run jobs describe JOB_NAME \
  --region=REGION

    Sostituisci:

    • JOB_NAME con il nome del job.
    • REGION con la regione del job specificata nel passaggio precedente.

    L'output dovrebbe contenere il nome della rete e della subnet, ad esempio:

    VPC network:
  Network:       default
  Subnet:        default

Ora puoi eseguire il job Cloud Run e inviare richieste dal job a qualsiasi risorsa della rete VPC, come consentito dalle regole firewall.

YAML

  1. Se stai creando un nuovo job, salta questo passaggio. Se stai aggiornando un job esistente, scarica la relativa configurazione YAML:

    gcloud run jobs describe JOB --format export > job.yaml

  2. Aggiorna i seguenti attributi:

    apiVersion: run.googleapis.com/v1
  kind: Job
  metadata:
    name: JOB_NAME
    labels:
      cloud.googleapis.com/location: REGION
  spec:
    template:
      metadata:
        annotations:
          run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'
          run.googleapis.com/vpc-access-egress: EGRESS_SETTING
      spec:
        containers:
        - image: IMAGE

    Sostituisci:

    • JOB_NAME con il nome del tuo job Cloud Run. I nomi dei job devono avere una lunghezza massima di 49 caratteri e devono essere univoci per regione e progetto.
    • REGION con la regione del job Cloud Run, che deve corrispondere alla regione della subnet.
    • NETWORK con il nome della tua rete VPC. Specifica una rete VPC o una subnet oppure entrambe. Se specifichi solo una rete, la subnet utilizza lo stesso nome della rete.
    • SUBNET con il nome della subnet. Specifica una rete VPC o una subnet oppure entrambe. Se specifichi solo una rete, la subnet utilizza lo stesso nome della rete. Puoi eseguire il deployment o l'esecuzione di più servizi, job, pool di worker o istanze nella stessa subnet.
    • (Facoltativo) NETWORK_TAG_NAMES con i nomi dei tag di rete che vuoi associare a un job. Per i job, i tag di rete vengono specificati a livello di esecuzione. Ogni esecuzione del job può avere tag di rete diversi, ad esempio network-tag-2.
    • EGRESS_SETTING con un valore dell'impostazione del traffico in uscita:
      • all-traffic: invia tutto il traffico in uscita tramite la rete VPC.
      • private-ranges-only: invia solo il traffico agli indirizzi interni tramite la rete VPC.
    • IMAGE con l'URL dell'immagine container del job.

  3. Crea o aggiorna il job utilizzando il seguente comando:

    gcloud run jobs replace job.yaml

Connetti un pool di worker a una rete VPC

VPC diretto consente al pool di worker Cloud Run di inviare o ricevere traffico da o verso un VPC. Ogni istanza del pool di worker riceve un indirizzo IP privato sulla rete e sulla subnet configurate.

A differenza dei servizi o dei job, la connettività VPC diretta per i pool di worker consente il traffico in uscita e in entrata. Ciò significa che le istanze del pool di worker possono raggiungere le risorse sulla rete VPC e le risorse sulla rete VPC possono raggiungere un'istanza del pool di worker utilizzando il suo indirizzo IP. Scopri come un'istanza può recuperare i propri indirizzi IP privati utilizzando il server dei metadati.

Puoi anche aggiungere tag di rete direttamente alle revisioni del pool di worker Cloud Run con traffico VPC diretto in uscita per una sicurezza di rete più granulare, ad esempio applicando regole firewall VPC.

Puoi configurare il traffico VPC diretto in uscita utilizzando la console Google Cloud , Google Cloud CLI o YAML.

Console

  1. Vai a Cloud Run

  2. Seleziona Pool di worker dal menu e fai clic su Esegui il deployment del container per configurare un nuovo pool di worker. Se stai configurando un pool di worker esistente, fai clic sul pool di worker, quindi su Modifica ed esegui il deployment di una nuova revisione.

  3. Se stai configurando un nuovo pool di worker, compila la pagina iniziale del pool di worker, quindi fai clic su Container, volumi, networking, sicurezza per espandere la pagina di configurazione dei pool di worker.

  4. Fai clic sulla scheda Networking.

  5. Seleziona Connettiti a un VPC.

  6. Fai clic su Crea o Esegui il deployment.

    Ora puoi inviare richieste dal pool di worker Cloud Run a qualsiasi risorsa della rete VPC, come consentito dalle regole del firewall.

gcloud

Per eseguire il deployment di un pool di worker Cloud Run senza un connettore da Google Cloud CLI:

  1. Aggiorna i componenti di gcloud all'ultima versione:

    gcloud components update

  2. Assicurati che l'API Compute Engine sia abilitata per il tuo progetto:

    gcloud services enable compute.googleapis.com

  3. Esegui il deployment del pool di worker Cloud Run con il seguente comando:

    • Per il VPC diretto in uscita:
    gcloud run worker-pools deploy WORKER_POOL \
    --image=IMAGE_URL \
    --network=NETWORK \
    --subnet=SUBNET \
    --network-tags=NETWORK_TAG_NAMES \
    --region=REGION
    • Per il traffico in entrata VPC diretto:
    gcloud run worker-pools deploy WORKER_POOL \
    --image=IMAGE_URL \
    --network=NETWORK \
    --subnet=SUBNET \
    --region=REGION

    Sostituisci:

    • WORKER_POOL con il nome del tuo pool di worker Cloud Run. I nomi dei pool di worker devono contenere al massimo 49 caratteri, utilizzare un nome univoco per regione e progetto e non devono condividere lo stesso nome di un servizio esistente del progetto. Se il pool di worker non esiste ancora, questo comando lo crea durante il deployment. Puoi omettere completamente questo parametro, ma in questo caso ti verrà richiesto il nome del pool di worker.
    • IMAGE_URL: un riferimento all'immagine container che contiene il pool di worker, ad esempio us-docker.pkg.dev/cloudrun/container/worker-pool:latest
    • NETWORK con il nome della tua rete VPC. Specifica una rete VPC o una subnet oppure entrambe. Se specifichi solo una rete, la subnet utilizza lo stesso nome della rete.
    • SUBNET con il nome della subnet. Specifica una rete VPC o una subnet oppure entrambe. Se specifichi solo una rete, la subnet utilizza lo stesso nome della rete. Puoi eseguire il deployment o l'esecuzione di più servizi, job, pool di worker o istanze nella stessa subnet.
    • (Facoltativo, solo per VPC diretto in uscita): NETWORK_TAG_NAMES con i nomi separati da virgole dei tag di rete che vuoi associare a un pool di worker. Per i servizi, i tag di rete vengono specificati a livello di revisione. Ogni revisione del pool di worker può avere tag di rete diversi, ad esempio network-tag-2.
    • REGION con una regione per il tuo pool di worker.

  4. Per verificare che il pool di worker si trovi nella tua rete VPC, esegui questo comando:

    gcloud run worker-pools describe WORKER_POOL \
    --region=REGION

    Sostituisci:

    • WORKER_POOL con il nome del tuo pool di worker.
    • REGION con la regione del pool di worker specificata nel passaggio precedente.

    L'output deve contenere il nome della rete, della subnet e dell'impostazione del traffico in uscita, ad esempio:

    VPC access:
  Network:       default
  Subnet:        subnet
  Egress:        private-ranges-only

Ora puoi inviare richieste dal pool di worker Cloud Run a qualsiasi risorsa della rete VPC, come consentito dalle regole del firewall.

YAML

  1. Se stai creando un nuovo pool di worker, salta questo passaggio. Se stai aggiornando un pool di worker esistente, scarica la relativa configurazione YAML:

    gcloud run worker-pools describe WORKER_POOL --format export > worker-pool.yaml

  2. Aggiorna i seguenti attributi:

    apiVersion: run.googleapis.com/v1
  kind: WorkerPool
  metadata:
    name: WORKER_POOL
    labels:
      cloud.googleapis.com/location: REGION
  spec:
    template:
      metadata:
        annotations:
          run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'
          run.googleapis.com/vpc-access-egress: EGRESS_SETTING
      spec:
        containers:
        - image: IMAGE_URL

    Sostituisci quanto segue:

    • WORKER_POOL: il nome del tuo pool di worker Cloud Run.
    • REGION: la regione del pool di worker Cloud Run, che deve corrispondere alla regione della subnet.
    • NETWORK: il nome della tua rete VPC. Specifica una rete VPC o una subnet oppure entrambe. Se specifichi solo una rete, la subnet utilizza lo stesso nome della rete.
    • SUBNET con il nome della subnet. Specifica una rete VPC o una subnet oppure entrambe. Se specifichi solo una rete, la subnet utilizza lo stesso nome della rete. Puoi eseguire il deployment o l'esecuzione di più servizi, job, pool di worker o istanze nella stessa subnet.
    • (Facoltativo, solo VPC diretto in uscita) NETWORK_TAG_NAMES: i nomi dei tag di rete che vuoi associare al pool di worker. Per i pool di worker, i tag di rete vengono specificati a livello di revisione. Ogni revisione del pool di worker può avere tag di rete diversi, ad esempio network-tag-2.
    • EGRESS_SETTING: un valore dell'impostazione del traffico in uscita.
      • all-traffic: invia tutto il traffico in uscita tramite la rete VPC.
      • private-ranges-only: invia solo il traffico agli indirizzi interni tramite la rete VPC.
    • IMAGE_URL: un riferimento all'immagine container che contiene il pool di worker, ad esempio us-docker.pkg.dev/cloudrun/container/worker-pool:latest.

    Puoi anche specificare altre configurazioni, come variabili di ambiente o limiti di memoria.

  3. Crea o aggiorna il pool di worker utilizzando il seguente comando:

    gcloud run worker-pools replace worker-pool.yaml

    Il comando gcloud run worker-pools replace utilizza per impostazione predefinita il file worker-pool.yaml, se presente.

Connetti un'istanza a una rete VPC

Il VPC diretto consente all'istanza Cloud Run di inviare o ricevere traffico da o verso una rete VPC. Ogni istanza riceve un indirizzo IP privato sulla rete e sulla subnet configurate.

A differenza dei servizi o dei job, la connettività VPC diretta per le istanze consente sia il traffico in uscita sia quello in entrata. Ciò significa che le istanze possono raggiungere le risorse sulla rete VPC e le risorse sulla rete VPC possono anche raggiungere un'istanza utilizzando il suo indirizzo IP privato. Scopri come un'istanza può recuperare i propri indirizzi IP privati utilizzando il server dei metadati.

Puoi anche aggiungere tag di rete direttamente alle istanze Cloud Run con traffico VPC diretto in uscita per una sicurezza di rete più granulare, ad esempio applicando regole firewall VPC.

Puoi configurare il VPC diretto per un'istanza utilizzando Google Cloud CLI o YAML:

gcloud

Per eseguire il deployment di un'istanza Cloud Run con VPC diretto da Google Cloud CLI:

  1. Aggiorna i componenti di gcloud all'ultima versione:

    gcloud components update

  2. Assicurati che l'API Compute Engine sia abilitata per il tuo progetto:

    gcloud services enable compute.googleapis.com

  3. Esegui il deployment dell'istanza Cloud Run con il seguente comando:

    • Per il VPC diretto in uscita:
    gcloud beta run instances deploy INSTANCE_NAME \
    --image=IMAGE_URL \
    --network=NETWORK \
    --subnet=SUBNET \
    --network-tags=NETWORK_TAG_NAMES \
    --region=REGION
    • Per il traffico in entrata VPC diretto:
    gcloud beta run instances deploy INSTANCE_NAME \
    --image=IMAGE_URL \
    --network=NETWORK \
    --subnet=SUBNET \
    --region=REGION

    Sostituisci quanto segue:

    • INSTANCE_NAME: il nome dell'istanza Cloud Run.
    • IMAGE_URL: un riferimento all'immagine container, ad esempio us-docker.pkg.dev/cloudrun/container/hello:latest.
    • NETWORK: il nome della tua rete VPC. Specifica una rete VPC o una subnet oppure entrambe. Se specifichi solo una rete, la subnet utilizza lo stesso nome della rete.
    • SUBNET con il nome della subnet. Specifica una rete VPC o una subnet oppure entrambe. Se specifichi solo una rete, la subnet utilizza lo stesso nome della rete. Puoi eseguire il deployment o l'esecuzione di più servizi, job, pool di worker o istanze nella stessa subnet.
    • Facoltativo (solo VPC diretto in uscita): NETWORK_TAG_NAMES: i nomi separati da virgole dei tag di rete che vuoi associare all'istanza.
    • REGION: la regione dell'istanza.

  4. Per verificare che l'istanza si trovi nella tua rete VPC, esegui questo comando:

    gcloud beta run instances describe INSTANCE_NAME \
    --region=REGION

YAML

  1. Se stai creando una nuova istanza, salta questo passaggio. Se stai aggiornando un'istanza esistente, scarica la relativa configurazione YAML:

    gcloud beta run instances describe INSTANCE --format export > instance.yaml

  2. Aggiorna le annotazioni run.googleapis.com/network-interfaces e run.googleapis.com/vpc-access-egress in metadata.annotations:

    apiVersion: run.googleapis.com/v1
kind: Instance
metadata:
  name: INSTANCE_NAME
  labels:
    cloud.googleapis.com/location: REGION
  annotations:
    run.googleapis.com/launch-stage: BETA
    run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET","tags":["NETWORK_TAG_NAMES"]}]'
    run.googleapis.com/vpc-access-egress: 'EGRESS_SETTING'
spec:
  containers:
  - image: IMAGE_URL

  3. Crea o aggiorna l'istanza utilizzando il seguente comando:

    gcloud beta run instances replace instance.yaml

Recupera gli indirizzi IP privati utilizzando il server di metadati

Puoi accedere agli indirizzi IP privati tra le istanze della tua rete VPC per una comunicazione interna sicura. Per recuperare l'indirizzo IP privato di un'istanza di un pool di worker o di un'istanza Cloud Run dal server di metadati, esegui questi comandi all'interno del container:

  • Per ottenere l'indirizzo IPv4, invia una richiesta al server dei metadati all'endpoint /computeMetadata/v1/instance/network-interfaces/0/ip:

    curl "http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/ip" -H "Metadata-Flavor: Google"

  • Per ottenere l'indirizzo IPv6, crea l'istanza con una subnet dual stack e invia una richiesta al server di metadati all'endpoint /computeMetadata/v1/instance/network-interfaces/0/ipv6:

    curl "http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/ipv6" -H "Metadata-Flavor: Google"

  • Per verificare che l'istanza del pool di worker o l'istanza Cloud Run sia collegata a una rete VPC, esegui una query sui seguenti percorsi dei metadati dell'interfaccia di rete:

    # Verify the existence of the network interface directory

curl "http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/" -H "Metadata-Flavor: Google"

# Verify the existence of the first network interface

curl "http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/" -H "Metadata-Flavor: Google"

Gestisci gli errori del server di metadati

Il server dei metadati restituisce un errore 404: Not Found nei seguenti scenari:

  • Se esegui una query per un indirizzo IPv6 su una subnet solo IPv4.

  • Se non connetti l'istanza del pool di worker o l'istanza Cloud Run a una rete VPC. In questo caso, il server dei metadati restituisce un errore per i seguenti percorsi:

    • /computeMetadata/v1/instance/network-interfaces
    • /computeMetadata/v1/instance/network-interfaces/0
    • /computeMetadata/v1/instance/network-interfaces/0/ip
    • /computeMetadata/v1/instance/network-interfaces/0/ipv6

Configura il dual-stack (IPv4 e IPv6)

Per aggiungere una subnet dual stack con un intervallo IPv6 su una risorsa Cloud Run, consulta Configura il dual stack.

Limita l'accesso con le regole firewall

Limita l'accesso alle risorse in una rete VPC utilizzando le regole firewall VPC. Aggiungi queste limitazioni utilizzando una delle seguenti strategie:

  • Crea una regola firewall in entrata che faccia riferimento al tuo servizio o job utilizzando l'intervallo IP della subnet.

  • Crea una regola firewall in uscita che faccia riferimento al tuo servizio o al tuo job.

    Nella regola firewall in uscita, fai riferimento al servizio o al job utilizzando l'identità di servizio del account di servizio collegato, l'intervallo IP della subnet o i tag di rete associati.

Tag di rete per il traffico in uscita

Aggiungi un ulteriore livello di sicurezza di rete utilizzando i tag di rete nelle regole firewall in uscita.

Console

Per associare i tag di rete a un servizio o a un job:

  1. Nella console Google Cloud , vai alla pagina Cloud Run.

    Vai a Cloud Run

  2. Fai clic sul servizio o sul job a cui vuoi associare i tag di rete, quindi fai clic su Modifica per i job.

  3. Fai clic sulla scheda Networking per i servizi o sulla scheda Connessioni per i job.

  4. Assicurati di aver selezionato Connettiti a un VPC per il traffico in uscita e Invia il traffico direttamente a un VPC.

  5. Nel campo Subnet, seleziona la subnet da cui il servizio riceve gli indirizzi IP. Puoi eseguire il deployment o l'esecuzione di più servizi o job nella stessa subnet.

  6. Nel campo Tag di rete, inserisci i nomi dei tag di rete che vuoi associare al servizio o al job.

  7. Per i job, fai clic su Aggiorna. Per i servizi, fai clic su Visualizza diff e rifai il deployment, quindi su Esegui il deployment delle modifiche.

Per i servizi, ogni revisione del servizio può avere un insieme diverso di tag di rete, perché i tag di rete vengono specificati a livello di revisione. Per i job, un'esecuzione del job ha gli stessi tag di rete che aveva il job al momento della creazione dell'esecuzione del job.

gcloud

Per associare i tag di rete a un servizio o a un job, utilizza il comando gcloud run deploy:

gcloud run deploy SERVICE_JOB_NAME \
    --image=IMAGE_URL \
    --network=NETWORK \
    --subnet=SUBNET \
    --network-tags=NETWORK_TAG_NAMES \
    --region=REGION

Sostituisci quanto segue:

  • SERVICE_JOB_NAME con il nome del tuo servizio o job.
  • IMAGE_URL con l'URL dell'immagine del servizio o del lavoro.
  • NETWORK con il nome della tua rete VPC.
  • SUBNET con il nome della subnet. Specifica una rete VPC o una subnet oppure entrambe. Se specifichi solo una rete, la subnet utilizza lo stesso nome della rete. Puoi eseguire il deployment o l'esecuzione di più servizi, job, pool di worker o istanze nella stessa subnet.
  • NETWORK_TAG_NAMES con il nome del tag di rete o un elenco separato da virgole di tag di rete.
  • REGION con il nome della tua regione.

Per i servizi, ogni revisione del servizio può avere un insieme diverso di tag di rete, perché i tag di rete vengono specificati a livello di revisione. Per i job, un'esecuzione del job ha gli stessi tag di rete che aveva il job al momento della creazione dell'esecuzione del job.

Scollega una risorsa Cloud Run

A seconda della risorsa Cloud Run di cui disponi, consulta le istruzioni in una delle seguenti sezioni:

Scollega un servizio

Console

  • Per rimuovere il servizio dalla rete VPC:

    1. Vai a Cloud Run

    2. Fai clic sul servizio.

    3. Fai clic sulla scheda Networking.

    4. Deseleziona Connettiti a un VPC per il traffico in uscita.

    5. Fai clic su Visualizza differenze e fai di nuovo il deployment, quindi su Esegui il deployment delle modifiche.

    6. Per verificare che il servizio non sia più nella tua rete VPC, fai clic sulla scheda Networking. La rete e la subnet non sono più elencate nella scheda VPC.

  • Per rimuovere solo i tag di rete mantenendo il servizio connesso alla rete VPC:

    1. Fai clic sul servizio che contiene i tag di rete che vuoi rimuovere.

    2. Fai clic sulla scheda Networking.

    3. Cancella i nomi dei tag di rete che non vuoi più associare al tuo servizio.

    4. Fai clic su Visualizza differenze e fai di nuovo il deployment, quindi su Esegui il deployment delle modifiche.

gcloud

  • Per rimuovere il servizio dalla rete VPC, esegui il seguente comando:

    gcloud run services update SERVICE_NAME --region=REGION \
--clear-network

  • Per rimuovere solo i tag di rete mantenendo il servizio connesso alla rete VPC, esegui questo comando:

    gcloud run services update SERVICE_NAME --region=REGION \
--clear-network-tags

    Sostituisci quanto segue:

    • SERVICE_NAME: il nome del tuo servizio Cloud Run.
    • REGION: la regione del servizio Cloud Run.

YAML

  • Per rimuovere il servizio dalla rete VPC:

    1. Scarica la configurazione YAML del servizio:

      gcloud run services describe SERVICE_NAME --format export > service.yaml

    2. Rimuovi i seguenti contenuti dal file service.yaml:

      run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'

      Dove

      • NETWORK: il nome della tua rete VPC.
      • SUBNET: il nome della subnet.
      • (Facoltativo) NETWORK_TAG_NAMES: i nomi dei tag di rete se li avevi associati a un servizio.

    3. Esegui il deployment della revisione del servizio eseguendo questo comando:

      gcloud run services replace service.yaml

  • Per rimuovere solo i tag di rete mantenendo il servizio connesso alla rete VPC:

    1. Scarica la configurazione YAML del servizio:

      gcloud run services describe SERVICE_NAME --format export > service.yaml

    2. Rimuovi la variabile tags dai contenuti del file service.yaml, lasciando invariate le variabili network e subnetwork, come mostrato nell'esempio seguente:

      run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET"}]'

      Dove

      • NETWORK: il nome della tua rete VPC.
      • SUBNET: il nome della subnet.

    3. Esegui il deployment della revisione del servizio eseguendo questo comando:

      gcloud run services replace service.yaml

Scollega un lavoro

Console

  • Per rimuovere il job dalla rete VPC:

    1. Vai a Cloud Run

    2. Fai clic sul job che vuoi rimuovere, quindi su Modifica ed esegui il deployment di una nuova revisione.

    3. Fai clic sulla scheda Connessioni.

    4. Deseleziona Connettiti a un VPC per il traffico in uscita.

    5. Fai clic su Aggiorna.

    6. Per verificare che il job non sia più nella tua rete VPC, fai clic sulla scheda Configurazione. La rete e la subnet non sono più elencate nella scheda VPC.

  • Per rimuovere solo i tag di rete mantenendo il job connesso alla rete VPC:

    1. Fai clic sul job che contiene i tag di rete da rimuovere, quindi fai clic su Modifica ed esegui il deployment di una nuova revisione.

    2. Fai clic sulla scheda Connessioni.

    3. Cancella i nomi dei tag di rete che non vuoi più associare al job.

    4. Fai clic su Aggiorna.

gcloud

  • Per rimuovere il job dalla rete VPC, esegui questo comando:

    gcloud run jobs update JOB_NAME --region=REGION \
  --clear-network

  • Per rimuovere solo i tag di rete mantenendo il job connesso alla rete VPC, esegui questo comando:

    gcloud run jobs update JOB_NAME --region=REGION \
  --clear-network-tags

    Sostituisci quanto segue:

    • JOB_NAME: il nome del job Cloud Run.
    • REGION: la regione del job Cloud Run.

YAML

  • Per rimuovere il job dalla rete VPC:

    1. Scarica la configurazione YAML del job:

      gcloud run jobs describe JOB_NAME --format export > job.yaml

    2. Rimuovi i seguenti contenuti dal file job.yaml:

      run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'

      Sostituisci quanto segue:

      • NETWORK: il nome della tua rete VPC.
      • SUBNET: il nome della subnet.
      • (Facoltativo) NETWORK_TAG_NAMES con i nomi dei tag di rete se li avevi associati a un job.

    3. Aggiorna il job eseguendo questo comando:

      gcloud run jobs replace job.yaml

  • Per rimuovere solo i tag di rete mantenendo il job connesso alla rete VPC:

    1. Scarica la configurazione YAML del job:

      gcloud run jobs describe JOB_NAME --format export > job.yaml

    2. Rimuovi la variabile tags dai contenuti del file job.yaml, lasciando invariate le variabili network e subnetwork, come mostrato nell'esempio seguente:

      run.googleapis.com/network-interfaces: '[{"network":"NETWORK","subnetwork":"SUBNET"}]'

      Sostituisci quanto segue:

      • NETWORK: il nome della tua rete VPC.
      • SUBNET: il nome della subnet.

    3. Aggiorna il job eseguendo questo comando:

      gcloud run jobs replace job.yaml

Disconnetti un pool di worker

gcloud

  • Per rimuovere il pool di worker dalla rete VPC, esegui questo comando:

    gcloud run worker-pools update WORKER_POOL --region=REGION \
--clear-network

  • Per rimuovere solo i tag di rete mantenendo il pool di worker connesso alla rete VPC, esegui questo comando:

    gcloud run worker-pools update WORKER_POOL --region=REGION \
--clear-network-tags

    Sostituisci quanto segue:

    • WORKER_POOL: il nome del tuo pool di worker Cloud Run.
    • REGION: la regione del pool di worker Cloud Run.

Disconnetti un'istanza

gcloud

  • Per rimuovere l'istanza dalla rete VPC, esegui il seguente comando:

    gcloud beta run instances update INSTANCE_NAME \
  --region=REGION \
  --clear-network

  • Per rimuovere solo i tag di rete mantenendo l'istanza connessa alla rete VPC, esegui questo comando:

    gcloud beta run instances update INSTANCE_NAME \
    --region=REGION \
    --clear-network-tags

    Sostituisci quanto segue:

    • INSTANCE_NAME: il nome dell'istanza Cloud Run.
    • REGION: la regione dell'istanza Cloud Run.

YAML

  • Per rimuovere l'istanza dalla rete VPC:

    1. Scarica la configurazione YAML dell'istanza:

      gcloud beta run instances describe INSTANCE_NAME --format export > instance.yaml

    2. Rimuovi l'annotazione run.googleapis.com/network-interfaces da metadata.annotations nel file instance.yaml.

    3. Aggiorna l'istanza eseguendo questo comando:

      gcloud beta run instances replace instance.yaml

Risoluzione dei problemi

Impossibile eliminare la subnet

Per eliminare una subnet, devi prima eliminare o rifare il deployment di tutte le risorse che la utilizzano. Se Cloud Run utilizza una subnet, disconnetti il servizio o il job servizio, il job, il pool di worker o l'istanza Cloud Run dalla rete VPC o spostalo in un'altra subnet prima di eliminare la subnet.

La subnet VPC diretto in uscita ha esaurito gli indirizzi IPv4

Quando provi a eseguire il deployment, si verifica il seguente errore:

Instance failed to start because of insufficient free IP addresses in the
subnetwork SUBNET_ID when attempting to create an address in the
subnetwork. Please consider moving to a subnetwork with more available IP
addresses.

Se la subnet della rete VPC esaurisce gli indirizzi IPv4, l'evento viene registrato da Cloud Logging. In questo caso, Cloud Run non può avviare altre istanze di servizio o attività di job finché non diventano disponibili altri indirizzi IPv4.

Per risolvere il problema, segui le strategie per l'esaurimento degli indirizzi IP.

Visualizza gli indirizzi IP allocati

Non puoi eliminare manualmente un indirizzo prenotato. Il seguente errore si verifica quando tenti di eliminare un indirizzo IP allocato per Cloud Run:

The address resource 'ADDRESS_NAME' is already being used by
'//serverless.googleapis.com/projects/PROJECT_ID/locations/REGION/addressReservations/ADDRESS_NAME'

Per visualizzare gli indirizzi IP allocati da Cloud Run, vai alla pagina Indirizzi IP nella consoleGoogle Cloud e cerca gli indirizzi in cui la colonna In uso da è impostata su Serverless.

In alternativa, puoi eseguire questo comando da Google Cloud CLI:

gcloud compute addresses list --filter="purpose=SERVERLESS"

Problemi con la MTU personalizzata

Se riscontri problemi con una MTU personalizzata, assicurati di utilizzare l'impostazione MTU predefinita per Cloud Run.