Risolvi i problemi di Cloud Run

Questa pagina descrive come risolvere gli errori che potresti riscontrare durante l'utilizzo di Cloud Run. Personalized Service Health pubblica tutti gli incidenti di Cloud Run derivanti dall'infrastruttura Google Cloud sottostante per identificare le interruzioni del servizio Google Cloud che interessano i tuoi progetti. Ti consigliamo anche di configurare avvisi sugli eventi di Personalized Service Health. Per informazioni sugli incidenti che interessano tutti Google Cloud i servizi, consulta la dashboard Google Cloud Service Health.

Verifica la presenza di problemi esistenti o aprine di nuovi negli Issue Tracker pubblici.

Per altri messaggi di errore non elencati in questa pagina, consulta Problemi noti in Cloud Run. Se continui a riscontrare errori anche dopo aver seguito i passaggi di questa guida, contatta l'assistenza.

Consulta le sezioni seguenti per indicazioni su come risolvere i problemi in Cloud Run:

Errori di deployment

Questa sezione descrive gli errori di deployment comuni in Cloud Run e i metodi per risolverli.

Impossibile avviare il container

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

Container failed to start. Failed to start and then listen on the port defined by the PORT environment variable.

Per risolvere il problema, segui questi passaggi:

  1. Verifica di poter eseguire l'immagine container localmente. Se l'immagine container non può essere eseguita localmente, devi diagnosticare e risolvere il problema localmente.

  2. Controlla se il container è in attesa di richieste sulla porta corretta. Il tuo container deve eseguire le operazioni di ascolto delle richieste in entrata sulla porta definita da Cloud Run e fornita nella variabile di ambiente PORT. Per istruzioni su come specificare la porta,consulta Configurazione dei container per i servizi.

  3. Controlla se il container è in ascolto su tutte le interfacce di rete, in genere indicate come 0.0.0.0. In particolare, il container non deve rimanere in ascolto su 127.0.0.1.

  4. Verifica che l'immagine container sia compilata per Linux a 64 bit come richiesto dal contratto di runtime del container.

  5. Utilizza Cloud Logging per cercare errori dell'applicazione nei log di stdout o stderr. Puoi anche cercare arresti anomali acquisiti in Error Reporting.

    Potresti dover aggiornare il codice o le impostazioni di revisione per correggere errori o arresti anomali. Puoi anche risolvere i problemi del servizio a livello locale.

Errore di importazione del contenitore

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

The service has encountered an error during container import. Please try again later. Resource readiness deadline exceeded.

Per risolvere il problema, segui questi passaggi:

  1. Assicurati che il file system del contenitore non contenga caratteri non UTF-8.

  2. Alcune immagini Docker basate su Windows utilizzano livelli esterni. Il control plane di Cloud Run non supporta i livelli esterni. Per risolvere il problema, prova a impostare il flag --allow-nondistributable-artifacts nel daemon Docker.

La funzionalità non è supportata

Quando chiami l'API Cloud Run Admin, si verifica il seguente errore:

The feature is not supported in the declared launch stage

Questo errore si verifica quando chiami direttamente l'API Cloud Run Admin e utilizzi una funzionalità beta senza specificare un campo o un'annotazione della fase di lancio.

Per risolvere il problema, aggiungi il campo della fase di lancio alle richieste.

Fai riferimento agli esempi riportati di seguito per aggiungere riferimenti alla fase di lancio quando utilizzi l'API REST v1 o v2:

  • Aggiunta dell'annotazione della fase di lancio a una richiesta client utilizzando JSON e l'API REST v1:

      "annotations": {
    "run.googleapis.com/launch-stage": "BETA"
  }

  • Riferimento LaunchStage a una richiesta client che utilizza JSON e l'API REST v2:

    "launchStage": "BETA"

  • Aggiunta dell'annotazione della fase di lancio a una richiesta di servizio utilizzando YAML e l'API REST v1:

    kind: Service
metadata:
annotations:
  run.googleapis.com/launch-stage: BETA

L'utente root non è stato trovato

Si verifica il seguente errore quando le chiavi di crittografia gestite dal cliente vengono specificate utilizzando un parametro --key:

ERROR: "User \"root\""not found in /etc/passwd

Per risolvere il problema, specifica USER 0 anziché USER root nel Dockerfile.

L'account di servizio Compute Engine predefinito viene eliminato

Durante il deployment si verifica il seguente errore:

ERROR: (gcloud.run.deploy) User EMAIL_ADDRESS does not have permission to access namespace NAMESPACE_NAME (or it may not exist): Permission 'iam.serviceaccounts.actAs' denied on service account PROJECT_NUMBER-compute@developer.gserviceaccount.com (or it may not exist).

Questo problema si verifica in uno dei seguenti scenari:

  • Il service account Compute Engine predefinito non esiste nel progetto e non viene specificato un account di servizio con il flag --service-account al momento del deployment.

  • Lo sviluppatore o il principal che esegue il deployment del servizio non dispone delle autorizzazioni richieste per il deployment dell'account di servizio Compute Engine predefinito.

Per risolvere il problema:

  1. Specifica un account di servizio utilizzando il flag --service-account:

    gcloud run services update SERVICE_NAME --service-account SERVICE_ACCOUNT

  2. Verifica che il account di servizio specificato disponga delle autorizzazioni necessarie per il deployment.

Per verificare se l'agente di servizio Compute Engine predefinito esiste nel tuo progetto Google Cloud :

  1. Nella console Google Cloud , vai alla pagina Autorizzazioni di Identity and Access Management:

    Vai ad Autorizzazioni

  2. Seleziona la casella di controllo Includi concessioni di ruoli fornite da Google.

  3. Nell'elenco Entità, individua l'ID dell'agente di servizio Compute Engine, che segue il formato PROJECT_NUMBER-compute@developer.gserviceaccount.com.

Problemi con il account di servizio Cloud Build

Si verifica il seguente errore durante i deployment delle origini quando il account di servizio Cloud Build non dispone delle autorizzazioni richieste o è disattivato:

