Questa pagina mostra come risolvere i problemi relativi all'utilizzo di Cloud Run e ai messaggi di errore.
Puoi anche verificare la presenza di problemi esistenti o aprirne di nuovi negli Issue Tracker pubblici.
Per altri messaggi di errore non elencati in questa pagina, consulta la pagina dei problemi noti.
Errori di deployment
Questa sezione elenca i problemi che potresti riscontrare durante il deployment e fornisce suggerimenti su come 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, elimina le seguenti potenziali cause:
Verifica di poter eseguire l'immagine container in locale. Se l'immagine container non può essere eseguita localmente, devi prima diagnosticare e risolvere il problema localmente.
Controlla se il container è in ascolto di richieste sulla porta prevista, come documentato nel contratto di runtime del container. Il container deve rimanere in ascolto delle richieste in entrata sulla porta definita da Cloud Run e fornita nella variabile di ambiente
PORT
. Consulta Configurazione dei container per le istruzioni su come specificare la porta.Verifica se il container è in ascolto su tutte le interfacce di rete, comunemente indicato come
0.0.0.0
.Verifica che l'immagine container sia compilata per Linux a 64 bit come richiesto dal contratto di runtime del container.
Utilizza Cloud Logging per cercare gli errori dell'applicazione nei log
stdout
ostderr
. Puoi anche cercare gli 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 localmente.
Errore interno, scadenza dell'idoneità delle risorse superata
Il seguente errore si verifica quando provi a eseguire il deployment o a chiamare un'altra API Google Cloud:
The server has encountered an internal error. Please try again later. Resource readiness deadline exceeded.
Questo problema può verificarsi quando l'agente di servizio Cloud Run non esiste o se non ha il ruolo Agente di servizio Cloud Run (roles/run.serviceAgent
).
Per verificare che l'agente di servizio Cloud Run esista nel tuo progetto Google Cloud e abbia il ruolo necessario, segui questi passaggi:
Apri la console Google Cloud:
Nell'angolo in alto a destra della pagina Autorizzazioni, seleziona la casella di controllo Includi concessioni dei ruoli fornite da Google.
Nell'elenco Entità, individua l'ID dell'agente di servizio Cloud Run, che utilizza l'ID
service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com
.Verifica che l'agente di servizio disponga del ruolo Agente di servizio Cloud Run. Se l'agente di servizio non ha il ruolo, concedilo.
Impossibile trovare l'utente con errore "root" in /etc/passwd
Quando provi a eseguire il deployment, si verifica il seguente errore:
ERROR: "User \"root\""not found in /etc/passwd
Il problema si verifica quando le chiavi di crittografia gestite dal cliente vengono specificate utilizzando un parametro--key
Per risolvere il problema, specifica USER 0
anziché USER root
nel Dockerfile.
L'account di servizio Compute Engine predefinito è stato eliminato
Quando provi a eseguire 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 una delle seguenti situazioni:
- L'account di servizio Compute Engine predefinito non esiste nel progetto e non è specificato alcun account di servizio con il flag
--service-account
gcloud
al momento del deployment. - Lo sviluppatore o l'entità che esegue il deployment del servizio non dispone delle autorizzazioni per l'account di servizio Compute Engine predefinito che è necessario per il deployment.
Per risolvere il problema:
- Specifica un account di servizio utilizzando il flag
gcloud
--service-account
. - Verifica che l'account di servizio specificato disponga delle autorizzazioni necessarie per il deployment.
Se vuoi verificare se l'agente di servizio Compute Engine predefinito esiste nel progetto Google Cloud, segui questi passaggi:
Apri la console Google Cloud:
Nell'angolo in alto a destra della pagina Autorizzazioni, seleziona la casella di controllo Includi concessioni dei ruoli fornite da Google.
Nell'elenco Entità, individua l'ID dell'agente di servizio Compute Engine, che utilizza l'ID
PROJECT_NUMBER-compute@developer.gserviceaccount.com
.
L'agente di servizio Cloud Run non dispone dell'autorizzazione per leggere l'immagine
Il seguente errore si verifica quando provi a eseguire il deployment da PROJECT-ID utilizzando un'immagine archiviata in Container Registry in PROJECT-ID-2:
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.
Per risolvere il problema, segui questi consigli per la risoluzione dei problemi:
Segui le istruzioni per eseguire il deployment delle immagini container da altri progetti Google Cloud per assicurarti che le entità dispongano delle autorizzazioni necessarie.
Questo problema potrebbe verificarsi anche se il progetto si trova in un perimetro dei Controlli di servizio VPC con una restrizione sull'API Cloud Storage che vieta le richieste da parte dell'agente di servizio Cloud Run. Per risolvere il problema:
Apri Esplora log nella console Google Cloud. Non utilizzare la pagina Log nella pagina di Cloud Run):
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"
Se dopo aver utilizzato questa query, vedi voci di log, esaminale per determinare se devi aggiornare i criteri dei Controlli di servizio VPC. Potrebbero indicare che devi aggiungere
service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com
a un criterio di accesso preesistente.
Errori di importazione del container
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, elimina le seguenti potenziali cause:
Assicurati che il file system del container non contenga caratteri non utf8.
Alcune immagini Docker basate su Windows utilizzano livelli esterni. Anche se Container Registry non genera un errore in presenza di livelli esterni, il piano di controllo di Cloud Run non li supporta. Per risolvere il problema, puoi provare a impostare il flag
--allow-nondistributable-artifacts
nel daemon Docker.
Errori di pubblicazione
Questa sezione elenca i problemi che potresti riscontrare nella pubblicazione e fornisce suggerimenti per risolverli.
HTTP 401: il client non è autenticato correttamente
Durante l'elaborazione si verifica il seguente errore:
The request was not authorized to invoke this service
Per risolvere il problema:
Se viene richiamato da un account di servizio, l'attestazione del pubblico (
aud
) del token ID firmato da Google deve essere impostata come segue:- L'URL Cloud Run del servizio ricevente, utilizzando il modulo
https://service-xyz.run.app
.- Il servizio Cloud Run deve richiedere l'autenticazione.
- Il servizio Cloud Run può essere richiamato dall'URL di Cloud Run o tramite l'URL di un bilanciatore del carico.
- L'ID client di un ID client OAuth 2.0 di tipo applicazione web, utilizzando il
modulo
nnn-xyz.apps.googleusercontent.com
.- Il servizio Cloud Run può essere richiamato tramite un bilanciatore del carico HTTPS protetto da IAP.
- Questa opzione è ideale per un GCLB supportato da più servizi Cloud Run in diverse regioni.
- Un segmento di pubblico personalizzato configurato utilizzando gli esatti valori forniti. Ad esempio,
se il segmento di pubblico personalizzato è
service.example.com
, anche il valore della rivendicazione del pubblico (aud
) deve essereservice.example.com
. Se il segmento di pubblico personalizzato èhttps://service.example.com
, anche il valore della dichiarazione del pubblico deve esserehttps://service.example.com
.
- L'URL Cloud Run del servizio ricevente, utilizzando il modulo
Lo strumento jwt.io è utile per verificare le rivendicazioni su un JWT.
Se il formato del token di autenticazione non è valido, si verifica un errore
401
. Se il token è in un formato valido e il membro IAM utilizzato per generare il token non dispone dell'autorizzazionerun.routes.invoke
, si verifica un errore403
.Quando utilizzi il server di metadati per recuperare ID e token di accesso per autenticare le richieste con il servizio Cloud Run o l'identità del job 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.*
o169.254.0.0/16
*.google.internal
Questo errore si verifica comunemente quando le librerie client di 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, il comportamento sarà il seguente:
Se il servizio o il job Cloud Run e il proxy HTTP sono ospitati in diversi carichi di lavoro di Google Cloud, anche se le librerie client di Google Cloud sono in grado di ottenere le credenziali, i token vengono generati per l'account di servizio assegnato al carico di lavoro del proxy HTTP, che potrebbe non disporre delle autorizzazioni necessarie per eseguire le operazioni previste per l'API Google Cloud. In questo caso, i token vengono recuperati dalla visualizzazione del server 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 del server dei metadati vengono instradate tramite proxy, le richieste di token non andranno a buon fine e le operazioni delle API Google Cloud non verranno autenticate.
HTTP 403: il client non è autorizzato a richiamare o chiamare il servizio
Il seguente errore potrebbe essere o meno 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 questo problema quando è presente l'errore resource.type = "cloud_run_revision" Cloud Logging :
- Se il servizio deve essere richiamato da chiunque, aggiorna le relative impostazioni IAM per renderlo pubblico.
- Se vuoi che il servizio possa essere chiamato solo da determinate identità, assicurati di richiamarlo con il token di autorizzazione appropriato.
- Se la chiamata è stata richiamata da uno sviluppatore o un utente finale: assicurati che lo sviluppatore o l'utente disponga dell'autorizzazione
run.routes.invoke
, che puoi fornire tramite i ruoli Amministratore di Cloud Run (roles/run.admin
) e Invoker di Cloud Run (roles/run.invoker
). - Se richiamato da un account di servizio: assicurati che l'account di servizio sia membro del servizio Cloud Run e che abbia il ruolo Invoker di Cloud Run (
roles/run.invoker
). - Nelle chiamate manca un token di autenticazione o con un token di autenticazione in formato
valido, ma il membro IAM utilizzato per generare il token non dispone dell'autorizzazione
run.routes.invoke
. Questo genera questo errore403
.
- Se la chiamata è stata richiamata da uno sviluppatore o un utente finale: assicurati che lo sviluppatore o l'utente disponga dell'autorizzazione
Per risolvere questo problema quando resource.type = "cloud_run_revision" l'errore Cloud Logging non è presente:
- È possibile restituire un codice di stato 403 quando un servizio è in entrata configurato in
All
, ma è stato bloccato a causa dei Controlli di servizio VPC. Consulta la prossima sezione sugli errori 404 per ulteriori informazioni sulla risoluzione dei problemi relativi ai rifiuti di Controlli di servizio VPC.
HTTP 403: errore durante l'accesso al servizio da un browser web
Il problema seguente si verifica 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, quest'ultimo invia una richiesta GET
al servizio. Tuttavia, la richiesta non contiene il token di autorizzazione dell'utente chiamante. Per risolvere il problema, scegli uno dei seguenti rimedi:
Utilizza Identity-Aware Proxy (IAP) con Cloud Run. IAP consente di definire un livello di autorizzazione centrale per le applicazioni accessibili tramite HTTPS. Con IAP, puoi utilizzare un modello di controllo dell'accesso a livello di applicazione anziché un firewall a livello di rete. Per maggiori dettagli sulla configurazione di Cloud Run con IAP, vedi Abilitazione di Identity-Aware Proxy per Cloud Run.
Come soluzione alternativa 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 a
http://localhost:8080
(o alla porta specificata con--port
), fornendo il token dell'account attivo o un altro token da te specificato. Questo è il metodo consigliato per testare in privato un sito web o un'API nel tuo browser. Per ulteriori informazioni, consulta la sezione Test di servizi privati.Consenti chiamate non autenticate al tuo servizio. È utile per i test o quando il servizio è un'API o un sito web pubblici.
HTTP 404: non trovato
Durante la pubblicazione si verifica il seguente problema:
Si è verificato un errore HTTP 404
.
Per risolvere il problema:
Verifica che l'URL richiesto sia corretto controllando la pagina dei dettagli del servizio nella console Google Cloud o eseguendo questo comando:
gcloud run services describe SERVICE_NAME | grep URL
Controlla dove la logica dell'app potrebbe restituire codici di errore
404
. Se la tua app restituisce l'oggetto404
, questo sarà visibile in Cloud Logging.Assicurati che la tua app non inizi ad ascoltare sulla porta configurata prima che sia pronta a ricevere le richieste.
Verifica che l'app non restituisca un codice di errore
404
quando eseguita in locale.
Viene restituito un 404
quando le impostazioni in entrata di un servizio Cloud Run sono impostate su "Interna" o "Interna e Cloud Load Balancing" e una richiesta non soddisfa la limitazione di rete specificata. In questo scenario, la richiesta non raggiunge il container 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 traffico in entrata, la richiesta potrebbe essere bloccata dai Controlli di servizio VPC in base al contesto del chiamante, inclusi il progetto e l'indirizzo IP. Per verificare la presenza di una violazione delle norme dei Controlli di servizio VPC:
Apri Esplora log nella console Google Cloud (non la pagina Log per Cloud Run):
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"
Se, dopo aver utilizzato questa query, vedi voci di log, esaminale per determinare se devi aggiornare i criteri dei Controlli di servizio VPC.
HTTP 429: nessuna istanza di container disponibile
Durante l'elaborazione 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 sta per raggiungere il limite massimo. Vedi le impostazioni"max istanza" 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 di container:
HTTP 500 The request was aborted because there was no available instance
Questo errore può essere causato da una delle seguenti cause:
- Un enorme aumento improvviso del traffico.
- Un'ora di avvio a freddo lunga.
- Tempo di elaborazione delle richieste lungo o un improvviso aumento del tempo di elaborazione delle richieste.
- Il servizio sta raggiungendo il limite massimo di istanze di container (
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 nuovi tentativi per le richieste che il client non deve abbandonare.
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 alla risoluzione di 10 secondi.
Se la causa principale del problema è un periodo di aumentati errori temporanei attribuibili esclusivamente a Cloud Run, puoi contattare l'assistenza.
HTTP 503: impossibile trovare le credenziali predefinite
Durante l'elaborazione 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 di credenziali non validi o assegnazioni errate di variabili di ambiente.
Per risolvere il problema:
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 credenziali vengono archiviate nel file delle credenziali locali utilizzato da ADC.
Utilizza la variabile di ambiente
GOOGLE_APPLICATION_CREDENTIALS
per indicare la posizione di un file JSON delle credenziali all'interno del tuo progetto Google Cloud.
Per ulteriori informazioni, vedi Configurare le credenziali predefinite dell'applicazione.
HTTP 500 / HTTP 503: le istanze di container stanno superando i limiti di memoria
Durante l'elaborazione 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:
- Determina se le istanze di container superano la memoria disponibile.
Cerca gli errori correlati nei log
varlog/system
. - 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
per la memoria disponibile. Sono inclusi anche gli eventuali file di log scritti
in posizioni diverse da /var/log/*
e /dev/log
.
HTTP 503: problema di connessione all'istanza di container o risposta non corretta
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 memoria insufficiente nei log. Se visualizzi messaggi di errore relativi a istanze di container che superano i limiti di memoria, segui i consigli per risolvere il problema.
Timeout a livello di app Se le richieste vengono terminate con il codice di errore
503
prima di raggiungere il timeout della richiesta impostato in Cloud Run, potrebbe essere necessario aggiornare l'impostazione di timeout della richiesta per il framework del linguaggio:- Gli sviluppatori Node.js potrebbero dover aggiornare la
proprietà
server.timeout
tramiteserver.setTimeout
(utilizzaserver.setTimeout(0)
per ottenere un timeout illimitato) a seconda della versione in uso. [CRITICAL] WORKER TIMEOUT
Gli sviluppatori Python devono aggiornare il timeout predefinito di Gunicorn.
- Gli sviluppatori Node.js potrebbero dover aggiornare la
proprietà
Collo di bottiglia della rete downstream In alcuni casi, un codice di errore
503
può derivare indirettamente da un collo di bottiglia della rete downstream, ad esempio durante il test di carico. Ad esempio, se il tuo servizio instrada il traffico attraverso un connettore di accesso VPC serverless, assicurati che il connettore non abbia superato la soglia di velocità effettiva seguendo questa procedura:Apri l'accesso VPC serverless nella console Google Cloud:
Verifica la presenza di barre red nell'istogramma del grafico della velocità effettiva. Se è presente una barra red, valuta la possibilità di aumentare il numero massimo di istanze o tipi di istanza utilizzati dal connettore. In alternativa, comprimi il traffico inviato tramite un connettore di accesso VPC serverless.
Limite di richieste in entrata a un singolo container Si è verificato un problema noto in cui sono presenti elevata percentuale di richieste per container che genererà questo errore
503
. Se un'istanza di container riceve più di 800 richieste al secondo, i socket TCP disponibili possono essere esauriti. Per risolvere il problema, prova una delle seguenti soluzioni:Attiva HTTP/2 per il tuo servizio e apporta le modifiche necessarie per supportare HTTP/2.
Evita di inviare più di 800 richieste al secondo a una singola istanza di container riducendo la contemporaneità configurata. Utilizza la seguente equazione per ottenere una stima del tasso di richieste per istanza di container:
requests/sec/container_instance ~= concurrency * (1sec / median_request_latency)
HTTP 503: impossibile elaborare alcune richieste a causa dell'impostazione di un'elevata contemporaneità
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, le istanze di container non sono in grado di elaborare tutte le richieste. Di conseguenza, alcune richieste restituiscono un codice di errore 503
.
Per risolvere il problema, prova una o più delle seguenti operazioni:
Aumenta il numero massimo di istanze di container per il tuo servizio.
Ridurre la contemporaneità del servizio. Per istruzioni più dettagliate, consulta Impostazione della contemporaneità.
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 tuo servizio non restituisce una risposta entro il tempo specificato, la richiesta termina e il servizio restituisce un errore HTTP 504
, come documentato nel contratto di runtime del container.
Per risolvere questo problema, prova una o più delle seguenti operazioni:
Logging 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 reimpostate a volte a causa degli aggiornamenti dell'infrastruttura. Se l'applicazione riutilizza connessioni di lunga durata, ti consigliamo di configurare l'applicazione in modo da ristabilire le connessioni per evitare il riutilizzo di una connessione inattiva.
- A seconda della logica o della gestione degli errori dell'app, un errore
504
potrebbe indicare che la tua applicazione sta tentando di riutilizzare una connessione non disponibile e che la richiesta si blocca fino al timeout della richiesta configurata. - Puoi utilizzare un probe di attività per terminare un'istanza che restituisce errori permanenti.
- A seconda della logica o della gestione degli errori dell'app, un errore
Gli errori di memoria insufficiente che si verificano all'interno del codice dell'app, ad esempio
java.lang.OutOfMemoryError
, non terminano necessariamente un'istanza di container. 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 configurato.- Se vuoi che l'istanza di container termini nello scenario di cui sopra, configura il limite di memoria a livello di app in modo che sia maggiore del limite di memoria del container.
- Puoi utilizzare un probe di attività per terminare un'istanza che restituisce errori permanenti.
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 nella rete e il peer chiude inaspettatamente la connessione.
Per risolvere il problema:
Se stai tentando di eseguire lavori in background con la limitazione della CPU, prova a utilizzare l'impostazione di allocazione della CPU "La CPU è sempre allocata".
Assicurati di rientrare nei timeout delle richieste in uscita. Se l'applicazione mantiene una connessione in stato di inattività oltre queste soglie, il gateway deve recuperare la connessione.
Per impostazione predefinita, l'opzione socket TCP
keepalive
è disabilitata per Cloud Run. Non esiste un modo diretto per configurare l'opzionekeepalive
in Cloud Run a livello di servizio, ma puoi abilitare l'opzionekeepalive
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 vengono reimpostate a causa di aggiornamenti dell'infrastruttura. Se l'applicazione riutilizza connessioni di lunga durata, ti consigliamo di configurare l'applicazione in modo da ristabilire le connessioni per evitare il riutilizzo di una connessione inattiva.
Se utilizzi un proxy HTTP per instradare il traffico in uscita dei servizi Cloud Run o dei job e il proxy applica la durata massima della connessione, il proxy potrebbe ignorare automaticamente le connessioni TCP a lunga esecuzione, come quelle stabilite utilizzando il pool di connessioni. Questo causa un errore dei client HTTP quando riutilizza 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 nuovi 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 per inattività della connessione.
Timeout connessione
In caso di timeout della connessione quando si effettua una richiesta a un host remoto, si verificano errori di latenza o uno dei seguenti errori:
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 impiega troppo tempo per essere stabilita.
Se instrada tutto il traffico in uscita attraverso una rete VPC, utilizzando connettori VPC o in uscita VPC diretto, assicurati che:
Hai definito tutte le regole firewall necessarie per consentire il traffico in entrata per i connettori VPC.
Le regole firewall VPC consentono il traffico in entrata dai connettori VPC o dalla subnet VPC diretta in uscita per raggiungere l'host o la subnet di destinazione.
Disporre di tutte le route richieste per consentire il corretto routing del traffico verso gli host di destinazione e viceversa. Questo è importante quando si instrada 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 servizi o dai 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 HTTP in uscita utilizzando un proxy, assicurati di tenere conto di questo scenario implementando nuovi tentativi, backoff esponenziale o interruttori di sicurezza.
Configura eccezioni 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 altri host e subnet senza proxy per evitare latenza, timeout della connessione, reimpostazioni delle connessioni ed errori di autenticazione.
Gli host e le subnet senza proxy devono includere almeno quanto segue:
127.0.0.1
169.254.*
o169.254.0.0/16
localhost
*.google.internal
*.googleapis.com
Facoltativamente, gli host senza proxy possono includere:
*.appspot.com
*.run.app
*.cloudfunctions.net
*.gateway.dev
*.googleusercontent.com
*.pkg.dev
*.gcr.io
Di seguito sono riportati alcuni modi comuni per configurare le eccezioni del proxy HTTP per il networking in uscita:
- Variabili di ambiente:
NO_PROXY
ono_proxy
. Flag Java Virtual Machine
http.nonProxyHosts
.- La proprietà di sistema
https.nonProxyHosts
non è definita, quindihttp.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.
- La proprietà di sistema
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 nei seguenti casi:
- Un utente accede 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.
Si tratta del comportamento previsto. Per motivi di sicurezza, Google rimuove la firma del token 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 la pagina relativa al test dell'autenticazione nel 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 tuoi log:
OpenBLAS WARNING - could not determine the L2 cache size on this system,
assuming 256k
Questo è solo un avviso e non influisce sul tuo servizio. Questo avviso si verifica perché la sandbox del container utilizzata dall'ambiente di esecuzione di prima generazione non espone funzionalità hardware di basso livello. Facoltativamente, puoi passare all'ambiente di esecuzione di seconda generazione se non vuoi visualizzare questi avvisi nei log.
Spark non riesce durante l'acquisizione dell'indirizzo IP della macchina a cui eseguire l'associazione
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, utilizzerà per impostazione predefinita la rispettiva controparte IPv6 anziché localhost. Tieni presente che l'impostazione RUN export SPARK_LOCAL_IP="127.0.0.1"
non sarà disponibile in fase di runtime e Spark funzionerà come se non fosse stato impostato.
Mapping di domini personalizzati
Il dominio personalizzato è bloccato nello stato del provisioning dei certificati
Quando provi a mappare un dominio personalizzato, si verifica 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 in genere richiede circa 15 minuti, ma a volte possono essere necessarie fino a 24 ore.
Verifica di aver aggiornato correttamente i record DNS nel registrar di domini utilizzando lo strumento dig degli Strumenti amministrativi Google
I record DNS nel tuo registrar di domini devono corrispondere a ciò che la console Google Cloud ti chiede di aggiungere.
Conferma che la principale del dominio sia verificata nel tuo account utilizzando uno dei seguenti metodi:
- Segui le istruzioni per aggiungere proprietari di domini verificati e controlla che il tuo account sia elencato come Proprietario verificato.
- Utilizza Search Console.
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
API Admin
La funzionalità non è supportata nella fase di lancio dichiarata
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'annotazione o un campo per la fase di avvio.
Per risolvere il problema, aggiungi il campo della fase di avvio alle richieste. Di seguito sono riportati alcuni esempi per l'API REST v1 e l'API REST v2:
Nell'esempio seguente viene aggiunta un'annotazione della fase di avvio a una richiesta del client utilizzando JSON e l'API REST v1:
"annotations": { "run.googleapis.com/launch-stage": "BETA" }
Nell'esempio seguente viene aggiunto un riferimento LaunchStage a una richiesta del client utilizzando JSON e l'API REST v2:
"launchStage": "BETA"
Nell'esempio seguente viene aggiunta un'annotazione della fase di avvio a una richiesta di servizio utilizzando YAML e l'API REST v1:
kind: Service metadata: annotations: run.googleapis.com/launch-stage: BETA
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 container Cloud Run.
La soluzione consiste nell'utilizzare WebSocket o HTTP/2.0, che propagano le disconnessioni del client.
Risoluzione dei problemi relativi al file system di rete
Scopri di più sull'utilizzo dei file system di rete.
Impossibile accedere ai file utilizzando NFS
Errore | Rimedio suggerito |
---|---|
mount.nfs: Protocol not supported |
In alcune immagini di base, ad esempio debian e adoptopenjdk/openjdk11 , manca la dipendenza nfs-kernel-server. |
mount.nfs: Connection timed out |
In caso di timeout della connessione, assicurati di fornire l'indirizzo IP corretto dell'istanza del datastore. |
mount.nfs: access denied by server while mounting IP_ADDRESS:/FILESHARE |
Se il server ha negato l'accesso, 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.