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 che preferisci e utilizzare qualsiasi immagine di base, a condizione che rispetti i vincoli elencati in questa pagina.

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

Ascolto delle richieste sulla porta corretta

Il container deve rimanere in attesa 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 per inviare le richieste alla porta che preferisci.

All'interno delle istanze di container 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 alcun protocollo TLS (Transport Layer Security). 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 di 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 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 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 file system

Il file system del container è scrivibile ed è soggetto al seguente comportamento:

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

Ciclo di vita dell'istanza di 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 scalata al numero minimo di istanze di container configurato (zero per impostazione predefinita).

Avvio

Le istanze container devono essere 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 aspettarti di poter eseguire il calcolo solo nell'ambito di una richiesta: a un'istanza di container non viene allocata alcuna CPU se non sta elaborando una richiesta.

Arresto

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

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

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

Risorse dell'istanza di 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 calcolo disponibili per il tuo 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 calcolo 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ò tentare di utilizzare più RAM.

CPU

Per impostazione predefinita, il proxy sidecar della coda riserva 25 millicpu e non esiste un limite alla quantità di vCPU che i tuoi servizi Knative 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 astrazione dell'hardware sottostante per fornire il tempo CPU equivalente approssimativo di un singolo hyperthread hardware su piattaforme CPU variabili. L'istanza del container può essere eseguita su più core contemporaneamente. La vCPU viene allocata solo durante l'avvio dell'istanza di 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 proxy sidecar della coda non riserva memoria e non esiste un limite alla quantità di memoria che i tuoi servizi Knative serving possono utilizzare. Se vuoi, puoi configurare i limiti di memoria per i tuoi servizi Knative serving. Per saperne di più su come GKE gestisce la memoria, consulta Risorse di CPU e memoria 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
• Sistemi di memorizzazione nella cache in memoria come OpCache di PHP
• Utilizzo della memoria per richiesta

Contemporaneità

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

Sandbox dell'istanza di container

Knative serving non utilizza una sandbox del container.

Server metadati dell'istanza di container

Le istanze container di Knative Serving espongono un server di metadati che puoi utilizzare per recuperare i dettagli sull'istanza container, come l'ID progetto, la regione, l'ID istanza o i service account.

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 saperne di più, consulta la sezione 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 Knative serving
/computeMetadata/v1/instance/region	Regione di questo servizio Knative serving
/computeMetadata/v1/instance/id	Identificatore univoco dell'istanza del contenitore (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