ERROR: (gcloud.run.deploy) NOT_FOUND: Build failed. The service has encountered an internal error. Please try again later. This command is authenticated as EMAIL_ADDRESS which is the active account specified by the [core/account] property.

Cloud Build ha modificato il comportamento predefinito di utilizzo degli account di servizio nei nuovi progetti. Questo è descritto in dettaglio nella sezione Modifica dell'account di servizio predefinito di Cloud Build. A seguito di questa modifica, i nuovi progetti che eseguono il deployment su Cloud Run dal codice sorgente per la prima volta potrebbero utilizzare un account di servizio Cloud Build predefinito con autorizzazioni insufficienti per il deployment dall'origine.

Per risolvere il problema, segui questi passaggi:

  • Consulta le indicazioni di Cloud Build sulle modifiche all'account di servizio predefinito e disattiva queste modifiche.

  • Concedi il ruolo Cloud Run Builder (roles/run.builder) alaccount di serviziot di build.

L'agente di servizio Cloud Run non dispone dell'autorizzazione per leggere l'immagine

Il seguente errore si verifica quando tenti di eseguire il deployment da un progetto utilizzando un'immagine archiviata in Artifact Registry, utilizzando il dominio gcr.io in un progetto diverso:

Google Cloud Run Service Agent must have permission to read the image, gcr.io/PROJECT-ID/IMAGE-NAME. Ensure that the provided container image URL is correct and that above account has permission to access the image. If you just enabled the Cloud Run API, the permissions might take a few minutes to propagate. Note that PROJECT-ID/IMAGE-NAME is not in project PROJECT-ID-2. Permission must be granted to the Google Cloud Run Service Agent from this project.

Potresti anche visualizzare il seguente errore quando provi a eseguire il deployment da un progetto utilizzando un'immagine archiviata in Artifact Registry in un progetto diverso:

ERROR: (gcloud.run.deploy) PERMISSION_DENIED: User must have permission to read
the image, REGION.pkg.dev/PROJECT_ID/ARTIFACT_REGISTRY_REPO/IMAGE:latest. Ensure that the provided container image URL is correct
and that the above account has permission to access the image. If you just enabled
the Cloud Run API, the permissions might take a few minutes to propagate. Note
that the image is from project PROJECT_ID, which is not the same as
this project PROJECT_ID.

