Risolvi i problemi di Cloud Run

Questa pagina descrive come risolvere gli errori che potresti riscontrare durante l'utilizzo di Cloud Run.

Controlla se sono presenti problemi esistenti o apri nuovi problemi negli issue tracker pubblici.

Per altri messaggi di errore non elencati in questa pagina, consulta la sezione Problemi noti di Cloud Run.

Errori di deployment

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

Impossibile avviare il contenitore

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 del contenitore localmente. Se l'immagine del contenitore non può essere eseguita localmente, devi prima diagnosticare e risolvere il problema localmente.

  2. Verifica se il contenitore è attivo in ascolto per le 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 Configurare i contenitori per i servizi.

  3. Controlla se il contenitore è in ascolto su tutte le interfacce di rete, comunemente indicate come 0.0.0.0. In particolare, il contenitore non deve ascoltare su 127.0.0.1.

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

  5. Utilizza Cloud Logging per cercare gli errori dell'applicazione nei log stdout o stderr. Puoi anche cercare gli arresti anomali rilevati 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 localmente.

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 ai seguenti esempi per aggiungere riferimenti alla fase di lancio quando utilizzi l'API REST v1 o v2:

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

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

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

    "launchStage": "BETA"

  • Aggiungi un'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

Utente root non trovato

Quando le chiavi di crittografia gestite dal cliente vengono specificate utilizzando un parametro --key, si verifica il seguente errore:

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 è specificato un account di servizio con il --service-account flag al momento del deployment.

  • Lo sviluppatore o il principale 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 l'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 Enti, individua l'ID dell'agente di servizio Compute Engine, che segue il formato PROJECT_NUMBER-compute@developer.gserviceaccount.com.

Problemi con l'account di servizio Cloud Build

Il seguente errore si verifica durante i deployment delle origini quando l'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 per l'utilizzo degli account di servizio nei nuovi progetti. Questa operazione è descritta in dettaglio nella 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 dal codice sorgente.

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) all'account di servizio di compilazione.

All'agente di servizio Cloud Run manca l'autorizzazione per leggere l'immagine

Quando provi a eseguire il deployment da un progetto utilizzando un'immagine archiviata in Artifact Registry, utilizzando il dominio gcr.io in un altro progetto, si verifica il seguente errore:

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.

Quando provi a eseguire il deployment da un progetto utilizzando un'immagine archiviata in Artifact Registry in un altro progetto, potresti anche visualizzare il seguente errore:

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 delle immagini container da altri Google Cloud progetti per assicurarti che le entità dispongano delle autorizzazioni necessarie.

  • Questo problema potrebbe verificarsi anche se il progetto si trova in un perimetro VPC Service Controls con una limitazione all'API Cloud Storage che vieta le richieste dall'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 dopo aver utilizzato questa query vengono visualizzate voci di log, 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 un criterio 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 l'account di servizio predefinito (PROJECT_NUMBER-compute@developer.gserviceaccount.com) o un account di servizio gestito dall'utente.

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

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

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

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

Quando nell'account di deployment mancano le autorizzazioni richieste per il progetto, si verifica il seguente errore:

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 di Identity and Access Management:

Errori di pubblicazione

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

HTTP 401: il client non è autenticato correttamente

Durante la pubblicazione si verifica il seguente errore:

The request was not authorized to invoke this service

