Questa guida fornisce le best practice per la progettazione, l'implementazione, il test e il deployment di un servizio di pubblicazione Knative. Per ulteriori suggerimenti, consulta la sezione Migrazione di un servizio esistente.
Scrivere servizi efficaci
Questa sezione descrive le best practice generali per la progettazione e l'implementazione di un servizio di pubblicazione Knative.
Attività in background evitate
Quando un'applicazione in esecuzione sulla pubblicazione Knative termina di gestire una richiesta, l'accesso dell'istanza di container alla CPU viene disabilitato o gravemente limitato. Pertanto, non devi avviare thread o routine in background che vengono eseguiti al di fuori dell'ambito dei gestori delle richieste.
L'esecuzione di thread in background può causare comportamenti imprevisti perché qualsiasi richiesta successiva alla stessa istanza di container ripristina qualsiasi attività in background sospesa.
L'attività in background è tutto ciò che accade dopo che la risposta HTTP è stata inviata. Esamina il codice per assicurarti che tutte le operazioni asincrone terminino prima di inviare la risposta.
Se sospetti che possa esserci attività in background nel tuo servizio che non è prontamente evidente, puoi controllare i tuoi log: cerca qualsiasi cosa venga registrato dopo la voce della richiesta HTTP.
Eliminazione dei file temporanei in corso...
Nell'ambiente Cloud Run, l'archiviazione su disco è un file system in memoria. I file scritti su disco utilizzano memoria altrimenti disponibile per il tuo servizio e possono rimanere in sospeso tra una chiamata e l'altra. La mancata eliminazione di questi file potrebbe causare un errore di esaurimento della memoria e un successivo avvio a freddo.
Ottimizzazione del rendimento
Questa sezione descrive le best practice per ottimizzare il rendimento.
Avvio rapido dei servizi
Poiché le istanze di container vengono scalate secondo necessità, un metodo tipico è inizializzare completamente l'ambiente di esecuzione. Questo tipo di inizializzazione è chiamato "avvio a freddo". Se una richiesta client attiva un avvio a freddo, l'avvio dell'istanza di container genera una latenza aggiuntiva.
La routine di avvio è costituita da:
- Avvio del servizio
- Avvio del container in corso...
- Esegui il comando entrypoint per avviare il server.
- Controllo della porta di servizio aperta in corso.
L'ottimizzazione per la velocità di avvio del servizio riduce al minimo la latenza che ritarda la gestione delle richieste di un'istanza di container.
Usa le dipendenze in modo saggio
Se utilizzi un linguaggio dinamico con librerie dipendenti, ad esempio importando moduli in Node.js, il tempo di caricamento di questi moduli aumenta la latenza durante un avvio a freddo. Riduci la latenza di avvio nei seguenti modi:
- Riduci al minimo il numero e la dimensione delle dipendenze per creare un servizio sottile.
- Carica lentamente il codice usato raramente, se supportato dal tuo linguaggio.
- Usa ottimizzazioni del caricamento del codice come l'ottimizzazione del caricatore automatico dei composer di PHP.
Utilizzo delle variabili globali
Nella pubblicazione Knative, non puoi presumere che lo stato del servizio venga conservato tra le richieste. Tuttavia, la pubblicazione di Knative riutilizza singole istanze di container per gestire il traffico in corso, quindi puoi dichiarare una variabile in ambito globale per consentire il riutilizzo del relativo valore nelle chiamate successive. Non è possibile sapere in anticipo se ogni singola richiesta riceva il vantaggio di questo riutilizzo.
Puoi anche memorizzare nella cache gli oggetti che sono costosi da ricreare per ogni richiesta di servizio. Lo spostamento dalla logica di richiesta all'ambito globale consente di ottenere prestazioni migliori.
Node.js
Python
Go
Java
Esecuzione dell'inizializzazione lazy delle variabili globali
L'inizializzazione delle variabili globali avviene sempre durante l'avvio, aumentando il tempo di avvio a freddo. Usa l'inizializzazione lazy per gli oggetti usati raramente, al fine di rinviare il costo in termini di tempo e ridurre i tempi di avvio a freddo.
Node.js
Python
Go
Java
Ottimizzazione della contemporaneità
Le istanze di gestione Knative possono gestire più richieste contemporaneamente, "contemporaneamente", fino a una contemporaneità massima configurabile.
È diverso da Cloud Functions, che utilizza concurrency = 1
.
Dovresti mantenere l'impostazione predefinita per la contemporaneità massima, a meno che il tuo codice non abbia requisiti di contemporaneità specifici.
Ottimizzazione della contemporaneità per il tuo servizio
Il numero di richieste in parallelo che ogni istanza di container può essere gestita da ogni istanza di container può essere limitato dallo stack tecnologico e dall'uso di risorse condivise come variabili e connessioni ai database.
Per ottimizzare il servizio per la massima contemporaneità stabile:
- Ottimizza le prestazioni dei servizi.
- Imposta il livello previsto di supporto della contemporaneità in qualsiasi configurazione di contemporaneità a livello di codice. Non tutti gli stack tecnologici richiedono un'impostazione di questo tipo.
- Esegui il deployment del servizio.
- Imposta la contemporaneità della pubblicazione Knative per il tuo servizio in modo uguale o inferiore a qualsiasi configurazione a livello di codice. In assenza di una configurazione a livello di codice, utilizza la contemporaneità prevista.
- Utilizza strumenti di test del carico che supportano una contemporaneità configurabile. Devi confermare che il tuo servizio rimanga stabile, nel rispetto del carico e della contemporaneità previsti.
- Se il servizio funziona in modo scadente, vai al passaggio 1 per migliorare il servizio o al passaggio 2 per ridurre la contemporaneità. Se il servizio funziona, torna al passaggio 2 e aumenta la contemporaneità.
Continua a ripetere l'iterazione fino a trovare il massimo della contemporaneità stabile.
Abbinamento di memoria e contemporaneità
Ogni richiesta gestita dal tuo servizio richiede una certa quantità di memoria aggiuntiva. Pertanto, quando aumenti o riduci la contemporaneità, assicurati di regolare anche il limite di memoria.
Come evitare lo stato globale modificabile
Se vuoi utilizzare lo stato globale modificabile in un contesto simultaneo, esegui passaggi aggiuntivi nel codice per assicurarti che l'operazione venga eseguita in modo sicuro. Riduci al minimo la contesa limitando le variabili globali all'inizializzazione e al riutilizzo una tantum, come descritto sopra nella sezione Prestazioni.
Se utilizzi variabili globali modificabili in un servizio che gestisce più richieste contemporaneamente, assicurati di utilizzare blocchi o mutex per evitare racecondition.
Sicurezza dei container
Molte pratiche di sicurezza del software per uso generico si applicano alle applicazioni containerizzate. Esistono alcune pratiche specifiche per i container o in linea con la filosofia e l'architettura dei container.
Per migliorare la sicurezza dei container:
Utilizza immagini di base gestite attivamente e sicure come immagini di base di Google o immagini ufficiali di Docker Hub.
Applica gli aggiornamenti della sicurezza ai tuoi servizi ricreando regolarmente le immagini dei container ed eseguendo nuovamente il deployment dei servizi.
Includi nel container solo ciò che è necessario per eseguire il tuo servizio. Codice, pacchetti e strumenti aggiuntivi sono potenziali vulnerabilità per la sicurezza. Vedi sopra l'impatto sul rendimento correlato.
Implementare un processo di compilazione deterministico che includa versioni specifiche di software e librerie. In questo modo il codice non verificato viene incluso nel container.
Imposta il container in modo che venga eseguito come utente diverso da
root
con l'istruzione DockerfileUSER
. Per alcune immagini container potrebbe essere già configurato un utente specifico.
Automatizzare la scansione della sicurezza
Attiva l'analisi delle vulnerabilità per l'analisi di sicurezza delle immagini container archiviate in Artifact Registry.
Puoi anche utilizzare Autorizzazione binaria per garantire che venga eseguito il deployment solo delle immagini container sicure.
Creazione di immagini container minime
Le immagini container di grandi dimensioni aumentano probabilmente le vulnerabilità di sicurezza perché contengono più di ciò di cui il codice ha bisogno.
Nella pubblicazione con Knative, le dimensioni dell'immagine container non influiscono sull'avvio a freddo o sui tempi di elaborazione delle richieste e non vengono conteggiati ai fini della memoria disponibile del container.
Per creare un container minimo, valuta la possibilità di lavorare da un'immagine di base sottile come:
Ubuntu ha dimensioni maggiori, ma è un'immagine di base di uso comune con un ambiente server pronto all'uso più completo.
Se il tuo servizio ha un processo di compilazione che richiede molti strumenti, valuta la possibilità di utilizzare build multifase per mantenere il container leggero in fase di esecuzione.
Queste risorse forniscono ulteriori informazioni sulla creazione di immagini container sottili:
- Best practice per la creazione di container
- Best practice per Kubernetes: come e perché creare immagini container di piccole dimensioni
- 7 best practice per la creazione dei container