Per risolvere il problema, segui questi consigli per la risoluzione dei problemi:

  • Segui le istruzioni per il deployment di immagini container da altri Google Cloud progetti per assicurarti che le tue entità dispongano delle autorizzazioni necessarie.

  • Questo problema può verificarsi anche se il progetto si trova in un perimetro Controlli di servizio VPC con una limitazione dell'API Cloud Storage che vieta le richieste dell'agente di servizio Cloud Run. Per risolvere il problema:

    1. Apri Esplora log nella console Google Cloud . (Non utilizzare la pagina Log all'interno della pagina Cloud Run):

      Vai a Esplora log

    2. Inserisci il seguente testo nel campo della query:

      protoPayload.@type="type.googleapis.com/google.cloud.audit.AuditLog"
severity=ERROR
protoPayload.status.details.violations.type="VPC_SERVICE_CONTROLS"
protoPayload.authenticationInfo.principalEmail="service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com"

    3. Se visualizzi voci di log dopo aver utilizzato questa query, esaminale per determinare se devi aggiornare i criteri di Controlli di servizio VPC. Potrebbero indicare che devi aggiungere service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com a una policy di accesso preesistente.

Autorizzazioni mancanti per i deployment delle origini

Quando esegui il deployment dall'origine, potrebbero verificarsi i seguenti errori:

ERROR: (gcloud.run.deploy) EMAIL_ADDRESS does not have permission
to access namespaces instance PROJECT_ID (or it may not exist): Google
Cloud Run Service Agent does not have permission to get access tokens for
the service account SERVICE_ACCOUNT. Please give SERVICE_ACCOUNT
permission iam.serviceAccounts.getAccessToken on the service account.

Alternatively, if the service account is unspecified or in the same project you
are deploying in, ensure that the Service Agent is assigned the Google
Cloud Run Service Agent role roles/run.serviceAgent. This
command is authenticated as EMAIL_ADDRESS, which is the active account
specified by the [core/account] property.

Ogni servizio Cloud Run è associato a un account di servizio che funge da identità quando il servizio accede ad altre risorse. Questo account di servizio potrebbe essere il account di servizio predefinito (PROJECT_NUMBER-compute@developer.gserviceaccount.com) o un account di servizio gestito dall'utente.

Negli ambienti in cui più servizi accedono a risorse diverse, puoi utilizzare identità per servizio con service account gestiti dall'utente diversi anziché il account di servizio predefinito.

Per risolvere il problema, concedi all'account di deployment il ruolo Utente service account (roles/iam.serviceAccountUser) nel account di servizio utilizzato come identità del servizio. Questo ruolo predefinito contiene l'autorizzazione iam.serviceAccounts.actAs, necessaria per collegare un account di servizio al servizio o alla revisione. A un utente che crea un account di servizio gestito dall'utente viene concessa automaticamente l'autorizzazione iam.serviceAccounts.actAs, tuttavia, gli altri autori del deployment devono disporre di questa autorizzazione concessa dall'utente che crea il account di servizio gestito dall'utente.

Per ulteriori informazioni sui requisiti di accesso per i nuovi service account che crei, consulta Ricevere consigli per creare service account dedicati.

L'utente non dispone di autorizzazioni sufficienti per completare i deployment delle origini

Il seguente errore si verifica quando l'account del deployment non dispone delle autorizzazioni richieste per il tuo progetto:

ERROR: (gcloud.run.deploy) 403 Could not upload file EMAIL_ADDRESS does
not have storage.objects.create access to the Google Cloud Storage object. Permission storage.objects.create denied on resource (or it may not exist). This
command is authenticated as EMAIL_ADDRESS which is the active account.

Per risolvere questo errore, chiedi all'amministratore di concederti i seguenti ruoli Identity and Access Management:

Errore durante il deployment di un servizio Cloud Run da altri progetti Google Cloud

Il seguente errore si verifica quando esegui il deployment di un servizio Cloud Run da un progetto di origine a un progetto di destinazione:

Failed to create service.
Operation failed due to missing permissions.

Google Cloud Run Service Agent does not have permission to get access
tokens for the service account SERVICE_ACCOUNT. Please give
SERVICE_ACCOUNT permission iam.serviceAccounts.getAccessToken
on the service account. Alternatively, if the service account is unspecified or
in the same project you are deploying in, ensure that the Service Agent is
assigned the Google Cloud Run Service Agent role roles/run.serviceAgent.

Per risolvere il problema, segui questi passaggi:

  1. Concedi il ruolo Utente service account (roles/iam.serviceAccountUser) nel account di servizio che utilizzi come identità di servizio nel progetto di destinazione.

  2. Concedi il ruolo Creatore token account di servizio (roles/iam.serviceAccountTokenCreator) al service account Cloud Run nel progetto di destinazione. Aggiungi l'email dell'agente di servizio Cloud Run (service-PROJECT_NUMBER@SERVICE_DOMAIN.iam.gserviceaccount.com) come entità del progetto di origine.

  3. Disattiva il criterio dell'organizzazione iam.disableCrossProjectServiceAccountUsage.

Per istruzioni dettagliate, vedi Configurare l'identità del servizio per i servizi.

Errori durante il deployment del codice sorgente Python in Cloud Run

Quando esegui il deployment di un servizio Cloud Run dal codice sorgente con il runtime Python, si verifica uno dei seguenti errori:

  • Revision REVISION_NAME is not ready and cannot serve traffic.
The user provided container failed to start and listen on port defined by PORT=8080
environment variable within the allocated timeout. This can happen if the port is
misconfigured or if the timeout is too short. The healthcheck timeout can be extended.
  • Il deployment viene eseguito correttamente con i codici di errore HTTP 500 nei log.

Il buildpack Python imposta il punto di ingresso predefinito per i deployment di origine Cloud Run. Per Python versione 3.13 e successive, il buildpack Python imposta il punto di ingresso in base alla configurazione del servizio web nel file requirements.txt. Se non specifichi un server web o un framework nel file requirements.txt o utilizzi Python versione 3.12 e precedenti, il buildpack Python imposta il punto di ingresso predefinito su gunicorn -b :8080 main:app. Per saperne di più, consulta la sezione Creazione di un'applicazione Python.

Puoi risolvere il problema in diversi modi. Ad esempio, puoi specificare uno dei seguenti server web nel file requirements.txt:

  • gunicorn:

      # https://pypi.org/project/gunicorn/
  gunicorn==21.2.0

  • fastapi e uvicorn:

    
# https://pypi.org/project/fastapi
fastapi[standard]==0.116.1

# https://pypi.org/project/uvicorn
uvicorn==0.35.0

In alternativa, puoi seguire uno di questi passaggi per risolvere gli errori di deployment:

  • Specifica il punto di ingresso eseguendo il seguente comando di deployment dell'origine:

    gcloud run deploy SERVICE --source .  --set-build-env-vars GOOGLE_ENTRYPOINT="ENTRYPOINT"

    Sostituisci quanto segue:

    • SERVICE: il nome del servizio di cui vuoi eseguire il deployment.
    • ENTRYPOINT: il punto di ingresso predefinito che vuoi utilizzare per il codice sorgente.

  • Utilizza un Procfile per impostare un punto di ingresso.

Errori di pubblicazione

Questa sezione elenca i problemi che potresti riscontrare con la pubblicazione e fornisce suggerimenti su come risolverli.

HTTP 404: Non trovato

Durante la pubblicazione si verifica il seguente problema:

`HTTP 404`:Not found

Potresti riscontrare errori HTTP 404 nei seguenti scenari:

  1. Un URL di richiesta o un codice applicazione errati restituiscono errori 404. Per risolvere il problema, segui questi passaggi:

    1. Verifica che l'URL richiesto sia corretto. Puoi verificare l'URL nella pagina dei dettagli del servizio nella console Google Cloud o eseguendo il seguente comando:

      gcloud run services describe SERVICE_NAME | grep URL

    2. Controlla dove la tua app restituisce i codici di errore 404. Se la tua app restituisce 404, puoi trovarlo in Cloud Logging. Inoltre, verifica che l'app non restituisca un codice di errore 404 quando la esegui localmente.

    3. Assicurati che l'app non inizi ad ascoltare sulla porta configurata prima di essere pronta a ricevere richieste.

  2. La richiesta non raggiunge il container, il che comporta un errore 404 nei seguenti scenari:

    • Una richiesta non soddisfa la restrizione di rete specificata, in particolare quando le impostazioni di traffico in entrata del servizio Cloud Run sono impostate su Interno o Interno e bilanciamento del carico cloud.

    • L'URL run.app predefinito del servizio Cloud Run è disattivato e un client tenta di raggiungere il servizio a quell'URL run.app.

    In entrambi gli scenari, non riesci a trovare l'errore 404 in Cloud Logging, anche quando applichi il seguente filtro:

    resource.type="cloud_run_revision"
log_name="projects/PROJECT_ID/logs/run.googleapis.com%2Frequests"
httpRequest.status=404

  3. Con le stesse impostazioni di Ingress, la richiesta potrebbe essere bloccata da Controlli di servizio VPCs in base al contesto del chiamante, inclusi progetto e indirizzo IP. Per verificare la violazione di un criterio per i controlli di servizio VPC:

    1. Apri Esplora log nella console Google Cloud :

      Vai a Esplora log

    2. Inserisci il seguente testo nel campo della query:

      resource.type="audited_resource"
log_name="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fpolicy"
resource.labels.method="run.googleapis.com/HttpIngress"

    3. Se visualizzi voci di log dopo aver utilizzato questa query, esaminale per determinare se devi aggiornare o meno i criteri di Controlli di servizio VPC.

  4. Accedi all'endpoint del servizio con un bilanciatore del carico utilizzando il runtime Python. Per risolvere il problema, verifica la maschera URL del bilanciatore del carico e assicurati che il percorso URL specificato per il bilanciatore del carico corrisponda al percorso nel codice sorgente Python.

Nessuna istanza di container disponibile

Durante la pubblicazione si verifica il seguente errore:

HTTP 429
The request was aborted because there was no available instance.
The Cloud Run service might have reached its maximum container instance
limit or the service was otherwise not able to scale to incoming requests.
This might be caused by a sudden increase in traffic, a long container startup time or a long request processing time.

Per risolvere il problema, controlla la metrica Conteggio istanze container per il tuo servizio e valuta la possibilità di aumentare questo limite se il tuo utilizzo si sta avvicinando al massimo. Per saperne di più, consulta Imposta il numero massimo di istanze per i servizi e, se hai bisogno di più istanze, richiedi un aumento della quota.

Cloud Run non è riuscito a gestire la velocità del traffico

Il seguente errore si verifica durante la pubblicazione o quando il servizio non ha raggiunto il limite massimo di istanze container:

HTTP 500
The request was aborted because there was no available instance

Per risolvere il problema, segui questi passaggi:

  1. Affronta le seguenti possibili cause principali:

    • Un improvviso e notevole aumento del traffico.
    • Un tempo di avvio a freddo lungo.
    • Un lungo tempo di elaborazione delle richieste o un improvviso aumento del tempo di elaborazione delle richieste.
    • Il servizio ha raggiunto il limite massimo di istanze di container (HTTP 429).
    • Fattori transitori attribuiti al servizio Cloud Run.

  2. Implementa il backoff esponenziale e i tentativi per le richieste che il client non deve interrompere. Un aumento breve e improvviso del traffico o del tempo di elaborazione delle richieste potrebbe essere visibile in Cloud Monitoring solo se aumenti lo zoom fino a una risoluzione di 10 secondi.

  3. Quando la causa principale del problema è un periodo di errori temporanei attribuibili esclusivamente a Cloud Run, contatta l'assistenza.

L'operazione non è implementata

Il seguente errore si verifica quando specifichi un REGION errato durante l'invocazione del job Cloud Run, ad esempio quando esegui il deployment di un job nella regione asia-southeast1 e lo invochi utilizzando southeast1-asia o asia-southeast:

HTTP 501
Operation is not implemented, or supported, or enabled.

Per l'elenco delle regioni supportate, vedi Località di Cloud Run.

Credenziali predefinite non trovate

Il seguente errore si verifica quando l'applicazione non viene autenticata correttamente a causa di file mancanti, percorsi delle credenziali non validi o assegnazioni di variabili di ambiente errate:

HTTP 503: System.InvalidOperationException System.InvalidOperationException your Default
credentials were not found.

Per risolvere il problema:

  1. Installa e inizializza gcloud CLI.

  2. Configura le Credenziali predefinite dell'applicazione (ADC) con le credenziali associate al tuo Account Google. Configura ADC utilizzando:

      gcloud auth application-default login

    Viene visualizzata una schermata di accesso. Dopo aver eseguito l'accesso, le tue credenziali vengono archiviate nel file delle credenziali locali, utilizzato da ADC.

  3. Utilizza la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS per fornire la posizione di un file JSON delle credenziali all'interno del tuo progetto Google Cloud .

    Per maggiori informazioni, vedi Configurare le credenziali predefinite dell'applicazione.

Le istanze di container superano i limiti di memoria

Durante la pubblicazione in Cloud Logging si verifica il seguente errore HTTP 500 o HTTP 503:

While handling this request, the container instance was found to be using too much memory and was terminated. This is likely to cause a new container instance to be used for the next request to this revision. If you see this message frequently, you may have a memory leak in your code or may need more memory. Consider creating a new revision with more memory.

Per risolvere il problema:

  1. Determina se le istanze container superano la memoria disponibile. Cerca errori correlati nei log varlog/system.
  2. Se le istanze superano la memoria disponibile, valuta la possibilità di aumentare il limite di memoria.

In Cloud Run, i file scritti nel file system locale vengono conteggiati ai fini della memoria disponibile. Sono inclusi anche i file di log scritti in posizioni diverse da /var/log/* e /dev/log.

Impossibile elaborare alcune richieste a causa dell'impostazione di concorrenza elevata

Si verifica il seguente errore quando le istanze container utilizzano un carico della CPU elevato per elaborare le richieste e, di conseguenza, non sono in grado di elaborare tutte le richieste:

HTTP 503
The Cloud Run service probably has reached its maximum container instance limit. Consider increasing this limit.

Per risolvere il problema, segui questi passaggi:

  1. Aumenta il numero massimo di istanze di container per il tuo servizio.

  2. Riduci la concorrenza del servizio. Per saperne di più, consulta Impostare il numero massimo di richieste in parallelo per istanza.

Errori di Cloud Logging relativi agli annullamenti delle richieste di coda in attesa

Quando Cloud Run non riesce a scalare abbastanza rapidamente per gestire il traffico, si verifica uno dei seguenti errori:

  • The request was aborted because there was no available instance:
severity=WARNING ( Response code: 429 ) Cloud Run cannot
scale due to the max-instances limit you set
during configuration.

  • severity=ERROR ( Response code: 500 ) Cloud Run intrinsically
cannot manage the rate of traffic.

Per risolvere il problema, segui questi passaggi:

  1. Risolvi le cause principali che potrebbero causare errori di scalabilità, ad esempio:

    • Un improvviso e notevole aumento del traffico.
    • Tempo di avvio a freddo lungo.
    • Tempi di elaborazione delle richieste lunghi.
    • Tasso di errori elevato nel codice sorgente.
    • Raggiungimento del limite massimo di istanze e impedimento della scalabilità del sistema.
    • Fattori transitori attribuiti al servizio Cloud Run.

    Per ulteriori informazioni sulla risoluzione dei problemi di scalabilità e sull'ottimizzazione delle prestazioni, consulta Suggerimenti generali per lo sviluppo.

  2. Per i servizi o le funzioni basati su trigger HTTP, il client deve implementare il backoff esponenziale e i tentativi per le richieste che non devono essere eliminate. Se attivi servizi da Workflows, puoi utilizzare la sintassi try/retry per farlo.

  3. Per i servizi o le funzioni in background o basati su eventi, Cloud Run supporta la consegna at-least-once. Anche senza abilitare esplicitamente i tentativi, Cloud Run ripete automaticamente la pubblicazione dell'evento e riprova l'esecuzione. Per saperne di più, consulta Nuovo tentativo per le funzioni basate su eventi.

  4. Per i problemi relativi agli avvii a freddo, configura il numero minimo di istanze per ridurre il numero di avvii a freddo con un'implicazione di fatturazione più elevata.

  5. Se la causa principale del problema è un periodo di errori temporanei più frequenti attribuibili esclusivamente a Cloud Run o se hai bisogno di assistenza per il tuo problema, contatta l'assistenza.

Firma del token di identità oscurata da Google

Durante le fasi di sviluppo e test si verifica il seguente errore:

SIGNATURE_REMOVED_BY_GOOGLE

Questo errore può verificarsi nei seguenti scenari:

  • L'utente esegue l'accesso utilizzando Google Cloud CLI o Cloud Shell.

  • L'utente genera un token ID utilizzando i comandi gcloud.

  • L'utente tenta di utilizzare il token ID per richiamare un servizio Cloud Run non pubblico.

Questo è il comportamento predefinito previsto. Google rimuove la firma del token per motivi di sicurezza per impedire a qualsiasi servizio Cloud Run non pubblico di riprodurre i token ID generati in questo modo.

Per risolvere il problema, richiama il tuo servizio privato con un nuovo token ID. Per ulteriori informazioni, consulta Testare il servizio privato.

Avviso OpenBLAS nei log

Se utilizzi librerie basate su OpenBLAS come NumPy con l'ambiente di esecuzione di prima generazione, potresti visualizzare il seguente avviso nei log:

OpenBLAS WARNING - could not determine the L2 cache size on this system,
assuming 256k`

L'avviso OpenBLAS si verifica quando il sandbox del contenitore utilizzato dall'ambiente di esecuzione di prima generazione non espone funzionalità hardware di basso livello. Questo avviso non influisce sul tuo servizio. Per evitare voci di log di avvisi OpenBLAS, passa all'ambiente di esecuzione di seconda generazione.

Spark non riesce a ottenere l'indirizzo IP della macchina a cui eseguire il binding

Quando Spark non riesce a ottenere l'indirizzo IP della macchina di binding, si verifica uno dei seguenti errori:

assertion failed: Expected hostname (not IP) but got <IPv6 ADDRESS>
 
assertion failed: Expected hostname or IPv6 IP enclosed in [] but got <IPv6 ADDRESS>

Per risolvere il problema, imposta la variabile di ambiente SPARK_LOCAL_IP su 127.0.0.1 nel Dockerfile, ad esempio ENV SPARK_LOCAL_IP="127.0.0.1". Se non imposti la variabile di ambiente SPARK_LOCAL_IP, il valore predefinito è la controparte IPv6 anziché localhost. Inoltre, Spark non riconosce la variabile di ambiente impostata come RUN export SPARK_LOCAL_IP="127.0.0.1".

Impossibile accedere ai file utilizzando NFS

Errore Rimedio suggerito
mount.nfs: Protocol not supported In alcune immagini di base, come debian e adoptopenjdk/openjdk11, manca la dipendenza nfs-kernel-server.
mount.nfs: Connection timed out Se la connessione scade, assicurati di fornire l'indirizzo IP corretto dell'istanza filestore.
mount.nfs: access denied by server while mounting IP_ADDRESS:/FILESHARE Se l'accesso è stato negato dal server, assicurati che il nome della condivisione file sia corretto.

Impossibile accedere ai file utilizzando Cloud Storage FUSE

Consulta la guida alla risoluzione dei problemi di Cloud Storage FUSE.

Latenza elevata quando l'utilizzo della CPU è basso

Il tuo servizio potrebbe riscontrare latenze elevate delle richieste o non riuscire a scalare sotto carico, anche se Cloud Monitoring mostra che l'utilizzo medio della CPU è ben al di sotto del target di scalabilità tipico del 60%.

Possibile causa:

Ciò potrebbe verificarsi se la tua applicazione è single-thread per le attività CPU-bound, ma viene eseguita il deployment su un'istanza con più vCPU. La tua applicazione potrebbe utilizzare al massimo un core vCPU, mentre gli altri core rimangono per lo più inattivi. Il gestore della scalabilità automatica di Cloud Run utilizza l'utilizzo medio della CPU in tutte le vCPU; questa media potrebbe essere bassa in questi casi, il che impedisce lo scaling basato sulla CPU.

Soluzioni:

  • Per le applicazioni a thread singolo:
    • Se i requisiti di memoria possono essere soddisfatti, preferisci configurare il servizio con 1 vCPU (vedi Limiti di memoria e minimi di CPU). In questo modo, le metriche di utilizzo della CPU riflettono con precisione il carico.
    • Se sono necessarie più vCPU a causa di esigenze di memoria elevate che superano i limiti di 1 vCPU, la scalabilità automatica basata sulla CPU sarà probabilmente meno efficace. In questo scenario, riduci l'impostazione di concorrenza massima per favorire lo scaling più rapido in base alla velocità effettiva delle richieste. Consulta la sezione Configurazione della concorrenza.
  • Per le configurazioni con più vCPU: assicurati che la tua applicazione sia progettata per utilizzare in modo efficace tutte le vCPU allocate (ad esempio, utilizzando più processi o thread di lavoro).

Errori di connettività e sicurezza

Questa sezione descrive gli errori comuni di connettività e sicurezza in Cloud Run e i metodi per risolverli.

Il client non è autenticato correttamente

Durante la pubblicazione si verifica il seguente errore:

HTTP 401: The request was not authorized to invoke this service

Per risolvere il problema:

  1. Se un service account richiama il tuo servizio Cloud Run, imposta l'attestazione audience (aud) del token ID firmato da Google su:

    • Se imposti aud sull'URL del servizio di ricezione utilizzando il formato https://SERVICE.run.app o https://REGION-PROJECT_ID.cloudfunctions.net/FUNCTION, il tuo servizio deve richiedere l'autenticazione. Richiama il servizio Cloud Run utilizzando l'URL Cloud Run o tramite un URL del bilanciatore del carico. Per esempi sull'invio di richieste autenticate, vedi Richiamare un servizio con una richiesta HTTPS.

    • Se imposti aud sull'ID client di un ID client OAuth 2.0 di tipo Applicazione web, utilizzando il formato nnn-xyz.apps.googleusercontent.com, puoi richiamare il servizio Cloud Run tramite un bilanciatore del carico HTTPS protetto da IAP. Consigliamo questo approccio per un bilanciatore del carico delle applicazioni supportato da più servizi Cloud Run in diverse regioni.

    • Se imposti aud su un segmento di pubblico personalizzato configurato, utilizza i valori esatti forniti. Ad esempio, se il segmento di pubblico personalizzato è https://service.example.com, anche il valore dell'attributo del pubblico deve essere https://service.example.com.

  2. Assicurati che le richieste includano un'intestazione Authorization: Bearer ID_TOKEN o un'intestazione X-Serverless-Authorization: Bearer ID_TOKEN per l'autorizzazione personalizzata e che il token sia un token ID, non un token di accesso o di aggiornamento. Un errore 401 potrebbe verificarsi nei seguenti scenari a causa di un formato di autorizzazione errato:

    • Il token di autorizzazione utilizza un formato non valido.

    • L'intestazione di autorizzazione non è un token JWT (JSON Web Token) con una firma valida.

    • L'intestazione di autorizzazione contiene più JWT.

    • Nella richiesta sono presenti più intestazioni di autorizzazione.

    Per controllare le rivendicazioni su un JWT, utilizza lo strumento jwt.io.

  3. Se ricevi token non validi quando utilizzi il server di metadati per recuperare token ID e di accesso per autenticare le richieste con l'identità del servizio o del job Cloud Run con un proxy HTTP per instradare il traffico in uscita, aggiungi i seguenti host alle eccezioni del proxy HTTP:

    • 169.254.* o 169.254.0.0/16

    • *.google.internal

  4. Un errore 401 si verifica comunemente quando le librerie client Cloud utilizzano il server di metadati per recuperare le credenziali predefinite dell'applicazione per autenticare le chiamate REST o gRPC. Se non definisci le eccezioni del proxy HTTP, si verifica il seguente comportamento:

    • Se diversi Google Cloud carichi di lavoro ospitano un servizio o un job Cloud Run e il proxy HTTP, anche se le librerie client Cloud recuperano le credenziali, l'account di servizio assegnato al carico di lavoro del proxy HTTP genera i token. I token potrebbero non disporre delle autorizzazioni necessarie per eseguire le operazioni API Google Cloud previste. Questo perché il account di servizio recupera i token dalla visualizzazione del server di metadati del carico di lavoro del proxy HTTP, anziché dal servizio o dal job Cloud Run.

    • Se il proxy HTTP non è ospitato in Google Cloude instradi le richieste del server di metadati utilizzando il proxy, le richieste di token non vanno a buon fine e le operazioni delle APIGoogle Cloud non vengono autenticate.

  5. Esegui nuovamente il deployment del servizio per consentire l'accesso pubblico se questa operazione è supportata dalla tua organizzazione. Questa opzione è utile per i test.

Il client non è autorizzato a richiamare il servizio

Si verifica uno dei seguenti errori durante la chiamata del servizio:

HTTP 403: The request was not authenticated. Either allow public access or set the proper Authorization header
 
HTTP 403: Forbidden: Your client does not have permission to get URL from this server.

Potrebbe verificarsi un errore 403 quando il membro IAM utilizzato per generare il token di autorizzazione non dispone dell'autorizzazione run.routes.invoke. Concedi questa autorizzazione all'utente che genera il token.

Inoltre, se in Cloud Logging è presente una voce per l'errore con il formato resource.type = "cloud_run_revision", segui questi passaggi per risolverlo:

  1. Per rendere il servizio richiamabile da chiunque, aggiorna le impostazioni IAM e rendi pubblico il servizio.

  2. Per rendere il tuo servizio richiamabile solo da determinate identità, richiama il servizio con il token di autorizzazione appropriato:

    • Se un developer o un utente finale richiama il tuo servizio, concedi l'autorizzazione run.routes.invoke. Puoi fornire questa autorizzazione tramite i ruoli Amministratore di Cloud Run (roles/run.admin) e Invoker di Cloud Run (roles/run.invoker).

    • Se un service account richiama il tuo servizio, assicurati che il account di servizio sia membro del servizio Cloud Run e concedi il ruolo Invoker Cloud Run (roles/run.invoker).

    • Le chiamate a cui manca un token di autenticazione potrebbero causare l'errore 403. Se le chiamate con un token di autenticazione valido continuano a generare l'errore 403, concedi all'utente IAM che genera il token l'autorizzazione run.routes.invoke.

Quando si verifica un errore 403 e non si trova la voce di log resource.type = "cloud_run_revision", il problema potrebbe essere dovuto ai Controlli di servizio VPC che bloccano un servizio Cloud Run con impostazioni di traffico in entrata configurate su All. Per ulteriori informazioni sulla risoluzione dei problemi relativi ai rifiuti dei Controlli di servizio VPC, consulta Errori 404.

Errore durante l'accesso al servizio da un browser web

Si verifica il seguente problema quando accedi a un servizio Cloud Run da un browser web:

403 Forbidden
Your client does not have permission to get URL from this server.

Quando richiami un servizio Cloud Run da un browser web, il browser invia una richiesta GET al servizio. Tuttavia, la richiesta non contiene il token di autorizzazione dell'utente chiamante. Per risolvere il problema, segui questi passaggi:

  1. Utilizza Identity-Aware Proxy (IAP) con Cloud Run. IAP consente di definire un livello di autorizzazione centrale per le applicazioni a cui si accede tramite HTTPS. Con IAP, puoi utilizzare un modello dicontrollo dell'accessoo a livello di applicazione invece di firewall a livello di rete. Per ulteriori dettagli sulla configurazione di Cloud Run con IAP, consulta Abilitazione di Identity-Aware Proxy per Cloud Run.

  2. Come soluzione alternativa temporanea, accedi al servizio tramite un browser web utilizzando il proxy Cloud Run in Google Cloud CLI. Per eseguire il proxy di un servizio localmente, esegui questo comando:

    gcloud run services proxy SERVICE --project PROJECT-ID

    Cloud Run esegue il proxy del servizio privato su http://localhost:8080 (o sulla porta specificata con --port), fornendo il token dell'account attivo o un altro token specificato. Questo è il modo consigliato per testare privatamente un sito web o un'API nel browser. Per saperne di più, consulta Testare i servizi privati.

  3. Consenti l'accesso pubblico al tuo servizio. È utile per i test o quando il servizio è un'API o un sito web pubblici.

Connessione ripristinata dal peer

Si verifica uno dei seguenti errori quando un peer della rete chiude inaspettatamente la connessione TCP stabilita dall'applicazione:

Connection reset by peer
 
asyncpg.exceptions.ConnectionDoesNotExistError: connection was closed in the middle of operation
 
grpc.StatusRuntimeException: UNAVAILABLE: io exception
 
psycopg.OperationalError: the connection is closed
 
ECONNRESET

Per risolvere il problema, segui questi passaggi:

  • Se stai tentando di eseguire operazioni in background con la limitazione della CPU, utilizza l'impostazione di fatturazione basata sull'istanza.

  • Assicurati di rispettare i timeout delle richieste in uscita. Se la tua applicazione mantiene una connessione in stato di inattività oltre questa soglia, il gateway deve interrompere la connessione.

  • Per impostazione predefinita, l'opzione socket TCP keepalive è disabilitata per Cloud Run. Non esiste un modo diretto per configurare l'opzione keepalive a livello di servizio. Per attivare l'opzione keepalive per ogni connessione socket, fornisci le opzioni socket richieste quando apri una nuova connessione socket TCP, a seconda della libreria client che utilizzi per questa connessione nella tua applicazione.

  • Di tanto in tanto, le connessioni in uscita vengono ripristinate a causa di aggiornamenti dell'infrastruttura. Se la tua applicazione riutilizza connessioni di lunga durata, ti consigliamo di configurarla in modo da ristabilire le connessioni per evitare il riutilizzo di una connessione non più attiva.

  • Se utilizzi un proxy HTTP per instradare il traffico in uscita dei servizi o dei job Cloud Run e il proxy applica una durata massima della connessione, il proxy potrebbe eliminare silenziosamente le connessioni TCP a lunga esecuzione, ad esempio quelle stabilite utilizzando il pooling delle connessioni. In questo modo, i client HTTP non funzionano quando riutilizzano una connessione già chiusa. Se intendi instradare il traffico in uscita tramite un proxy HTTP, devi implementare la convalida della connessione, i tentativi e il backoff esponenziale. Per i pool di connessioni, configura i valori massimi per l'età della connessione, le connessioni inattive e il timeout di inattività della connessione.

Timeout connessione

I seguenti errori si verificano quando un'applicazione tenta di creare una nuova connessione TCP con un host remoto e la connessione richiede troppo tempo per essere stabilita:

java.io.IOException: Connection timed out
 
ConnectionError: HTTPSConnectionPool
 
dial tcp REMOTE_HOST:REMOTE_PORT: i/o timeout / context error
 
Error: 4 DEADLINE_EXCEEDED: Deadline exceeded

Per risolvere i problemi di timeout della connessione:

  1. Se instradi tutto il traffico in uscita tramite una rete VPC, utilizzando connettori VPC o uscita VPC diretta, segui questi passaggi:

    • Definisci tutte le regole firewall necessarie per consentire il traffico in entrata per i connettori VPC.

    • Le regole firewall VPC devono consentire il traffico in entrata dai connettori VPC o dalla subnet di uscita VPC diretta per raggiungere l'host o la subnet di destinazione.

    • Assicurati di disporre di tutte le route necessarie per consentire il corretto routing del traffico verso gli host di destinazione e viceversa. Ciò è importante quando si instrada il traffico di uscita tramite il peering di rete VPC o la connettività cloud ibrida, poiché i pacchetti attraversano più reti prima di raggiungere l'host remoto.

  2. Se utilizzi un proxy HTTP per instradare tutto il traffico in uscita dai tuoi servizi o job Cloud Run, gli host remoti devono essere raggiungibili tramite il proxy.

    Il traffico instradato tramite un proxy HTTP potrebbe subire ritardi a seconda dell'utilizzo delle risorse del proxy. Se stai instradando il traffico in uscita HTTP utilizzando un proxy, implementa i nuovi tentativi, il backoff esponenziale o i circuit breaker.

Configurare le eccezioni del proxy HTTP

Quando utilizzi un proxy HTTP per instradare il traffico di uscita dei servizi o dei job Cloud Run, aggiungi eccezioni per le API Cloud e per altri host e subnet non proxy per evitare latenza, timeout di connessione, ripristini della connessione ed errori di autenticazione.

Gli host e le subnet non sottoposti a proxy devono includere, come minimo, quanto segue:

  • 127.0.0.1
  • 169.254.* o 169.254.0.0/16
  • localhost
  • *.google.internal
  • *.googleapis.com

Facoltativamente, gli host non proxy potrebbero includere:

  • *.appspot.com
  • *.run.app
  • *.cloudfunctions.net
  • *.gateway.dev
  • *.googleusercontent.com
  • *.pkg.dev
  • *.gcr.io

Per impostare le eccezioni del proxy HTTP per il networking in uscita, configura quanto segue:

  • Variabili di ambiente: NO_PROXY o no_proxy.

  • Flag della Java Virtual Machine http.nonProxyHosts:

    • La proprietà di sistema https.nonProxyHosts non è definita. Questa proprietà di sistema si applica sia a HTTP sia a HTTPS.

    • La proprietà di sistema http.nonProxyHosts non supporta la notazione CIDR. Devi utilizzare espressioni di corrispondenza dei pattern.

Risposta con formato non valido o problema di connessione dell'istanza container

Si verifica il seguente errore quando si verifica un problema di connessione dell'istanza container:

HTTP 503
The request failed because either the HTTP response was malformed or connection to the instance had an error.

Per risolvere il problema, segui questi passaggi:

  1. Controlla Cloud Logging per i seguenti errori:

    • Errori di esaurimento della memoria. Se i log contengono messaggi di errore relativi a istanze di container che superano i limiti di memoria, consulta i consigli nella sezione Le istanze di container superano i limiti di memoria.

    • Errori del probe di attività con il seguente errore nei log:

      LIVENESS HTTP probe failed 1 time consecutively for container CONTAINER_NAME on port 8080. The instance has been shut down.

      Quando l'istanza non risponde correttamente al probe entro il periodo di timeout, segui questi passaggi:

  2. Se le richieste terminano con il codice di errore 503 prima di raggiungere il timeout della richiesta impostato in Cloud Run, aggiorna l'impostazione del timeout della richiesta per il framework del linguaggio:

  3. In alcuni scenari, potrebbe verificarsi un codice di errore 503 a causa di un collo di bottiglia della rete downstream, ad esempio durante il test di carico. Ad esempio, se il tuo servizio instrada il traffico tramite un connettore di accesso VPC serverless, assicurati che il connettore non superi la soglia di velocità effettiva seguendo questi passaggi:

    1. Apri l'accesso VPC serverless nella console Google Cloud :

      Vai ad Accesso VPC serverless

    2. Controlla la presenza di barre rosse nell'istogramma del grafico del throughput. Se è presente una barra rossa, valuta la possibilità di aumentare il numero massimo di istanze o il tipo di istanza utilizzato dal connettore. In alternativa, comprimi il traffico inviato tramite un connettore di accesso VPC serverless.

  4. Se un'istanza container riceve più di 800 richieste al secondo, i socket TCP disponibili potrebbero esaurirsi. Per risolvere il problema, attiva HTTP/2 per il tuo servizio e apporta le modifiche necessarie al servizio per supportare HTTP/2.

Errore di timeout del gateway

Il seguente errore si verifica quando il tuo servizio non restituisce una risposta entro un periodo di tempo specificato e la richiesta termina:

HTTP 504
The request has been terminated because it has reached the maximum request timeout.

Per ulteriori informazioni su questo errore, consulta il contratto di runtime del container.

Per risolvere il problema:

  • Se il tuo servizio elabora richieste lunghe, aumenta il timeout della richiesta.

  • Registrazione e tracciamento degli strumenti per capire dove la tua app trascorre il tempo prima di superare il timeout della richiesta configurato.

  • Le connessioni in uscita vengono ripristinate di tanto in tanto a causa di aggiornamenti dell'infrastruttura. Se la tua applicazione riutilizza connessioni di lunga durata, ti consigliamo di configurarla in modo da ristabilire le connessioni per evitare il riutilizzo di una connessione non più attiva.

    A seconda della logica o della gestione degli errori dell'app, un errore 504 potrebbe indicare che l'applicazione sta tentando di riutilizzare una connessione non più attiva e la richiesta viene bloccata fino al timeout della richiesta configurato. Utilizza un probe di attività per terminare un'istanza che restituisce errori persistenti.

  • Gli errori di memoria insufficiente che si verificano all'interno del codice dell'app, ad esempio java.lang.OutOfMemoryError, non terminano necessariamente un'istanza container. Se l'utilizzo della memoria non supera il limite di memoria del container, Cloud Run non terminerà l'istanza. A seconda di come l'app gestisce gli errori di esaurimento della memoria a livello di app, le richieste potrebbero non essere elaborate finché non superano il timeout della richiesta configurato.

    Per terminare l'istanza del container:

    • Configura il limite di memoria a livello di app in modo che sia maggiore del limite di memoria del container.

    • Utilizza un probe di attività per terminare un'istanza che restituisce errori persistenti.

Il dominio personalizzato è bloccato durante il provisioning del certificato

Si verifica uno dei seguenti errori quando esegui il mapping di un dominio personalizzato:

The domain is available over HTTP.  Waiting for certificate provisioning. You must configure your DNS records for certificate issuance to begin and to accept HTTP traffic.
 
Waiting for certificate provisioning. You must configure your DNS records for certificate issuance to begin.

Per risolvere il problema:

  1. Attendi almeno 24 ore. Il provisioning del certificato SSL richiede in genere circa 15 minuti, ma può richiedere fino a 24 ore.

  2. Verifica di aver aggiornato correttamente i record DNS presso il registrar del dominio utilizzando lo strumento Dig degli Strumenti amministrativi Google. I record DNS nel registrar di domini devono corrispondere a quelli che la consoleGoogle Cloud ti chiede di aggiungere.

  3. Verifica la radice del dominio nel tuo account utilizzando uno dei seguenti metodi:

  4. Verifica che il certificato per il dominio non sia scaduto. Per trovare i limiti di scadenza, utilizza il comando seguente:

    echo | openssl s_client -servername 'ROOT_DOMAIN' -connect 'ROOT_DOMAIN:443' 2>/dev/null | openssl x509 -startdate -enddate -noout

La disconnessione del client non viene propagata a Cloud Run

Quando utilizzi HTTP/1.1 su Cloud Run, gli eventi di disconnessione del client non vengono propagato al container Cloud Run.

Per risolvere il problema, utilizza WebSocket o HTTP/2.0, che propagano le disconnessioni del client.