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 devono 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 dell'installazione predefinita
Installa Knative serving nel
tuo cluster per connettere e gestire i carichi di lavoro stateful. I componenti 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:- Activator: quando i pod vengono scalati a zero o sono sovraccaricati dalle richieste inviate alla revisione, Activator mette temporaneamente in coda le richieste e invia le metriche ad Autoscaler per avviare altri pod. Una volta che il ridimensionamento automatico esegue il ridimensionamento della revisione in base alle metriche registrate 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 ed elaborano il traffico utente inoltrato.
- Autoscaler: aggrega ed elabora le metriche di Activator e del contenitore sidecar proxy della coda, un componente nel piano dati 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 piano di controllo. In caso contrario, quando i pod vengono scalati a zero, il gestore della scalabilità automatica è un componente del piano dati.
- Controller: crea e aggiorna le risorse secondarie di Autoscaler e degli oggetti Service. Il controller è un componente del piano di controllo. I componenti del piano di controllo gestiscono tutte le funzioni e le procedure che stabiliscono il percorso della richiesta del traffico utente.
- Raccogli metriche: raccoglie le metriche dai componenti di pubblicazione di Knative e poi le inoltra a Cloud Monitoring.
- Webhook: imposta valori predefiniti, rifiuta oggetti incoerenti e non validi e convalida e mutates le chiamate all'API Kubernetes in base alle risorse di 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 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 viene registrato un dominio esterno per evitare 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 il gateway di ingresso Istio per gestire le richieste HTTP agli endpoint corretti. Istiod è un componente del piano di controllo. Per ulteriori informazioni, consulta Istiod.
I componenti di servizio Knative vengono aggiornati automaticamente con eventuali aggiornamenti del cluster del piano di controllo GKE. Per ulteriori informazioni, consulta Versioni di GKE disponibili.
Utilizzo delle risorse del cluster
L'installazione iniziale per il servizio Knative richiede circa 1,5 CPU virtuali 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ò consumare richieste con un massimo di 1000 milliCPU e 600 MiB di RAM. Quando un attivatore esistente non è in grado di supportare il numero di richieste in arrivo, 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 sidecar proxy di coda che applica i limiti di concorrenza delle richieste. Il proxy della coda prenota 25 milliCPU e non ha prenotazioni di memoria. Il consumo del proxy di coda dipende dal numero di richieste in coda e dalle dimensioni delle richieste. Non sono previsti limiti per le risorse di CPU e memoria che può consumare.
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 tue applicazioni nel cluster:
- Il servizio Knative serving è la risorsa personalizzata di primo livello definita da Knative serving. Si tratta di una singola applicazione che gestisce l'intero ciclo di vita del carico di lavoro. Il servizio garantisce che la tua app abbia un percorso, una configurazione e una nuova revisione per ogni aggiornamento del servizio.
- La revisione è un'istantanea immutabile del codice e della configurazione in un determinato momento.
- Configurazione mantiene le impostazioni correnti per la revisione più recente e registra una cronologia di tutte le revisioni passate. La modifica di una configurazione crea una nuova revisione.
- Percorso 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 i seguenti passaggi:
L'oggetto Service di Knative serving definisce:
- Una configurazione per la pubblicazione delle revisioni.
- Una revisione immutabile per questa versione del servizio.
- Un percorso per gestire l'assegnazione del traffico specificato alla 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 piano di dati del servizio Knative in un cluster Google Kubernetes Engine di esempio:
Il diagramma seguente espande quello precedente per fornire una visione approfondita del percorso della richiesta del traffico utente, descritto anche in dettaglio di seguito:
Per un percorso di richiesta di Knative serving:
Il traffico arriva tramite:
- Il gateway in entrata 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 piano di controllo, determina il passaggio successivo nel percorso della richiesta in base alla disponibilità dei pod per gestire il traffico:
Se nella revisione non sono presenti pod:
- Activator mette temporaneamente in coda la richiesta ricevuta e invia una metrica ad Autoscaler per scalare più pod.
- Il gestore della scalabilità automatica esegue la scalabilità in base allo stato desiderato dei pod nel deployment.
- Il deployment crea più pod per ricevere richieste aggiuntive.
- L'attivatore riprova le richieste al sidecar proxy della coda.
Se il servizio viene scalato (i pod sono disponibili), il servizio Kubernetes invia la richiesta al sidecar proxy della coda.
Il sidecar proxy della coda applica i parametri della coda delle richieste, richieste singole o multithread, che il contenitore può gestire alla volta.
Se il sidecar proxy della coda ha più richieste di quante possa gestire, Autoscaler crea più pod per gestire le richieste aggiuntive.
Il sidecar proxy della coda invia il traffico al contenitore dell'utente.