Contratto runtime container

In questa pagina sono elencati i requisiti e i comportamenti chiave dei container Knative serving.

Lingue e immagini supportate

L'immagine container può eseguire codice scritto nel linguaggio di programmazione del tuo e utilizzare qualsiasi immagine di base, purché rispetti i vincoli elencati in questa pagina.

Gli eseguibili nell'immagine container devono essere compilati per Linux a 64 bit. Knative serving supporta specificatamente il formato Linux x86_64 ABI.

In ascolto delle richieste sulla porta corretta

Il container deve rimanere in ascolto delle richieste su 0.0.0.0 sulla porta verso cui inviate. Per impostazione predefinita, le richieste vengono inviate a 8080, ma puoi configurare Knative serving per inviare richieste alla porta che preferisci.

All'interno delle istanze di container Knative serving, il valore del parametro PORT variabile di ambiente sempre la porta a cui vengono inviate le richieste. Il valore predefinito è 8080.

Crittografia TLS

Il container non deve implementare alcuna sicurezza del livello di trasporto direttamente. TLS è terminati da Knative serving per HTTPS e gRPC, quindi richiede vengono inviati tramite proxy come HTTP o gRPC al container senza TLS.

Risposte

L'istanza di container deve inviare una risposta entro il tempo specificato in l'impostazione di timeout della richiesta dopo riceve una richiesta, tra cui il tempo 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 al cluster container:

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

Accesso al file system

Il file system del container è scrivibile ed è soggetto ai seguenti comportamento:

• Si tratta di un file system in memoria, quindi per scriverci viene utilizzato il container di un'istanza.
• I dati scritti nel file system non vengono mantenuti quando l'istanza di container viene è stata interrotta.

Ciclo di vita di un'istanza di container

In risposta alle richieste in entrata, un servizio viene scalato automaticamente 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 numero minimo di istanze di container configurate (zero per impostazione predefinita).

Avvio

Le istanze di container devono rimanere in ascolto delle richieste all'interno 4 minuti dopo l'avvio. Durante questo tempo di avvio, alle istanze di container viene allocata la CPU.

Il calcolo è limitato all'ambito di una richiesta

Dopo l'avvio, dovresti riuscire a eseguire il calcolo solo all'interno ambito di una richiesta: a un'istanza di container non è allocata alcuna CPU non sta elaborando una richiesta.

Arresto

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

Quando un'istanza di container deve essere arrestata, le nuove richieste in entrata vengono instradato ad altre istanze e alle richieste attualmente in fase di elaborazione viene concesso per completare l'operazione. L'istanza di container riceve quindi un indicatore SIGTERM che indica l'inizio di un periodo di 10 secondi prima di essere arrestati (con un segnale SIGKILL). Durante questo periodo, all'istanza di container viene allocata la CPU e viene fatturato. Se l'istanza di container non rileva l'indicatore SIGTERM, viene arrestata immediatamente.

A meno che un'istanza di container non debba essere mantenuta inattiva a causa numero minimo di istanze di container non verrà mantenuto inattivo per più di 15 minuti.

Risorse istanza container

Le richieste di risorse per le istanze di container sono pianificate nei nodi del tuo cluster GKE. Ogni nodo condivide la quantità totale di computing disponibile per il cluster GKE.

Pertanto, la quantità di risorse di computing disponibile Il servizio Knative serving è limitato solo dalla quantità di servizi di risorse in quel nodo. Scopri di più su risorse di calcolo per le richieste.

Ad esempio, se allochi 512 MiB di memoria per un container il container è in esecuzione nell'unico pod all'interno di un nodo che ha 8 GiB di memoria, il container può provare a utilizzare più RAM.

CPU

Per impostazione predefinita, file collaterale proxy di coda prenota 25 milliCPU e non esiste alcun limite alla quantità di vCPU utilizzabili dai servizi Knative serving. In coda il consumo di risorse da parte del proxy dipende da quante richieste vengono messe in coda la dimensione delle richieste.

Una vCPU viene implementata come un'astrazione delle risorse sottostanti per fornire il tempo di CPU equivalente approssimativo di un singolo hardware hyperthread su piattaforme CPU variabili. L'istanza di container può essere eseguita su più core contemporaneamente. La La vCPU viene allocata solo durante l'avvio e la richiesta dell'istanza di container durante l'elaborazione dei dati, viene limitata altrimenti.

Per allocare un valore di vCPU diverso, consulta la documentazione relativa a allocando la CPU.

Memoria

Per impostazione predefinita, file collaterale proxy di coda non riserva memoria e non esiste alcun limite alla quantità di memoria che utilizzabili dai servizi Knative serving. Se vuoi, puoi configurare i limiti di memoria dei tuoi servizi Knative serving. Per ulteriori informazioni GKE gestisce la memoria, Risorse di memoria e CPU allocabili.

Gli utilizzi tipici della memoria includono:

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

Contemporaneità

Ogni istanza di container Knative serving per impostazione predefinita è impostata su più contemporaneità, in cui ogni container l'istanza può ricevere più di una richiesta contemporaneamente. Puoi modificare impostando la contemporaneità.

Sandbox dell'istanza di container

Knative serving non utilizza una sandbox dei container.

Server di metadati dell'istanza di container

Le istanze di container Knative serving espongono un server di metadati che puoi utilizzare per recuperare i dettagli dell'istanza di container, come l'ID progetto, regione, ID istanza o account di servizio.

Puoi accedere a questi dati dal server dei metadati utilizzando semplici richieste HTTP al Endpoint http://metadata.google.internal/ con Metadata-Flavor: Google intestazione: non sono necessarie librerie client. Per ulteriori informazioni, vedi Recupero dei metadati.

Nella tabella seguente sono elencate alcune delle informazioni disponibili sul server di metadati:

Percorso	Descrizione
/computeMetadata/v1/project/project-id	ID progetto di questo servizio Knative serving
/computeMetadata/v1/instance/region	Regione di questo servizio Knative serving
/computeMetadata/v1/instance/id	Identificatore univoco dell'istanza 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 Knative serving