Per risolvere il problema:

  • Se richiamato da un account di servizio, la rivendicazione del segmento di pubblico (aud) del token ID firmato da Google deve essere impostata su quanto segue:

    • L'URL Cloud Run del servizio di destinazione, utilizzando il modulo https://service-xyz.run.app.
      • Il servizio Cloud Run deve richiedere l'autenticazione.
      • Il servizio Cloud Run può essere richiamato tramite l'URL Cloud Run o tramite un URL del bilanciatore del carico.
    • L'ID client di un ID client OAuth 2.0 di tipo applicazione web, utilizzando il form nnn-xyz.apps.googleusercontent.com.
    • Un segmento di pubblico personalizzato configurato utilizzando i valori esatti forniti. Ad esempio, se il segmento di pubblico personalizzato è service.example.com, anche il valore della rivendicazione del segmento di pubblico (aud) deve essere service.example.com. Se il segmento di pubblico personalizzato è https://service.example.com, anche il valore della rivendicazione del segmento di pubblico deve essere https://service.example.com.

  • 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 i claim in un JWT, utilizza lo strumento jwt.io.

  • Potrebbe verificarsi un errore 403 quando al membro IAM utilizzato per generare il token di autorizzazione manca l'autorizzazione run.routes.invoke.

  • Quando utilizzi il server di metadati per recuperare token di 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 e ricevi token non validi, assicurati di aggiungere i seguenti host alle eccezioni del proxy HTTP:

    • 169.254.* o 169.254.0.0/16
    • *.google.internal

    Questo errore si verifica di solito 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 il servizio o il job Cloud Run e il proxy HTTP sono ospitati in diversi Google Cloud carichi di lavoro, anche se le librerie client sono in grado di ottenere le credenziali, i token vengono generati per il service account assegnato al carico di lavoro del proxy HTTP, che potrebbe non avere le autorizzazioni richieste per eseguire le operazioni previste dell'Google Cloud API. Google Cloud In questo caso, i token vengono recuperati dalla visualizzazione del server di metadati del carico di lavoro del proxy HTTP, anziché da quello di Cloud Run.

    • Se il proxy HTTP non è ospitato in Google Cloud e le richieste al server di metadati vengono instradate utilizzando il proxy, le richieste di token non andranno a buon fine e le operazioni delle APIGoogle Cloud non saranno autenticate.

HTTP 403: il client non è autorizzato a richiamare o chiamare il servizio

Il seguente errore potrebbe o meno essere presente in Cloud Logging con resource.type = "cloud_run_revision":

The request was not authenticated. Either allow unauthenticated invocations or set the proper Authorization header

Nella risposta HTTP restituita al client è presente il seguente errore:

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

Per risolvere il problema quando è presente l'errore Cloud Logging quando resource.type = "cloud_run_revision":

  • Se il servizio deve essere invocabile da chiunque, aggiorna le relative impostazioni IAM per renderlo pubblico.
  • Se il servizio deve essere invocato solo da determinate identità, assicurati di invocarlo con il token di autorizzazione corretto.
    • Se invocata da un sviluppatore o da un utente finale: assicurati che lo sviluppatore o l'utente disponga dell'autorizzazione run.routes.invoke, che puoi fornire tramite i ruoli Amministratore Cloud Run (roles/run.admin) e Invoker Cloud Run (roles/run.invoker).
    • Se chiamato da un account di servizio: assicurati che l'account di servizio sia un membro del servizio Cloud Run e che disponga del ruolo Invoker (roles/run.invoker) di Cloud Run.
    • Le chiamate in cui manca un token di autenticazione o con un token di autenticazione di formato valido, ma al membro IAM utilizzato per generare il token manca l'autorizzazione run.routes.invoke, generano questo errore 403.

Per risolvere il problema quando resource.type = "cloud_run_revision" l'errore di Cloud Logging non è presente:

  • Un codice di stato 403 può essere restituito quando un servizio ha ingress configurato su All, ma è stato bloccato a causa dei Controlli di servizio VPC. Per ulteriori informazioni sulla risoluzione dei problemi relativi ai rifiuti di VPC Service Controls, consulta la sezione successiva sugli errori 404.

HTTP 403: errore durante l'accesso al servizio da un browser web

Quando accedi a un servizio Cloud Run da un browser web, si verifica il seguente problema:

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 che chiama. Per risolvere questo problema, scegli uno dei seguenti rimedi:

  • Utilizza Identity-Aware Proxy (IAP) con Cloud Run. IAP consente di stabilire un livello di autorizzazione centrale per le applicazioni a cui si accede tramite HTTPS. Con IAP, puoi utilizzare un modello di controllo dell'accesso a livello di applicazione anziché i firewall a livello di rete. Per ulteriori dettagli sulla configurazione di Cloud Run con IAP, consulta Abilitazione di Identity-Aware Proxy per Cloud Run.

  • Come soluzione temporanea, puoi accedere al servizio tramite un browser web utilizzando il proxy Cloud Run in Google Cloud CLI. Puoi eseguire il proxy di un servizio localmente utilizzando quanto segue:

    gcloud run services proxy SERVICE --project PROJECT-ID

    Dopo aver eseguito questo comando, 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 in privato un sito web o un'API nel browser. Per ulteriori informazioni, consulta Testare i servizi privati.

  • Consenti chiamate non autenticate al tuo servizio. Questa opzione è utile per i test o quando il servizio è un'API o un sito web pubblici.

