Le connessioni SSH non riescono durante l'avvio a freddo di un servizio Cloud Run multi-container

Quando una connessione SSH avvia a freddo un servizio Cloud Run multi-container con ordine di avvio dei container (container-dependencies), la richiesta viene instradata prima che l'ambiente del container sia pronto. Cloud Run restituisce un errore HTTP 500 e arresta immediatamente la nuova istanza. Se ti connetti utilizzando Google Cloud CLI, il comando non va a buon fine.

Per risolvere questo problema, connettiti utilizzando SSH solo quando un'istanza è già in esecuzione. Ad esempio, invia prima una richiesta al servizio per avviare un'istanza o configura istanze minime.

Le operazioni di lunga durata per l'attivazione o la disattivazione di SSH sulle istanze Cloud Run potrebbero essere restituite in anticipo

Le operazioni a lunga esecuzione (LRO) per l'attivazione o la disattivazione dell'SSH sulle istanze Cloud Run potrebbero essere restituite prima del completamento dell'operazione.

Le connessioni SSH potrebbero occasionalmente non riuscire dopo l'attivazione o la disattivazione di SSH

Le connessioni SSH potrebbero non riuscire occasionalmente, in particolare dopo aver attivato o disattivato SSH. Se una connessione non riesce, riprova.

La policy di riavvio Always arresta le istanze Cloud Run quando un container esce con il codice 0

Quando una istanza Cloud Run multi-container ha la policy di riavvio impostata su Always e un container esce con il codice 0, Cloud Run arresta l'istanza anziché riavviarla.

Il flag di dipendenza del container dependsOn non funziona per le istanze Cloud Run

Il flag dependsOn per le istanze Cloud Run multi-container non è funzionante. Le dipendenze specificate tra i container nelle istanze multicontainer non vengono applicate durante l'avvio del container.

Recupero ritardato del servizio dopo la rimozione di un limite di spesa superato o la riattivazione della fatturazione

Se il tuo progetto ha superato il limite di spesa o la fatturazione è stata disattivata, le risorse Cloud Run potrebbero subire un ritardo fino a 30 minuti prima di riprendere a gestire il traffico dopo che avrai rimosso il limite di spesa o riattivato la fatturazione. Durante questo periodo, le richieste potrebbero non andare a buon fine con errori 429 o 503 (con log che indicano "La richiesta è stata interrotta perché non era disponibile alcuna istanza") o le istanze potrebbero non avviarsi.

Non esiste una soluzione alternativa manuale. Devi attendere fino a 30 minuti prima che le risorse tornino a essere integre.

I connettori VPC per i pool di worker non sono pronti per la produzione

I connettori di accesso VPC serverless con i pool di worker Cloud Run sono disponibili in anteprima e supportati solo tramite Terraform utilizzando l'API Cloud Run v2. Non è presente il supporto nella console Cloud de Confiance , Google Cloud CLI, YAML e nell'API Cloud Run v1. Inoltre, i componenti di preparazione alla produzione, come le metriche di monitoraggio, non sono supportati.

Aumento lineare della metrica di latenza dall'ingresso alla regione

Potresti notare un aumento lineare artificiale della metrica run.googleapis.com/request_latency/ingress_to_region, più comunemente quando inserisci un servizio dietro un bilanciatore del carico delle applicazioni esterno utilizzando il protocollo HTTP/2 e le connessioni vengono riutilizzate. Ciò si verifica perché il timestamp della richiesta iniziale potrebbe non aggiornarsi per le richieste successive sulla stessa connessione, mentre l'ora di arrivo regionale continua ad avanzare.

Questo pattern è un'anomalia nella generazione di report sulle metriche. Questo problema non rappresenta la latenza effettiva del piano dati, che in genere rimane bassa. La metrica si corregge quando la connessione si chiude o il contatore si azzera.

Latenza di deployment elevata in alcune regioni

La creazione o l'aggiornamento delle risorse Cloud Run potrebbe essere più lento del previsto in alcune regioni come us-central1. Se la latenza di deployment è un problema in una determinata regione, Google consiglia di eseguire il deployment in un'altra regione.

Le attività del job Cloud Run potrebbero essere contrassegnate erroneamente come riprovate

In alcune situazioni, un'attività può essere contrassegnata come riprovata, anche se l'attività è stata completata al primo tentativo. Finché il problema non viene risolto, Google consiglia di mantenere il parametro --max-retries impostato su 3 o su un valore superiore per evitare errori di esecuzione spuri.

