Risolvi i problemi di Cloud Run

Questa pagina mostra come risolvere i messaggi di errore quando utilizzando Cloud Run.

Puoi anche verificare la presenza di problemi esistenti o aprirne di nuovi nel Issue Tracker pubblici.

Per altri messaggi di errore non elencati in questa pagina, controlla 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:

  1. Verificare di poter esegui l'immagine container in locale. Se le tue l'immagine container non può essere eseguita localmente, devi diagnosticare e risolvere il problema a livello locale.

  2. Verifica se il container resta in ascolto delle richieste su come documentato contratto di runtime del container. Il container deve rimanere in ascolto delle richieste in entrata sulla porta definita da Cloud Run e fornito nella variabile di ambiente PORT. Consulta Configurazione dei container per le istruzioni su come specificare la porta.

  3. Controllare se il container è in ascolto su tutti interfacce di rete, comunemente indicate come 0.0.0.0.

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

  5. Utilizzare Cloud Logging per cerca errori dell'applicazione nei log stdout o stderr. Puoi anche cerca gli arresti anomali rilevati in Error Reporting.

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

Errore interno, scadenza per l'idoneità delle risorse superata

Il seguente errore si verifica quando provi a eseguire il deployment o a chiamare un altro API Google Cloud:

The server has encountered an internal error. Please try again later. Resource readiness deadline exceeded.

Questo problema può verificarsi quando l'istanza di Cloud Run agente di servizio non esiste o non esiste. dispongono del ruolo di agente di servizio Cloud Run (roles/run.serviceAgent).

Per verificare che l'agente di servizio Cloud Run esista nel tuo un progetto Google Cloud e dispone del ruolo necessario, segui questi passaggi:

  1. Apri la console Google Cloud:

    Vai alla pagina Autorizzazioni

  2. Nell'angolo in alto a destra della pagina Autorizzazioni, seleziona la casella di controllo Includi Casella di controllo Concessioni dei ruoli fornita da Google.

  3. Nell'elenco Entità, individua l'ID del servizio Cloud Run. che utilizza l'ID
    service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com.

  4. Verifica che l'agente di servizio disponga dell'agente di servizio Cloud Run. ruolo. Se l'agente di servizio non ha questo ruolo, grant.

Errore utente "root" non trovato 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:

Per risolvere il problema:

  1. Specifica un account di servizio utilizzando il flag gcloud --service-account.
  2. Verifica che l'account di servizio specificato abbia autorizzazioni richieste per il deployment.

Se vuoi verificare se l'agente di servizio Compute Engine predefinito esiste in del tuo progetto Google Cloud, segui questi passaggi:

  1. Apri la console Google Cloud:

    Vai alla pagina Autorizzazioni

  2. Nell'angolo in alto a destra della pagina Autorizzazioni, seleziona la casella di controllo Includi Casella di controllo Concessioni dei ruoli fornita da Google.

  3. Nell'elenco Entità, individua l'ID del 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