HTTP 404: Not Found

Durante la pubblicazione si verifica il seguente problema:

Si verifica un errore HTTP 404.

Per risolvere il problema:

  1. Verifica che l'URL che stai richiedendo sia corretto controllando la 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 logica dell'app potrebbe restituire codici di errore 404. Se la tua app restituisce 404, sarà visibile in Cloud Logging.

  3. Assicurati che l'app non inizi a eseguire l'ascolto sulla porta configurata prima di essere pronta per ricevere richieste.

  4. Verifica che l'app non restituisca un codice di errore 404 quando la esegui localmente.

Un 404 viene restituito quando le impostazioni di ingresso di un servizio Cloud Run sono impostate su "Interna" o "Interna e bilanciamento del carico su cloud" e una richiesta non soddisfa la restrizione di rete specificata. Questo può accadere anche se l'URL run.app predefinito del servizio Cloud Run è disattivato e un client tenta di raggiungere il servizio all'URL run.app. In entrambi gli scenari, la richiesta non raggiunge il contenitore e 404 non è presente in Cloud Logging con il seguente filtro:

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

Con le stesse impostazioni di ingresso, la richiesta potrebbe essere bloccata da VPC Service Controls in base al contesto dell'autore della chiamata, inclusi progetto e indirizzo IP. Per verificare la presenza di una violazione dei criteri di Controlli di servizio VPC:

  1. Apri Esplora log nella console Google Cloud (non la pagina Log per Cloud Run):

    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 dopo aver utilizzato questa query vengono visualizzate voci di log, esaminale per determinare se devi aggiornare o meno i criteri di VPC Service Controls.

Potresti anche visualizzare un errore 404 quando accedi all'endpoint del servizio con un bilanciatore del carico che utilizza il runtime Python. Per risolvere questo problema, verifica la maschera URL per il bilanciatore del carico e assicurati che il percorso dell'URL specificato per il bilanciatore del carico corrisponda al percorso nel codice sorgente di Python.

HTTP 429: nessuna istanza 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 contenitore" per il tuo servizio e valuta la possibilità di aumentare questo limite se il tuo utilizzo sta per raggiungere il massimo. Consulta le impostazioni"Numero massimo di istanze" e, se hai bisogno di più istanze, richiedi un aumento della quota.

HTTP 500: Cloud Run non è riuscito a gestire la frequenza del traffico

Il seguente errore si verifica durante la pubblicazione e può verificarsi anche quando il servizio non ha raggiunto il limite massimo di istanze contenitore:

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

Questo errore può essere causato da uno dei seguenti fattori:

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

Per risolvere il problema, risolvi i problemi elencati in precedenza.

Oltre a risolvere questi problemi, come soluzione alternativa puoi implementare il backoff esponenziale e i tentativi di nuovo per le richieste che il client non deve perdere.

Tieni presente che 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.

Quando la causa principale del problema è un periodo di errori transitori elevati attribuiti esclusivamente a Cloud Run, puoi contattare l'assistenza.

HTTP 501: l'operazione non è implementata

Durante la pubblicazione si verifica il seguente errore:

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

Questo problema si verifica quando specifichi un valore REGION errato durante l'invocazione del tuo job Cloud Run. Ad esempio, questo errore può verificarsi quando esegui il deployment di un job nella regione asia-southeast1 e lo richiami utilizzando southeast1-asia o asia-southeast. Per l'elenco delle regioni supportate, consulta Località di Cloud Run.

HTTP 503: le credenziali predefinite non sono state trovate

