Contratto runtime container

Questa pagina elenca i requisiti e i comportamenti chiave dei container in Knative serving.

Linguaggi e immagini supportati

L'immagine container può eseguire codice scritto nel linguaggio di programmazione che preferisci e utilizzare qualsiasi immagine di 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. Knative serving supporta in modo specifico il formato ABI Linux x86_64.

Ascoltare le richieste sulla porta corretta

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

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

Crittografia del livello di trasporto (TLS)

Il container non deve implementare direttamente alcuna sicurezza del livello di trasporto. TLS viene terminato da Knative serving per HTTPS e gRPC, quindi le richieste vengono inviate tramite proxy come HTTP o gRPC al container senza TLS.

Risposte

L'istanza container deve inviare una risposta entro il tempo specificato nell' impostazione del timeout della richiesta dopo aver ricevuto una richiesta, incluso il tempo di avvio dell'istanza 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 deve rimanere in ascolto il server HTTP.	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 di Knative serving che ha creato la revisione.	hello-world

Accesso al filesystem

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

• Si tratta di un filesystem in memoria, quindi la scrittura utilizza la memoria dell'istanza container.
• I dati scritti nel filesystem non vengono conservati quando l'istanza container viene arrestata.

Ciclo di vita dell'istanza container

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

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

Avvio

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

Il calcolo è limitato a una richiesta

Dopo l'avvio, dovresti prevedere di poter eseguire calcoli solo nell'ambito di una richiesta: a un'istanza container non viene allocata alcuna CPU se non sta elaborando una richiesta.

Arresto

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

Quando è necessario arrestare un'istanza container, le nuove richieste in entrata vengono indirizzate ad altre istanze e alle richieste in fase di elaborazione viene concesso il tempo necessario per essere completate. L'istanza container riceve quindi un segnale SIGTERM che indica l'inizio di un periodo di 10 secondi prima dell'arresto (con un segnale SIGKILL). Durante questo periodo, all'istanza container viene allocata la CPU e viene fatturata. Se l'istanza container non rileva il segnale SIGTERM, viene arrestata immediatamente.

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

Risorse dell'istanza container

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

Pertanto, la quantità di risorse di computing disponibile per un servizio Knative serving è limitata solo dalla quantità di risorse disponibili in quel nodo. Scopri di più sulle risorse di computing per le richieste.

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

CPU

Per impostazione predefinita, il sidecar del proxy della coda riserva 25 milliCPU e non esiste alcun limite alla quantità di vCPU che i servizi Knative serving possono utilizzare. Il consumo di risorse del proxy della coda dipende dal numero di richieste in coda e dalle dimensioni delle richieste.

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

Per allocare un valore di vCPU diverso, consulta la documentazione relativa all' allocazione della CPU.

Memoria

Per impostazione predefinita, il sidecar del proxy della coda non riserva memoria e non esiste alcun limite alla quantità di memoria che i servizi Knative serving possono utilizzare. Se vuoi, puoi configurare i limiti di memoria per i servizi Knative serving. Per ulteriori informazioni su come GKE gestisce la memoria, consulta Risorse di memoria e CPU allocabili.

Gli utilizzi tipici della memoria includono:

• Codice caricato in memoria per eseguire il servizio
• Scrittura nel filesystem
• 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

Concorrenza

Per impostazione predefinita, ogni istanza container di Knative serving è impostata su concorrenza multipla, in cui ogni istanza container può ricevere più di una richiesta contemporaneamente. Puoi modificare questa impostazione impostando la concorrenza.

Sandbox dell'istanza container

Knative serving non utilizza una sandbox container.

Server di metadati dell'istanza container

Le istanze container di Knative serving espongono un server di metadati che puoi utilizzare per recuperare i dettagli dell'istanza container, come l'ID progetto, la regione, 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 Recuperare i metadati.

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

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