Contratto runtime container

Questa pagina elenca i requisiti e i comportamenti chiave dei container in 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 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 contenitore non deve implementare direttamente alcuna sicurezza del livello di trasporto. 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 del contenitore deve inviare una risposta entro il tempo specificato nell'impostazione di timeout della richiesta dopo aver ricevuto una richiesta, incluso il tempo di avvio dell'istanza del contenitore. 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 containers:

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 di Knative serving che ha creato la revisione.	hello-world

Accesso al file system

Il file system del contenitore è scrivibile ed è soggetto al seguente 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 dell'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 base al 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 aspettarti di poter eseguire calcoli solo nell'ambito di una richiesta: a un'istanza del contenitore non viene allocata alcuna CPU se non sta elaborando una richiesta.

Arresto

Un'istanza del contenitore può essere arrestata in qualsiasi momento.

Quando è necessario arrestare un'istanza di container, le nuove richieste in arrivo vengono indirizzate ad altre istanze e alle richieste in fase di elaborazione viene concesso il tempo di completarsi. 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 del contenitore non riceve 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 delle istanze di 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, il sidecar proxy della coda riserva 25 milliCPU e non esiste un limite alla quantità di vCPU che i servizi di pubblicazione Knative possono utilizzare. 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 del contenitore 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 vCPU diverso, consulta la documentazione relativa all'allocazione delle CPU.

Memoria

Per impostazione predefinita, file collaterale proxy di coda non riserva memoria e non c'è limite alla quantità di memoria che utilizzabili dai servizi Knative serving. Se vuoi, puoi configurare i limiti di memoria per i 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 nella memoria per eseguire il servizio
• Scrittura nel file system
• Processi aggiuntivi in esecuzione nel contenitore, ad esempio un server nginx
• I sistemi di memorizzazione nella cache come PHP OpCache
• Utilizzo della memoria per richiesta

Contemporaneità

Per impostazione predefinita, ogni istanza di container di servizio Knative è impostata su più contemporaneità, in cui ogni istanza di container 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.

La seguente tabella elenca alcune delle informazioni sul 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 del contenitore (disponibile anche in logs).
/computeMetadata/v1/instance/service-accounts/default/token	Genera un token per l'account di servizio di runtime di questo servizio Knative serving