I montaggi dei volumi non sono compatibili con Config Connector

Se esegui il deployment del servizio o del job Cloud Run con Config Connector, i montaggi dei volumi non verranno preservati al successivo deployment. Potresti anche riscontrare problemi durante l'utilizzo di Config Connector con servizi o job a cui sono già stati applicati i montaggi dei volumi.

La variabile di ambiente HOME è impostata su /home nell'ambiente di esecuzione di prima generazione

L'ambiente di esecuzione di prima generazione di Cloud Run imposta la variabile di ambiente HOME su /home. L'ambiente di esecuzione di seconda generazione imposta la variabile HOME sul valore in /etc/passwd per l'utente in esecuzione oppure utilizza /home se /etc/passwd non esiste o se l'utente non viene trovato in /etc/passwd.

Non puoi montare i secret su /tmp nell'ambiente di esecuzione di prima generazione

Se utilizzi l'ambiente di esecuzione di prima generazione, non puoi montare i secret direttamente su /tmp. Tuttavia, puoi montare i secret in qualsiasi sottodirectory di /tmp.

Latenza elevata delle richieste con domini personalizzati quando vengono richiamati da alcune regioni

Le richieste ai servizi Cloud Run che utilizzano domini personalizzati potrebbero avere una latenza molto elevata da alcune località. Questo problema è più evidente per i servizi Cloud Run in asia-northeast1 e us-east4. Se osservi questo problema, puoi ottenere prestazioni migliori con Cloud Load Balancing utilizzando un NEG serverless.

A volte una richiesta potrebbe essere inviata alle istanze prima che siano noti i risultati del probe di avvio

Cloud Run potrebbe utilizzare la richiesta inviata all'endpoint del servizio per avviare un'istanza. Prima che i risultati del probe di avvio siano noti, Cloud Run potrebbe anche assegnare la richiesta all'istanza. Se il probe viene superato, l'istanza elaborerà la richiesta all'indirizzo receiveTimestamp elencato nel log delle richieste di Cloud Run. Se il probe non riesce, Cloud Run registra l'errore senza inserire il codice del servizio.

I mapping di domini personalizzati richiedono URL attivi

Puoi mappare solo domini personalizzati per i servizi Cloud Run che hanno un URL predefinito. Finché il problema non viene risolto, se hai disattivato l'URL predefinito, ti consigliamo di attivare l'URL predefinito, mappare il dominio personalizzato e poi disattivare di nuovo l'URL predefinito.

L'accesso VPC serverless non supporta IPv6

Non puoi utilizzare IPv6 quando invii traffico tramite i connettori di accesso VPC serverless. IPv6 è supportato quando il traffico VPC diretto in uscita utilizza subnet dual-stack o quando si accede a endpoint non VPC mentre vpc-egress è impostato su private-ranges-only.

Indirizzi IP non chiaramente identificati quando sono in uso da serverless

Quando utilizzi l'uscita VPC diretto, puoi identificare gli indirizzi IP riservati da Cloud Run attualmente in uso, visualizzati come None anziché Serverless nella pagina Indirizzi IP della console Cloud de Confiance .

Percorsi dell'URL riservati

• Percorsi che iniziano con /_ah/
• Alcuni percorsi che terminano con z. Per evitare conflitti con i percorsi riservati, ti consigliamo di evitare tutti i percorsi che terminano con z

Alcuni caratteri dell'URL codificato vengono decodificati

Cloud Run decodifica alcuni caratteri codificati nell'URL dei servizi Cloud Run prima di raggiungere l'istanza del container. Ad esempio, %41 viene decodificato automaticamente in A.

Servizi non supportati

HTTP/2 Push

Cloud Run supporta HTTP/2, ma non HTTP/2 Server Push.

Metodi HTTP

Cloud Run non supporta le richieste con metodi HTTP come TRACE e CONNECT. Di conseguenza, questi metodi non vengono ricevuti dai servizi in esecuzione su Cloud Run.

Le connessioni Cloud SQL integrate non sono disponibili per i job Cloud Run eseguiti con più container.

La funzionalità Cloud Run di connessione alle istanze Cloud SQL non è supportata per i job Cloud Run in esecuzione con più container. I job continueranno a essere eseguiti, ma Cloud Run non monterà la directory /cloudsql all'interno dei container.