Si verifica il seguente errore quando provi a eseguire il deployment da PROJECT-ID utilizzando un'immagine archiviata in Container Registry 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 il deployment di 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 Controlli di servizio VPC perimetro con una restrizione sull'API Cloud Storage che vieta dall'agente di servizio Cloud Run. Per risolvere il problema:

    1. Apri Esplora log nella console Google Cloud. (Non utilizzare pagina Log nella 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 vedi voci di log, esamina il log per determinare se è necessario aggiornare i criteri dei Controlli di servizio VPC. Potrebbero indicare che devi aggiungere service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com in base 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:

  1. Assicurati che il file system del container non contenga caratteri non utf8.

  2. Alcune immagini Docker basate su Windows utilizzano strati stranieri. Anche se Container Registry non genera un errore quando gli strati estranei sono presenti, non sono supportati dal piano di controllo di Cloud Run. A risolvi, 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 su come 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 richiamato da un account di servizio, la rivendicazione del pubblico (aud) del token ID firmato da Google deve essere impostata come segue:

    • L'URL Cloud Run del servizio ricevente, utilizzando modulo https://service-xyz.run.app.
      • Il servizio Cloud Run deve richiedere l'autenticazione.
      • Il servizio Cloud Run può essere richiamato dall'istanza 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 la proprietà modulo nnn-xyz.apps.googleusercontent.com.
    • Un segmento di pubblico personalizzato configurato utilizzando gli esatti valori forniti. Ad esempio: Se il segmento di pubblico personalizzato è service.example.com, il valore della rivendicazione del pubblico (aud) deve anche essere service.example.com. Se il segmento di pubblico personalizzato è https://service.example.com, il valore della rivendicazione del pubblico deve anche essere https://service.example.com.

  • 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 è di un formato valido e manca il membro IAM utilizzato per generare il token l'autorizzazione run.routes.invoke, si verifica un errore 403.

  • Quando utilizzi il server di metadati per recuperare l'ID e i token di accesso per autenticare le richieste con il servizio o il job Cloud Run con un proxy HTTP per instradare il traffico in uscita e otterrai non validi, assicurati di aggiungere i seguenti host Eccezioni per il proxy HTTP:

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

    Questo errore si verifica solitamente quando librerie client di Cloud utilizza il server di metadati per recuperare le credenziali predefinite dell'applicazione per autenticare le chiamate REST o gRPC. Se non definisci il proxy HTTP fanno eccezione i seguenti comportamenti:

    • Se il servizio o il job Cloud Run e il proxy HTTP sono ospitati in diversi carichi di lavoro Google Cloud, anche se il client Le librerie possono ottenere le credenziali, i token vengono generati di account di servizio assegnato al carico di lavoro del proxy HTTP, che potrebbe non Disporre delle autorizzazioni necessarie per eseguire l'API Google Cloud prevista. operations. In questo caso, i token vengono recuperati dalla vista del carico di lavoro del proxy HTTP, invece che in Cloud Run.

    • Se il proxy HTTP non è ospitato su Google Cloud e sul server di metadati vengono indirizzate utilizzando il proxy, le richieste di token non andranno a buon fine le operazioni delle API Google Cloud non saranno 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 il problema quando resource.type = "cloud_run_revision" L'errore di Cloud Logging è presente:

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

  • È possibile restituire un codice di stato 403 quando un servizio è in ingress. configurato su All, ma è stato bloccato a causa dei Controlli di servizio VPC. Consulta le sezione successiva sugli errori 404 per ulteriori informazioni sulla risoluzione dei problemi. 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:

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, non contiene il token di autorizzazione dell'utente chiamante. Da risolvere Per questo problema, scegli uno dei seguenti rimedi:

  • Utilizza Identity-Aware Proxy (IAP) con Cloud Run. IAP ti consente di definire e il 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é a livello di rete. Per maggiori dettagli sulla configurazione Cloud Run con IAP, vedi Abilitazione di Identity-Aware Proxy per Cloud Run.

  • Come soluzione alternativa temporanea, accedi al servizio tramite un browser web utilizzando la Proxy Cloud Run in Google Cloud CLI. Puoi usare il proxy per un servizio localmente utilizzando:

    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 completamente gestito di Google Cloud. È utile per i test o quando il servizio è un su un'API pubblica o su un sito web pubblico.

HTTP 404: non trovata

Durante la pubblicazione si verifica il seguente problema:

Si è verificato un errore HTTP 404.

Per risolvere il problema:

  1. Verifica che l'URL richiesto sia corretto controllando il servizio dei dettagli nella console Google Cloud o eseguendo questo comando:

    gcloud run services describe SERVICE_NAME | grep URL

  2. Controlla dove la logica dell'app potrebbe restituire codici di errore 404. Se le tue restituisce l'oggetto 404, questo sarà visibile in Cloud Logging.

  3. Assicurati che la tua app non inizi ad ascoltare prima sulla porta configurata è pronto a ricevere richieste.

  4. Verifica che l'app non restituisca il codice di errore 404 quando eseguirlo localmente.

Viene restituito un 404 quando Cloud Run Le impostazioni del traffico in entrata sono impostate su "Interno" o "Interno e Cloud Load Balancing" e la richiesta non genera che soddisfano la restrizione di rete specificata. In questo scenario, la richiesta non raggiunge il container e 404 non è presente Cloud Logging con il filtro seguente:

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 Controlli di servizio VPC basati sul contesto del chiamante, inclusi progetto e indirizzo IP. Per verificare la presenza di una violazione delle norme dei Controlli di servizio VPC:

  1. Apri Esplora log nella console Google Cloud (non i 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 vedi voci di log, esamina il log per determinare se è necessario aggiornare i Controlli di servizio VPC criteri.

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 "Conteggio istanze container" metrica per e ti consigliamo di aumentare questo limite se il tuo utilizzo sta per raggiungere il limite massimo. Vedi "istanza massima" impostazioni e se 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 l'elaborazione 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 i nuovi tentativi per le richieste che il client non deve abbandonare.

Tieni presente che un breve e improvviso aumento del traffico o del tempo di elaborazione delle richieste potrebbe saranno visibili in Cloud Monitoring solo se aumenti lo zoom fino a una risoluzione di 10 secondi.

Se la causa principale del problema è un periodo di gravi errori temporanei attribuibile esclusivamente a Cloud Run, puoi contattare Assistenza.

HTTP 501: operazione non implementata

Durante l'elaborazione 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 la chiamata del tuo job Cloud Run. Ad esempio, questo errore può verificarsi quando esegui il deployment di un job nella regione asia-southeast1 e richiami job utilizzando southeast1-asia o asia-southeast. Per l'elenco delle vedi Località di Cloud Run.

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 delle credenziali non validi o variabili di ambiente non corrette i compiti assegnati.

Per risolvere il problema:

  1. Installa e inizializza gcloud CLI.

  2. Configura le credenziali predefinite dell'applicazione (ADC) con le credenziali associati 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 memorizzate in il file delle credenziali locali utilizzata da ADC.

  3. Utilizza la variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS per fornire 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:

  1. Determina se le istanze di container superano la memoria disponibile. Cerca gli errori correlati nei log varlog/system.
  2. Se le istanze superano la memoria disponibile, considera aumentando il limite di memoria.

Tieni presente che in Cloud Run, i file scritti nel file system locale contano per la memoria disponibile. Sono inclusi anche i file di log scritti e località 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 cercarlo di errori di memoria nei log. Se ricevi messaggi di errore relativi al contenitore che superano i limiti di memoria, segui 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, potresti dover aggiornare l'impostazione di timeout della richiesta per la tua lingua :

  • Collo di bottiglia della rete downstream In alcuni casi, un codice di errore 503 può derivare indirettamente da una di un collo di bottiglia della rete downstream, ad esempio durante i test di carico. Per Ad esempio, se il tuo servizio instrada il traffico attraverso Connettore di accesso VPC serverless, assicurati che abbia non abbia superato la soglia di velocità effettiva seguendo questa procedura:

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

      Vai all'accesso VPC serverless

    2. Controlla la presenza di barre rosse nella velocità effettiva di un istogramma di un grafico. Se è presente una barra rossa Valuta la possibilità di aumentare il numero massimo di istanze o il tipo di istanza del tuo connettore utilizzi. In alternativa, comprimi il traffico inviato tramite un Connettore di accesso VPC serverless.

  • Limite di richieste in entrata verso un singolo contenitore. Esiste un problema noto in cui esistono percentuali di richieste elevate per container che comporterà questo errore di 503. Se un'istanza di container riceve più di 800 richieste al secondo, è possibile esaurire i socket TCP disponibili. A Risolvi il problema, prova una delle seguenti soluzioni:

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

    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 della 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 richieste e, di conseguenza, le istanze di container non sono in grado di elaborare quindi 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 aumenta il timeout della richiesta. Se le tue servizio non restituisce una risposta entro il tempo specificato, la richiesta termina e il servizio restituisce un errore HTTP 504, come documentato contratto di runtime del container.

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

  • Logging e tracciamento degli strumenti per capire dove si trovano prima di superare il timeout della richiesta configurato.

  • Le connessioni in uscita vengono reimpostate a causa degli aggiornamenti dell'infrastruttura. Se la tua applicazione riutilizza connessioni, ti consigliamo di configurare l'applicazione 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 essere un indicatore che la tua applicazione sta tentando di riutilizzare una connessione inattiva blocchi di richieste fino al timeout della richiesta configurato.
    • Puoi usare un probe di attività per terminare un'istanza che restituisce errori permanenti.

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

    • Se vuoi che l'istanza di container termini nello scenario precedente, quindi configura il limite di memoria a livello di app in modo che sia maggiore di il 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 il peer nella rete e il peer chiude inaspettatamente la connessione.

Per risolvere il problema:

  • Se stai tentando di eseguire operazioni in background con la limitazione della CPU, prova a usare il "La CPU è sempre allocata" Impostazione di allocazione della CPU.

  • Assicurati di rientrare nelle timeout delle richieste in uscita. Se l'applicazione mantiene una connessione in uno stato di inattività oltre questo stato le soglie, il gateway deve raggiungere la connessione.

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

  • A volte, le connessioni in uscita vengono reimpostate grazie agli aggiornamenti dell'infrastruttura. Se la tua applicazione riutilizza connessioni, ti consigliamo di configurare l'applicazione Ristabilire le connessioni per evitare il riutilizzo di una connessione inattiva.

  • Se utilizzi un proxy HTTP per il routing dei servizi Cloud Run o per il traffico in uscita dai job e il proxy applica la durata massima della connessione, il proxy potrebbe interrompere silenziosamente le connessioni TCP a lunga esecuzione come quelle mediante il pooling di connessioni. Questo causa un errore dei client HTTP quando a riutilizzare una connessione già chiusa. Se intendi instradare il traffico in uscita tramite un proxy HTTP, assicurati devi tenere conto di questo scenario implementando la convalida della connessione, e il backoff esponenziale. Per i pool di connessioni, configura il numero massimo relativi a età della connessione, connessioni inattive e timeout della connessione inattiva.

Timeout connessione

In caso di connessione, si verificano errori di latenza o uno dei seguenti errori timeout quando si invia 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 un nuovo TCP connessione con un host remoto e la connessione impiega troppo tempo la creazione di un progetto.

  • Se instrada tutto il traffico in uscita attraverso una rete VPC, utilizzando connettori VPC o Traffico 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 traffico proveniente dai connettori VPC o dal VPC diretto in uscita per raggiungere l'host o la subnet di destinazione.

    • Disporre di tutte le route necessarie per consentire il corretto instradamento del traffico verso la host di destinazione e viceversa. Questo è importante quando si instrada il traffico in uscita attraverso il peering di rete VPC connettività cloud ibrida, mentre i pacchetti passano su più reti prima di raggiungere l'host remoto.

  • Se utilizzi un proxy HTTP per instradare tutto il traffico in uscita dal tuo Cloud Run o i job di Cloud Run, assicurati che gli host remoti siano raggiungibile tramite il proxy.

    Il traffico instradato tramite un proxy HTTP potrebbe subire ritardi a seconda del dell'uso delle risorse del proxy. Se si instrada il traffico HTTP in uscita utilizzando un proxy assicurati di tenere conto di questo scenario implementando nuovi tentativi, il backoff esponenziale o gli interruttori di sicurezza.

Configura eccezioni proxy HTTP

Quando utilizzi un proxy HTTP per instradare i servizi o i job Cloud Run traffico in uscita, assicurati di aggiungere eccezioni per le API Cloud, e altri host e subnet senza proxy per prevenire latenza, timeout della connessione, reimpostazioni della connessione ed errori di autenticazione.

Gli host e le subnet senza proxy devono includere almeno quanto segue:

  • 127.0.0.1
  • 169.254.* o 169.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

Metodi comuni per configurare le eccezioni del proxy HTTP per il networking in uscita include:

  • Variabili di ambiente: NO_PROXY o no_proxy.

  • Flag Java Virtual Machine 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 con corrispondenza del 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 nei seguenti casi:

  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 prova a utilizzare il token ID per richiamare una dal servizio Cloud Run.

Si tratta del comportamento previsto. Google rimuove la firma del token per problemi di sicurezza per impedire a qualsiasi servizio Cloud Run non pubblico di ripetere i token ID. generati in questo modo.

Per risolvere il problema, richiama il tuo servizio privato con un nuovo token ID. Consulta testare l'autenticazione nel servizio per ulteriori informazioni.

Avviso OpenBLAS nei log

Se utilizzi sistemi basati su OpenBLAS come NumPy con le librerie nell'ambiente di esecuzione di prima generazione, potresti vedere 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 restituisce perché la sandbox del container usata dall'ambiente di esecuzione di prima generazione non espone funzionalità hardware di basso livello. In via facoltativa, passare all'ambiente di esecuzione di seconda generazione se non vuoi che questi avvisi si trovino nei tuoi 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 variabile SPARK_LOCAL_IP se non è configurato, utilizzerà per impostazione predefinita la rispettiva controparte IPv6 anziché localhost. Nota l'impostazione RUN export SPARK_LOCAL_IP="127.0.0.1" non sarà disponibile e Spark si comporta 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 richiede in genere circa 15 minuti, ma potrebbero essere necessarie fino a 24 ore.

  • Verifica di aver aggiornato correttamente i record DNS del tuo dominio utilizzando lo Strumento di scavo degli Strumenti amministrativi Google

    I record DNS nel registrar del dominio devono corrispondere a quelli Console Google Cloud ti chiede di aggiungere.

  • Conferma che la principale del dominio sia stata verificata con il tuo account utilizzando uno dei seguenti metodi:

  • Verifica che il certificato per il dominio non sia scaduto. Per trovare il 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 versione beta senza specificare un'annotazione o un campo nella fase di avvio.

Per risolvere il problema, aggiungi il campo della fase di avvio alle richieste. Inferiore 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 propagate 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ù su Utilizzo di 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.