Durante la pubblicazione si verifica il seguente errore:

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

Questo problema 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.

Per risolvere il problema:

  1. Installa e inizializza la 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 l'accesso, le credenziali vengono memorizzate 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 progetto. Google Cloud

Per ulteriori informazioni, consulta Configurare le credenziali predefinite dell'applicazione.

HTTP 500 / HTTP 503: le istanze del contenitore stanno superando i limiti di memoria

Durante la pubblicazione si verifica il seguente errore:

In Cloud Logging:

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 gli errori correlati nei log varlog/system.
  2. Se le istanze superano la memoria disponibile, valuta la possibilità di aumentare il limite di memoria.

Tieni presente che in Cloud Run i file scritti nel file system locale vengono conteggiati in relazione alla memoria disponibile. Sono inclusi anche i file di log scritti in posizioni diverse da /var/log/* e /dev/log.

HTTP 503: risposta non corretta o problema di connessione all'istanza del contenitore

Durante la pubblicazione si verifica uno dei seguenti errori: 

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 consigli per la risoluzione dei problemi:

  • Controlla Cloud Logging Utilizza Cloud Logging per cercare errori di esaurimento della memoria nei log. Se visualizzi messaggi di errore relativi a istanze di contenitori che superano i limiti di memoria, segui i consigli per risolvere il problema.

  • Timeout a livello di app Se le richieste terminano con il codice di errore 503 prima di raggiungere il timeout delle richieste impostato in Cloud Run, potrebbe essere necessario aggiornare l'impostazione del timeout delle richieste per il tuo framework linguistico:

  • Bottleneck della rete a valle In alcuni casi, un codice di errore 503 può derivare indirettamente da un bottleneck della rete a valle, ad esempio durante i test di carico. Ad esempio, se il tuo servizio instrada il traffico tramite un connettore Serverless VPC Access, assicurati che il connettore non abbia superato la soglia di throughput seguendo questi passaggi:

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

      Vai ad Accesso VPC serverless

    2. Controlla se sono presenti 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, comprimere il traffico inviato tramite un connettore di accesso VPC serverless.

  • Limite di richieste in entrata per un singolo contenitore Esiste un problema noto in cui sono presenti tassi di richieste elevati per contenitore che generano questo errore 503. Se un'istanza di container riceve più di 800 richieste al secondo, le socket TCP disponibili possono essere esaurite. Per risolvere il problema, prova una delle seguenti soluzioni:

    1. Attiva HTTP/2 per il tuo servizio e apporta le modifiche necessarie per supportare HTTP/2.

    2. Evita di inviare più di 800 richieste al secondo a una singola istanza container riducendo la contemporaneità configurata. Utilizza la seguente equazione per ottenere una stima della frequenza di richiesta per istanza container: requests/sec/container_instance ~= concurrency * (1sec / median_request_latency)

HTTP 503: impossibile elaborare alcune richieste a causa di un'impostazione di concorrenza elevata

Durante la pubblicazione si verificano i seguenti errori:

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

Questo problema si verifica quando le istanze di container utilizzano molta CPU per elaborare le richieste e, di conseguenza, non possono elaborarle tutte, pertanto alcune richieste restituiscono un codice di errore 503.

Per risolvere il problema, prova una o più delle seguenti operazioni:

HTTP 504: errore di timeout del gateway

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

Se il tuo servizio elabora richieste lunghe, puoi aumentare il timeout della richiesta. Se il servizio non restituisce una risposta entro il tempo specificato, la richiesta termina e il servizio restituisce un errore HTTP 504, come descritto nel contratto del runtime del contenitore.

Per risolvere il problema, prova una o più delle seguenti operazioni:

  • Utilizza il logging e il tracing per capire dove la tua app sta impiegando tempo prima di superare il timeout della richiesta configurato.

  • Le connessioni in uscita vengono reimpostate occasionalmente 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 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 attiva e la richiesta si blocca fino al timeout della richiesta configurato.
    • Puoi utilizzare un probe di attività per contribuire a terminare un'istanza che restituisce errori persistenti.

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

    • Se vuoi che l'istanza del contenitore venga interrotta nello scenario precedente, configura il limite di memoria a livello di app in modo che sia superiore al limite di memoria del contenitore.
    • Puoi utilizzare un probe di attività per contribuire a terminare un'istanza che restituisce errori persistenti.

Errori di Cloud Logging relativi all'interruzione delle richieste in coda in attesa

Quando Cloud Run non riesce a eseguire il ridimensionamento sufficientemente 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 enorme aumento improvviso del traffico.
    • Tempo di avvio a freddo lungo.
    • Tempo di elaborazione delle richieste lungo.
    • Tasso di errori del codice sorgente elevato.
    • Raggiungere il limite massimo di istanze e impedire la scalabilità del sistema.
    • Fattori temporanei attribuiti al servizio Cloud Run.

    Per ulteriori informazioni sulla risoluzione dei problemi di ridimensionamento e sull'ottimizzazione del rendimento, consulta Suggerimenti generali per lo sviluppo.

  2. Per i servizi o le funzioni basati su trigger HTTP, chiedi al client di implementare il backoff e i tentativi di nuovo invio esponenziali per le richieste che non devono essere ignorate. Se attivi i servizi da Workflows, puoi utilizzare la sintassi try/retry per farlo.

  3. Per servizi o funzioni in background o basati su eventi, Cloud Run supporta la consegna almeno una volta. Anche senza abilitare esplicitamente il nuovo tentativo, Cloud Run re-invia automaticamente l'evento e riprova a eseguire l'operazione. Per ulteriori informazioni, consulta Riprovare 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 impatto maggiore sulla fatturazione.

  5. Quando la causa principale del problema è un periodo di errori transitori elevati attribuiti esclusivamente a Cloud Run o se hai bisogno di assistenza per il problema, contatta l'assistenza.

Connessione reimpostata dal peer

Durante la pubblicazione si verifica uno dei seguenti errori:

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

Questo errore si verifica quando un'applicazione ha una connessione TCP stabilita con un peer sulla rete e il peer chiude inaspettatamente la connessione.

Per risolvere il problema:

  • Se stai tentando di eseguire un'operazione in background con la limitazione della CPU, prova a utilizzare l'impostazione della fatturazione basata sulle istanze.

  • Assicurati di rispettare i tempi di attesa delle richieste in uscita. Se la tua applicazione mantiene una connessione in uno stato inattivo oltre queste soglie, il gateway deve recuperarla.

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

  • A volte le connessioni in uscita verranno reimpostate per via 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 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 di lunga durata, come quelle stabilite utilizzando il pool di connessioni. Ciò causa un errore nei client HTTP quando riutilizzano una connessione già chiusa. Se intendi instradare il traffico in uscita tramite un proxy HTTP, assicurati di tenere conto di questo scenario implementando la convalida della connessione, i tentativi di nuovo e il backoff esponenziale. Per i pool di connessioni, configura i valori massimi per l'età delle connessioni, le connessioni inattive e il timeout di inattività delle connessioni.

Timeout di connessione

Gli errori di latenza o uno dei seguenti errori si verificano quando si verificano timeout di connessione durante l'invio di una richiesta a un host remoto:

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

Questo tipo di errori si verifica quando un'applicazione tenta di creare una nuova connessione TCP con un host remoto e la connessione richiede troppo tempo per essere stabilita.

  • Se indirizzi tutto il traffico in uscita tramite una rete VPC, utilizzando connettori VPC o uscita diretta VPC, assicurati che:

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

    • Le regole del firewall VPC consentono il traffico in entrata dall'host o dalla subnet di destinazione dei connettori VPC o della subnet di VPC diretto in uscita.

    • Disponi di tutte le route necessarie per consentire il routing corretto del traffico agli host di destinazione e viceversa. Questo è importante quando indirizzi il traffico in uscita tramite il peering di rete VPC o la connettività cloud ibrida, poiché i pacchetti attraversano più reti prima di raggiungere l'host remoto.

  • Se utilizzi un proxy HTTP per instradare tutto il traffico in uscita dai tuoi servizi o job Cloud Run, assicurati che gli host remoti siano raggiungibili utilizzando il proxy.

    Il traffico instradato tramite un proxy HTTP potrebbe subire ritardi a seconda dell'utilizzo delle risorse del proxy. Se è previsto il routing del traffico in uscita HTTP tramite un proxy, assicurati di tenere conto di questo scenario implementando i tentativi, il backoff esponenziale o gli interruttori di sicurezza.

Configurare le eccezioni del proxy HTTP

Quando utilizzi un proxy HTTP per instradare il traffico in uscita dei servizi o dei job Cloud Run, assicurati di aggiungere eccezioni per le API Cloud e per altri host e sottoreti non proxy per evitare latenza, timeout delle connessioni, reimpostazione delle connessioni ed errori di autenticazione.

Gli host e le sottoreti non proxy devono includere, come minimo, quanto segue:

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

Se vuoi, gli host non proxy possono includere:

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

I modi comuni per configurare le eccezioni del proxy HTTP per la rete in uscita include:

  • Variabili di ambiente: NO_PROXY o no_proxy.

  • Indicatore della macchina virtuale Java http.nonProxyHosts.

    • La proprietà di sistema https.nonProxyHosts non è definita, quindi http.nonProxyHosts si applica sia a HTTP che a HTTPS.
    • La proprietà di sistema http.nonProxyHosts non supporta la notazione CIDR, pertanto devi utilizzare espressioni di corrispondenza dei pattern.

Firma del token di identità oscurata da Google

Durante la pubblicazione si verificano i seguenti errori:

SIGNATURE_REMOVED_BY_GOOGLE

Questo può verificarsi durante lo sviluppo e i test nelle seguenti circostanze:

  1. Un utente accede utilizzando Google Cloud CLI o Cloud Shell.
  2. L'utente genera un token ID utilizzando i comandi gcloud.
  3. L'utente tenta di utilizzare il token ID per richiamare un servizio Cloud Run non pubblico.

Si tratta del comportamento 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, invoca il servizio privato con un nuovo token ID. Per ulteriori informazioni, consulta la sezione relativa al test dell'autenticazione nel tuo servizio.

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

Si tratta solo di un avviso e non ha alcun effetto sul tuo servizio. Questo avviso si verifica perché la sandbox del contenitore utilizzata dall'ambiente di esecuzione di prima generazione non espone le funzionalità hardware di basso livello. Se non vuoi che questi avvisi vengano visualizzati nei log, puoi passare all'ambiente di esecuzione di seconda generazione.

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

Durante la pubblicazione 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:

Per modificare il valore della variabile di ambiente e risolvere il problema, imposta ENV SPARK_LOCAL_IP="127.0.0.1" nel Dockerfile. In Cloud Run, se la variabile SPARK_LOCAL_IP non è impostata, per impostazione predefinita verrà utilizzata la controparte IPv6 anziché localhost. Tieni presente che l'impostazione RUN export SPARK_LOCAL_IP="127.0.0.1" non sarà disponibile in fase di esecuzione e Spark si comporterà come se non fosse impostata.

Mapping di domini personalizzati

Lo stato del provisioning del certificato del dominio personalizzato è bloccato

Quando provi a mappare un dominio personalizzato, viene visualizzato uno dei seguenti errori:

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:

  • Attendi almeno 24 ore. Il provisioning del certificato SSL richiede in genere circa 15 minuti, ma possono essere necessarie fino a 24 ore.

  • 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 tuo registrar di domini devono corrispondere a quelli che la console Google Cloud ti chiede di aggiungere.

  • Verifica che la parte principale del dominio sia verificata nel tuo account utilizzando uno dei seguenti metodi:

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

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

La disconnessione del client non si propaga a Cloud Run

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

La soluzione è utilizzare WebSocket o HTTP/2.0, che propagano le disconnessioni del client.

Risolvere i problemi relativi al file system di rete

Scopri di più sull'utilizzo dei sistemi di file di rete.

Impossibile accedere ai file utilizzando NFS

Errore Rimedio suggerito
mount.nfs: Protocol not supported Per alcune immagini di base, ad esempio 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, verifica 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.