Queste informazioni sono utili per i seguenti tipi di utenti:
- Utenti che iniziano a utilizzare la pubblicazione con Knative.
- Operatori con esperienza nell'esecuzione dei cluster GKE.
- Sviluppatori di applicazioni che hanno bisogno di saperne di più su come Knative Serving si integra con i cluster Kubernetes per progettare applicazioni migliori o per configurare la loro applicazione di pubblicazione Knative.
Componenti nell'installazione predefinita
Installa Knative Serving nel tuo cluster per connettere e gestire i carichi di lavoro stateless. I componenti Knative vengono creati nello spazio dei nomi knative-serving.
Knative pubblicazione utilizza Anthos Service Mesh per instradare il traffico. Per impostazione predefinita, Anthos Service Mesh installa i componenti nello spazio dei nomi istio-system.
Di seguito è riportato un elenco dei componenti installati da Knative Serving e Anthos Service Mesh:
Componenti installati da Knative nello spazio dei nomi
knative-serving:- Attivatore: quando i pod vengono scalati a zero o si sovraccaricano di richieste inviate alla revisione, l'Activator mette temporaneamente in coda le richieste e invia le metriche al gestore della scalabilità automatica per avviare altri pod. Quando il gestore della scalabilità automatica scala la revisione in base alle metriche segnalate e ai pod disponibili, l'attivatore inoltra le richieste in coda alla revisione. L'attivatore è un componente del piano dati; i componenti del piano dati gestiscono tutte le funzioni e i processi che inoltrano il traffico degli utenti.
- Gestore della scalabilità automatica: aggrega ed elabora le metriche dell'attivatore e del container collaterale proxy coda, un componente del piano dati che applica limiti di contemporaneità delle richieste. Il gestore della scalabilità automatica calcola quindi la contemporaneità osservata per la revisione e regola le dimensioni del deployment in base al numero di pod desiderato. Quando i pod sono disponibili nella revisione, il gestore della scalabilità automatica è un componente del piano di controllo; in caso contrario, quando viene fatto lo scale in dei pod a zero, il gestore della scalabilità automatica è un componente del piano dati.
- Controller: crea e aggiorna le risorse figlio del gestore della scalabilità automatica e degli oggetti di servizio. Il controller è un componente del piano di controllo; i componenti del piano di controllo gestiscono tutte le funzioni e i processi che stabiliscono il percorso di richiesta del traffico degli utenti.
- Raccoglitore metriche: raccoglie le metriche dai componenti di gestione di Knative e le inoltra a Cloud Monitoring.
- Webhook: imposta valori predefiniti, rifiuta oggetti incoerenti e non validi e convalida e modifica le chiamate API Kubernetes rispetto alle risorse di pubblicazione Knative. Il webhook è un componente del piano di controllo.
Componenti installati da Anthos Service Mesh in esecuzione nello spazio dei nomi
istio-system:- Gateway locale del cluster: bilanciatore del carico nel piano dati responsabile della gestione del traffico interno che arriva da un servizio di pubblicazione Knative a un altro. È possibile accedere al gateway locale del cluster solo dall'interno del cluster GKE e non registra un dominio esterno per evitare l'esposizione accidentale di informazioni private o processi interni.
- Gateway Ingress Istio: bilanciatore del carico nel piano dati responsabile della ricezione e della gestione del traffico in entrata dall'esterno del cluster, compreso il traffico proveniente da reti esterne o interne.
- Istiod: configura il gateway locale del cluster e il gateway in entrata Istio per gestire le richieste HTTP negli endpoint corretti. Istiod è un componente del piano di controllo. Per ulteriori informazioni, vedi Istiod.
I componenti di gestione di Knative vengono aggiornati automaticamente con gli aggiornamenti dei cluster del piano di controllo GKE. Per ulteriori informazioni, consulta Versioni di GKE disponibili.
Utilizzo delle risorse del cluster
L'installazione iniziale per la gestione di Knative richiede circa 1,5 CPU virtuale e 1 GB di memoria per il tuo cluster. Il numero di nodi nel cluster non influisce sui requisiti di spazio e memoria per un'installazione di gestione Knative.
Un attivatore può consumare richieste fino a un massimo di 1000 milliCPU e 600 MiB di RAM. Quando un attivatore esistente non supporta il numero di richieste in entrata, si avvia un attivatore aggiuntivo, il che richiede una prenotazione di 300 milliCPU e 60 MiB di RAM.
Ogni pod creato dal servizio di gestione Knative crea un collaterale proxy di coda che applica i limiti di contemporaneità delle richieste. Il proxy di coda riserva 25 milliCPU e non ha prenotazione di memoria. Il consumo del proxy di coda dipende dal numero di richieste che vengono messe in coda e dalla dimensione delle stesse; non sono previsti limiti alle risorse di CPU e memoria che può utilizzare.
Crea un Service
Knative Serving estende Kubernetes definendo un insieme di definizioni di risorse personalizzate (CRD): Servizio, Revisione, Configurazione e Route. Questi CRD definiscono e controllano il comportamento delle applicazioni sul cluster:
- Il servizio di pubblicazione Knative è la risorsa personalizzata di primo livello definita dalla gestione di Knative. È una singola applicazione che gestisce l'intero ciclo di vita del carico di lavoro. Il servizio garantisce che l'app abbia un route, una configurazione e una nuova revisione per ogni aggiornamento del servizio.
- Revisione è uno snapshot point-in-time e immutabile del codice e della configurazione.
- Configurazione mantiene le impostazioni correnti dell'ultima revisione e registra una cronologia di tutte le revisioni passate. La modifica di una configurazione crea una nuova revisione.
- Route definisce un endpoint HTTP e lo associa a una o più revisioni a cui vengono inoltrate le richieste.
Quando un utente crea un servizio di pubblicazione Knative, si verifica quanto segue:
L'oggetto del servizio di gestione Knative definisce:
- Una configurazione su come gestire le revisioni.
- Una revisione immutabile per questa versione del servizio.
- Una route per gestire l'assegnazione del traffico specificata alla revisione.
L'oggetto route crea VirtualService. L'oggetto VirtualService configura il gateway in entrata e il gateway locale del cluster per instradare il traffico del gateway alla revisione corretta.
L'oggetto revisione crea i seguenti componenti del piano di controllo: un oggetto servizio Kubernetes e un oggetto Deployment.
La configurazione di rete connette l'Attivatore, il gestore della scalabilità automatica e i bilanciatori del carico per la tua app.
Gestione delle richieste
Il seguente diagramma mostra una panoramica generale di un possibile percorso di richiesta per il traffico degli utenti attraverso i componenti del piano dati di gestione Knative in un cluster Google Kubernetes Engine di esempio:
Il diagramma successivo si espande rispetto a quello in alto per offrire una visione approfondita del percorso di richiesta del traffico utente, descritto anche in dettaglio di seguito:
Per un percorso di richiesta di pubblicazione con Knative:
Il traffico arriva attraverso:
- Il gateway in entrata per il traffico dall'esterno dei cluster
- Il gateway locale del cluster per il traffico all'interno dei cluster
Il componente VirtualService, che specifica le regole di routing del traffico, configura i gateway in modo che il traffico degli utenti venga instradato alla revisione corretta.
Il servizio Kubernetes, un componente del piano di controllo, determina il passaggio successivo nel percorso della richiesta in base alla disponibilità dei pod per la gestione del traffico:
Se non esistono pod nella revisione:
- L'attivatore accoda temporaneamente la richiesta ricevuta ed esegue il push di una metrica al gestore della scalabilità automatica per scalare più pod.
- Il gestore della scalabilità automatica scala allo stato desiderato dei pod nel deployment.
- Il deployment crea più pod per ricevere richieste aggiuntive.
- L'attivatore esegue un nuovo tentativo di richiesta al file collaterale del proxy in coda.
In caso di scale out del servizio (i pod sono disponibili), il servizio Kubernetes invia la richiesta al file collaterale del proxy in coda.
Il file collaterale proxy di coda applica i parametri delle code di richiesta, richieste singole o multi-thread, che il container è in grado di gestire contemporaneamente.
Se il file collaterale del proxy della coda ha più richieste di quelle che può gestire, il gestore della scalabilità automatica crea più pod per gestire richieste aggiuntive.
Il file collaterale del proxy in coda invia il traffico al container utente.