Queste informazioni sono utili per i seguenti tipi di utenti:
- Utenti che iniziano a utilizzare Knative serving.
- Operatori con esperienza nell'esecuzione di 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 configurare la propria applicazione Knative serving.
Componenti nell'installazione predefinita
Installa Knative serving nel tuo cluster per connettere e gestire i tuoi carichi di lavoro stateless. I componenti di Knative
vengono creati nello spazio dei nomi knative-serving.
Knative serving utilizza Cloud Service Mesh per instradare il traffico. Per impostazione predefinita,
Cloud Service Mesh installa i componenti nello spazio dei nomi istio-system.
Ecco un elenco dei componenti installati da Knative serving e Cloud Service Mesh:
Componenti installati da Knative serving nello spazio dei nomi
knative-serving:- Attivatore: quando gli apod vengono scalati a zero o sovraccarichi di richieste inviate alla revisione, l'attivatore mette temporaneamente in coda le richieste e invia le metriche allo strumento di scalabilità automatica per avviare altri pod. Una volta che il gestore della scalabilità automatica ridimensiona la revisione in base alle metriche riportate e ai pod disponibili, Activator inoltra le richieste in coda alla revisione. Activator è un componente del data plane; i componenti del data plane gestiscono tutte le funzioni e i processi di inoltro del traffico utente.
- Gestore della scalabilità automatica: aggrega ed elabora le metriche di Activator e del container collaterale proxy della coda, un componente del data plane che applica i limiti di concorrenza delle richieste. Il gestore della scalabilità automatica calcola quindi la concorrenza 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 control plane; altrimenti, quando i pod vengono ridotti a zero, il gestore della scalabilità automatica è un componente del data plane.
- Controller: crea e aggiorna le risorse secondarie di Autoscaler e gli oggetti Service. Il controller è un componente del control plane; i componenti del control plane gestiscono tutte le funzioni e i processi che stabiliscono il percorso delle richieste del traffico utente.
- Metrics Collector: raccoglie le metriche dai componenti di Knative Serving e le inoltra a Cloud Monitoring.
- Webhook: imposta i valori predefiniti, rifiuta gli oggetti incoerenti e non validi e convalida e modifica le chiamate API Kubernetes rispetto alle risorse Knative Serving. Webhook è un componente del piano di controllo.
Componenti installati da Cloud Service Mesh in esecuzione nello spazio dei nomi
istio-system:- Cluster Local Gateway: bilanciatore del carico nel data plane responsabile della gestione del traffico interno che arriva da un servizio Knative Serving a un altro. È possibile accedere al gateway locale del cluster solo dall'interno del cluster GKE e non registra un dominio esterno per impedire l'esposizione accidentale di informazioni private o processi interni.
- Istio Ingress Gateway: bilanciatore del carico nel piano dati responsabile della ricezione e della gestione del traffico in entrata dall'esterno del cluster, incluso il traffico proveniente da reti esterne o interne.
- Istiod: configura il gateway locale del cluster e l'Istio Ingress Gateway per gestire le richieste HTTP negli endpoint corretti. Istiod è un componente del control plane. Per saperne di più, consulta Istiod.
I componenti di Knative Serving vengono aggiornati automaticamente con qualsiasi aggiornamento del cluster del control plane GKE. Per maggiori informazioni, vedi Versioni di GKE disponibili.
Utilizzo delle risorse cluster
L'installazione iniziale di Knative Serving richiede circa 1,5 CPU virtuale e 1 GB di memoria per il cluster. Il numero di nodi nel cluster non influisce sui requisiti di spazio e memoria per un'installazione di Knative Serving.
Un attivatore può utilizzare le richieste a un massimo di 1000 millicpu e 600 MiB di RAM. Quando un attivatore esistente non è in grado di supportare il numero di richieste in entrata, viene avviato un attivatore aggiuntivo, che richiede una prenotazione di 300 millicpu e 60 MiB di RAM.
Ogni pod creato dal servizio Knative serving crea un proxy di coda sidecar che applica i limiti di concorrenza delle richieste. Il proxy della coda riserva 25 millicpu e non ha prenotazione di memoria. Il consumo del proxy di coda dipende dal numero di richieste in coda e dalle dimensioni delle richieste; non esistono limiti alle risorse di CPU e memoria che può consumare.
Crea un Service
Knative Serving estende Kubernetes definendo un insieme di definizioni di risorse personalizzate (CRD): Service, Revision, Configuration e Route. Questi CRD definiscono e controllano il comportamento delle tue applicazioni sul cluster:
- Knative serving Service è la risorsa personalizzata di primo livello definita da Knative serving. È una singola applicazione che gestisce l'intero ciclo di vita del carico di lavoro. Il tuo servizio garantisce che la tua app abbia una route, una configurazione e una nuova revisione per ogni aggiornamento del servizio.
- Una revisione è un'istantanea immutabile del codice e della configurazione in un determinato momento.
- Configurazione mantiene le impostazioni correnti per l'ultima revisione e registra una cronologia di tutte le revisioni precedenti. 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 Knative serving, si verificano le seguenti operazioni:
L'oggetto Servizio Knative serving definisce:
- Una configurazione per la modalità di pubblicazione delle revisioni.
- Una revisione immutabile per questa versione del servizio.
- Un percorso per gestire l'assegnazione del traffico specificato alla tua revisione.
L'oggetto route crea VirtualService. L'oggetto VirtualService configura Ingress Gateway e Cluster Local Gateway 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 Activator, Autoscaler e i bilanciatori del carico per la tua app.
Gestione delle richieste
Il seguente diagramma mostra una panoramica di alto livello di un possibile percorso di richiesta per il traffico utente attraverso i componenti del data plane di Knative Serving in un cluster Google Kubernetes Engine di esempio:
Il diagramma successivo si basa su quello precedente per fornire una visione approfondita del percorso della richiesta del traffico utente, descritto in dettaglio di seguito:
Per un percorso di richiesta di Knative serving:
Il traffico arriva tramite:
- L'Ingress Gateway per il traffico proveniente 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 utente venga indirizzato alla revisione corretta.
Il servizio Kubernetes, un componente del control plane, determina il passaggio successivo nel percorso della richiesta a seconda della disponibilità dei pod per gestire il traffico:
Se nella revisione non sono presenti pod:
- L'attivatore mette temporaneamente in coda la richiesta ricevuta e invia una metrica al gestore della scalabilità automatica per scalare più pod.
- Il gestore della scalabilità automatica esegue lo scale up o lo scale down fino allo stato desiderato dei pod nel deployment.
- Il deployment crea più pod per ricevere richieste aggiuntive.
- Activator riprova le richieste al file collaterale proxy della coda.
Se il servizio viene scalato orizzontalmente (i pod sono disponibili), il servizio Kubernetes invia la richiesta al contenitore secondario proxy della coda.
Il file collaterale del proxy della coda applica i parametri della coda delle richieste, le richieste a thread singolo o multithread, che il container può gestire contemporaneamente.
Se il sidecar proxy della coda ha più richieste di quelle che può gestire, il gestore della scalabilità automatica crea più pod per gestire le richieste aggiuntive.
Il proxy sidecar della coda invia il traffico al container utente.