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

Gli eseguibili nell'immagine del contenitore 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 ascoltare le richieste su 0.0.0.0 sulla porta a cui vengono inviate. Per impostazione predefinita, le richieste vengono inviate a 8080, ma puoi configurare Knative serving in modo da inviare le 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 viene terminato dal servizio Knative per HTTPS e gRPC, quindi le richieste vengono proxy come HTTP o gRPC al contenitore 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 ai contenuti 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 contenitore è scrivibile ed è soggetto al seguente comportamento:

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

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, ciascuna delle quali esegue l'immagine del 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 del contenitore devono ascoltare le richieste entro 4 minuti dall'avvio. Durante questo tempo di avvio, alle istanze di container viene allocata la CPU.

Il calcolo è limitato a 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 segnale SIGTERM che indica l'inizio di un periodo di 10 secondi prima di essere arrestata (con un segnale SIGKILL). Durante questo periodo, all'istanza del contenitore viene allocata la CPU e viene addebitata. 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 dei container vengono pianificate nei nodi del tuo cluster GKE. Ogni nodo condivide la quantità totale di risorse di calcolo disponibili per il tuo cluster GKE.

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

Ad esempio, se assegni 512 MiB di memoria a un contenitore e questo contenitore è in esecuzione nell'unico pod all'interno di un nodo con 8 GB di memoria, il contenitore 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. 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 della CPU approssimativo equivalente di un singolo hyperthread hardware su piattaforme CPU variabili. L'istanza del contenitore 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 vCPU diverso, consulta la documentazione relativa all'allocazione delle CPU.

Memoria

Per impostazione predefinita, il sidecar proxy della coda non riserva alcuna memoria e non esiste un limite alla quantità di memoria che possono utilizzare i tuoi servizi Knative serving. Se vuoi, puoi configurare i limiti di memoria per i tuoi servizi Knative serving. Per ulteriori informazioni su come GKE gestisce la memoria, consulta Risorse di CPU e memoria 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
• Sistemi di memorizzazione nella cache in memoria come OpCache di PHP
• 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 alla volta. Puoi modificare questo valore impostando la concorrenza.

Sandbox dell'istanza di container

Knative serving non utilizza una sandbox del contenitore.

Server dei metadati delle istanze di container

Le istanze contenitore di servizio Knative espongono un server dei metadati che puoi utilizzare per recuperare i dettagli dell'istanza contenitore, ad esempio l'ID progetto, la regione, l'ID istanza o gli account di servizio.

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

La tabella seguente elenca alcune delle informazioni sui 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 di pubblicazione Knative