Risolvi i problemi di Cloud Run

Questa pagina mostra come risolvere i problemi relativi a Cloud Run.

Per altri problemi non elencati di seguito, verifica se potrebbero trattarsi di un problema noto.

Errori di deployment

Questa sezione elenca i problemi che potresti riscontrare durante l'implementazione 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, escludi le seguenti potenziali cause:

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

  2. Controlla se il container è in ascolto delle 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 istruzioni su come specificare la porta.

  3. Verifica se il contenitore è in ascolto su tutte le interfacce di rete, comunemente indicate come 0.0.0.0.

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

  5. Utilizza Cloud Logging per cercare errori dell'applicazione nei log stdout o stderr. 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 per l'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 quando non dispone del ruolo Agente di servizio Cloud Run (roles/run.serviceAgent).

Per verificare che l'agente di servizio Cloud Run esista nel progetto Google Cloud e disponga del ruolo necessario, esegui 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 concessioni dei ruoli fornite da Google.

  3. 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.

  4. Verifica che l'agente di servizio disponga del ruolo Agente di servizio Cloud Run. Se l'agente di servizio non dispone di questo ruolo, concedilo.

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 chiave

Per risolvere questo 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 --service-account gcloud.
  2. 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 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 concessioni dei ruoli fornite da Google.

  3. 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 ha l'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 può verificarsi anche se il progetto si trova in un perimetro di Controlli di servizio VPC con una restrizione sull'API Cloud Storage che impedisce le richieste dell'agente di servizio Cloud Run. Per risolvere il problema:

    1. Apri Esplora log nella console Google Cloud. (Non utilizzare la pagina Log all'interno della pagina di 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, esamina le voci dei log per determinare se è necessario aggiornare i criteri dei Controlli di servizio VPC. Potrebbe indicare che è necessario aggiungere service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com a un criterio di accesso preesistente.

Errori 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, escludi 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 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 con la 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, la rivendicazione del pubblico (aud) del token ID firmato da Google deve essere impostata come 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 dall'URL di 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 modulo nnn-xyz.apps.googleusercontent.com.
    • Un segmento di pubblico personalizzato configurato che utilizza gli esatti valori forniti. Ad esempio, se il segmento di pubblico personalizzato è service.example.com, anche il valore della dichiarazione 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.

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

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

Il seguente errore potrebbe trovarsi 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" è presente l'errore di Cloud Logging:

  • Se il servizio può essere chiamato da chiunque, aggiorna le impostazioni IAM per renderlo pubblico.
  • Se il servizio deve essere chiamato solo da certe identità, assicurati di chiamarlo con il token di autorizzazione appropriato.
    • Se la chiamata da uno sviluppatore è stata richiamata o la chiamata da 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 disponga del ruolo Invoker (roles/run.invoker) di Cloud Run.
    • Alle chiamate senza un token di autenticazione o con un token di autenticazione valido in formato, ma il membro IAM utilizzato per generare il token non dispone dell'autorizzazione run.routes.invoke, genera questo errore 403.

Per risolvere questo problema, quando l'errore resource.type = "cloud_run_revision" non è presente:

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

HTTP 404: Non trovato

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 la pagina dei dettagli del servizio nella console Cloud o eseguendo questo comando:

    gcloud run services describe SERVICE_NAME | grep URL

  2. Controlla dove la logica dell'app potrebbe restituire i codici di errore 404. Se la tua app restituisce 404, sarà visibile in Cloud Logging.

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

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

Viene restituito un valore 404 quando le impostazioni in entrata di un servizio Cloud Run sono impostate su "Interno" o "Interno 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 progetto e indirizzo IP. Per verificare la presenza di una violazione dei criteri dei Controlli di servizio VPC:

  1. Apri Esplora log nella console Google Cloud (non nella 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 vedi voci di log, esamina le voci dei log per determinare se devi aggiornare o meno 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 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 ha potuto gestire la frequenza del traffico

Il seguente errore si verifica durante la gestione 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 uno dei seguenti motivi:

  • Un enorme improvviso aumento del traffico.
  • Un'ora di avvio a freddo lunga.
  • Un tempo di elaborazione della richiesta 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 breve e improvviso aumento del traffico o dei tempi di elaborazione delle richieste potrebbe essere visibile in Cloud Monitoring solo se aumenti lo zoom per una risoluzione di 10 secondi.

Se la causa principale del problema è un periodo di errori temporanei aumentati attribuibili esclusivamente a Cloud Run, puoi contattare l'assistenza

HTTP 500 / HTTP 503: le istanze di container superano 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, ti consigliamo di aumentare il limite di memoria.

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

HTTP 503: formato non corretto della risposta o problema di connessione all'istanza di container

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 vengono visualizzati messaggi di errore relativi alle 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, potresti dover aggiornare l'impostazione di timeout della richiesta per il tuo framework di linguaggio:

  • 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 questi passaggi:

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

      Vai all'accesso VPC serverless

    2. Controlla se sono presenti barre red nell'istogramma del grafico relativo alla velocità effettiva. Se è presente una barra red, valuta la possibilità di aumentare il numero massimo di istanze o il tipo di istanza utilizzato dal connettore. In alternativa, comprimi il traffico inviato tramite un connettore di accesso VPC serverless.

  • Limite di richieste in entrata per un singolo container Si è verificato un problema noto in cui sono presenti percentuali di richieste elevate per container che generano 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 operazioni:

    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 di un'impostazione di contemporaneità 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 elaborare tutte le richieste e, di conseguenza, 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 documentato nel contratto di runtime del container.

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

  • Strumento di logging e tracciamento per capire dove trascorre il tempo la tua app 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 in modo da evitare il riutilizzo di connessioni non attive.

    • 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 che la richiesta si blocca fino al timeout della richiesta configurata.
    • Puoi utilizzare un probe di attività per terminare un'istanza che restituisce errori persistenti.

  • Gli errori di memoria 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à arrestata. A seconda di come l'app gestisce gli errori di esaurimento della memoria a livello di app, le richieste potrebbero bloccarsi fino al superamento del timeout della richiesta configurata.

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

Per risolvere il problema:

  • Se stai cercando di eseguire operazioni in background con la limitazione della CPU, prova a utilizzare l'impostazione "CPU sempre allocata".

  • Assicurati di essere entro i timeout delle richieste in uscita. Se l'applicazione mantiene una connessione in stato di inattività oltre questa soglia, il gateway deve acquisire nuovamente la connessione.

  • Per impostazione predefinita, l'opzione del 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 abilitare 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 stai utilizzando per questa connessione nella tua applicazione.

  • A volte, le connessioni in uscita vengono reimpostate 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 in modo da evitare il riutilizzo di connessioni non attive.

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 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 a causa di problemi di sicurezza per impedire a qualsiasi servizio Cloud Run non pubblico di riprodurre i token ID generati in questo modo.

Per risolvere il problema, richiama il servizio privato con un nuovo token ID. Per ulteriori informazioni, consulta la sezione 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, nei log potrebbe essere visualizzato il seguente avviso:

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

Questo è solo un avviso e non ha alcun impatto sul tuo servizio. Questo avviso genera perché la sandbox dei 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 quando si ottiene l'indirizzo IP della macchina da associare

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 tuo Dockerfile. In Cloud Run, se la variabile SPARK_LOCAL_IP non è impostata, verrà utilizzata per impostazione predefinita la sua controparte IPv6 anziché localhost. Tieni presente che l'impostazione RUN export SPARK_LOCAL_IP="127.0.0.1" non sarà disponibile in runtime e Spark agirà come se non fosse stata impostata.

Mapping di domini personalizzati

Il dominio personalizzato è bloccato nello stato di provisioning del certificato

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 in alcuni casi possono essere necessarie fino a 24 ore.

  • Verifica di aver aggiornato correttamente i record DNS nel registrar di domini utilizzando lo strumento di esplorazione degli Strumenti amministrativi Google

    I record DNS nel tuo registrar di dominio devono corrispondere ai messaggi che ti vengono richiesti dalla console Google Cloud.

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

  • Verifica che il certificato del 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 della fase di avvio.

Per risolvere il problema, annota alla risorsa con un valore run.googleapis.com/launch-stage pari a BETA nella richiesta se viene utilizzata qualsiasi funzionalità beta.

Nell'esempio seguente viene aggiunta un'annotazione della fase di avvio a una richiesta di servizio:

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 di 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.