Questa è la versione Archiviata della documentazione. Il periodo di prova gratuito è terminato il 30 settembre 2021.

Per informazioni dettagliate sull'installazione di Cloud Run for Anthos come componente del parco Anthos con Anthos Service Mesh, consulta la documentazione sulla versione GA.

Versioni disponibili

Più recenti
Archiviare

Contratto runtime container

Questa pagina elenca i requisiti e i comportamenti chiave dei container in Cloud Run for Anthos.

Lingue e immagini supportate

L'immagine container può eseguire il codice scritto nel linguaggio di programmazione scelto e utilizzare qualsiasi immagine base, a condizione che rispetti i vincoli elencati in questa pagina.

I file eseguibili nell'immagine container devono essere compilati per Linux a 64 bit. Cloud Run for Anthos supporta in modo specifico il formato ABI Linux x86_64.

Ascolto delle richieste sulla porta corretta

Il container deve ascoltare le richieste su 0.0.0.0 nella porta a cui vengono inviate le richieste. Per impostazione predefinita, le richieste vengono inviate a 8080, ma puoi configurare Cloud Run for Anthos per inviare richieste alla porta di tua scelta.

All'interno delle istanze del container Cloud Run for Anthos, il valore della variabile di ambiente PORT rispecchia sempre la porta a cui vengono inviate le richieste. Il valore predefinito è 8080.

Crittografia Transport Layer (TLS)

Il container non deve implementare direttamente alcun livello di sicurezza del trasporto. TLS viene terminato da Cloud Run for Anthos per HTTPS e gRPC e le richieste vengono inviate tramite proxy come HTTP o gRPC al container senza TLS.

Risposte

L'istanza di container deve inviare una risposta entro il tempo specificato nell'impostazione di timeout della richiesta dopo aver ricevuto la richiesta, incluso il momento di avvio dell'istanza di container. In caso contrario, la richiesta viene terminata e viene restituito un errore 504.

Variabili di ambiente

Le seguenti variabili di ambiente vengono aggiunte automaticamente ai container in esecuzione:

Nome	Descrizione	Esempio
`PORT`	La porta su cui il server HTTP deve rimanere in ascolto.	`8080`
`K_SERVICE`	Il nome del servizio Cloud Run for Anthos in esecuzione.	`hello-world`
`K_REVISION`	Il nome della revisione Cloud Run for Anthos in esecuzione.	`hello-world.1`
`K_CONFIGURATION`	Il nome della configurazione di Cloud Run for Anthos che ha creato la revisione.	`hello-world`

Accesso al file system

Il filesystem del container è scrivibile ed è soggetto al seguente comportamento:

Si tratta di un filesystem in memoria, quindi per scrivere viene utilizzato la memoria del container dell'istanza.
I dati scritti nel file system non vengono conservati quando l'istanza del container viene arrestata.

Ciclo di vita di un'istanza di container

In risposta alle richieste in entrata, un servizio viene scalato automaticamente a un determinato numero di istanze di container, ognuna delle quali esegue l'immagine container di cui è stato eseguito il deployment.

Quando una revisione non riceve traffico, viene scalata in base al numero minimo di istanze di container configurate (zero per impostazione predefinita).

Startup

Le istanze del container devono ascoltare le richieste entro 4 minuti dall'avvio. Durante questo tempo di avvio, alle istanze container viene allocata la CPU.

L'ambito è limitato a una richiesta

Dopo l'avvio, dovresti essere in grado di eseguire il calcolo solo nell'ambito di una richiesta: un'istanza di container non dispone di alcuna CPU allocata se non sta elaborando una richiesta.

Chiusura

Un'istanza di container può essere arrestata in qualsiasi momento.

Quando un'istanza di container deve essere arrestata, le nuove richieste in entrata vengono instradate ad altre istanze e le richieste attualmente in fase di elaborazione hanno il tempo di completamento. L'istanza di container riceve quindi un indicatore SIGTERM che indica l'inizio di un periodo di 10 secondi prima di essere arrestato (con un indicatore SIGKILL). Durante questo periodo, l'istanza di container viene allocata alla CPU e viene fatturata. Se l'istanza di container non rileva il segnale SIGTERM, viene immediatamente arrestata.

A meno che un'istanza di container non debba essere mantenuta inattiva a causa dell'impostazione di configurazione del numero minimo di istanze di container, non verrà mantenuta inattiva per più di 15 minuti.

Risorse per le istanze di container

Le richieste di risorse per le istanze di container sono programmate nei nodi del cluster GKE. Ogni nodo condivide la quantità totale di risorse di calcolo disponibili per il cluster GKE.

Pertanto, la quantità di risorse di calcolo disponibili per un servizio Cloud Run for Anthos è limitata solo alla quantità di risorse disponibili in tale nodo. Scopri di più sulle risorse di calcolo per le richieste.

Ad esempio, se assegni 512 MiB di memoria per un container e tale container è in esecuzione nell'unico pod all'interno di un nodo con 8 GiB di memoria, tale container può tentare di utilizzare più RAM.

CPU

Per impostazione predefinita, il sidecar proxy della coda prenota 25 milliCPU e non esiste alcun limite alla quantità di vCPU utilizzabile dai servizi Cloud Run for Anthos. Il consumo di risorse del proxy di coda dipende dal numero di richieste in coda e dalle dimensioni delle richieste.

Una vCPU viene implementata come astrazione dell'hardware sottostante per fornire il tempo approssimativo equivalente della CPU per un singolo hyperthread hardware su piattaforme con CPU variabile. L'istanza di container può essere eseguita su più core contemporaneamente. La vCPU viene allocata solo durante l'avvio e l'elaborazione delle richieste dei container, altrimenti è limitata.

Per allocare un valore vCPU diverso, consulta la documentazione sull'allocazione della CPU.

Memoria

Per impostazione predefinita, il sidecar proxy della coda non riserva alcuna memoria e non esiste alcun limite alla quantità di memoria che i servizi Cloud Run for Anthos possono utilizzare. Se vuoi, puoi configurare limiti di memoria per i tuoi servizi Cloud Run for Anthos. Per ulteriori informazioni su come GKE gestisce la memoria, consulta la pagina relativa alle risorse di memoria e CPU allocabili.

Tra gli utilizzi tipici della memoria sono inclusi:

Codice caricato in memoria per eseguire il servizio
Scrittura nel file system
Processi aggiuntivi in esecuzione nel container, ad esempio un server nginx
Sistemi di memorizzazione nella cache in memoria come PHP OpCache
Utilizzo della memoria per richiesta

Contemporaneità

Ogni istanza di container di Cloud Run for Anthos è impostata su più contemporaneità, ciascuna delle quali può ricevere più richieste contemporaneamente. Puoi modificare questa impostazione impostando contemporaneità.

Sandbox istanza container

Cloud Run for Anthos non utilizza una sandbox per i container.

Server di metadati dell'istanza di container

Le istanze del container Cloud Run for Anthos espongono un server di metadati che puoi utilizzare per recuperare i dettagli dell'istanza di container, ad esempio l'ID progetto, l'area geografica, l'ID istanza o gli account di servizio.

Puoi accedere a questi dati dal server di metadati utilizzando semplici richieste HTTP all'endpoint http://metadata.google.internal/ con l'intestazione Metadata-Flavor: Google: non sono richieste librerie client. Per ulteriori informazioni, consulta la pagina Recupero dei metadati.

La tabella seguente elenca alcune delle informazioni disponibili sul server di metadati:

Percorso	Descrizione
`/computeMetadata/v1/project/project-id`	ID progetto di questo servizio Cloud Run for Anthos
`/computeMetadata/v1/instance/region`	Area geografica di questo servizio Cloud Run for Anthos
`/computeMetadata/v1/instance/id`	Identificatore univoco dell'istanza di container (disponibile anche nei log).
`/computeMetadata/v1/instance/service-accounts/default/token`	Genera un token per l'account di servizio di runtime di questo servizio Cloud Run for Anthos