Panoramica dell'architettura di Knative serving

Questa pagina fornisce una panoramica dell'architettura di Knative serving e illustra le modifiche che si verificano quando abiliti Knative serving nel tuo cluster Google Kubernetes Engine.

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 connetterti e gestire i tuoi carichi di lavoro stateless. 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.

Di seguito è riportato un elenco dei componenti installati da Knative serving e da Cloud Service Mesh:

• Componenti installati da Knative serving nello spazio dei nomi knative-serving:

  • Attivatore: quando i pod vengono scalati fino a zero o si sovraccaricano di richieste inviate alla revisione, Activator mette temporaneamente in coda le richieste e invia le metriche al gestore della scalabilità automatica per avviare altri pod. Una volta che 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 di inoltro del traffico degli utenti.
  • Gestore della scalabilità automatica: aggrega ed elabora le metriche di Activator e del container collaterale del proxy di coda, un componente del piano dati che applica i 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. Altrimenti, quando i pod vengono scalati fino 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 gli oggetti di servizio. 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 delle metriche: 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, convalida e modifica le chiamate API Kubernetes rispetto alle risorse Knative serving. Il webhook è un componente del piano di controllo.

• Componenti installati da Cloud 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 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.
  • Gateway Istio Ingress: bilanciatore del carico nel piano dati responsabile della ricezione e della gestione del traffico in entrata dall'esterno del cluster, compreso quello proveniente da reti esterne o interne.
  • Istiod: configura il gateway locale del cluster e il gateway Istio Ingress per gestire le richieste HTTP agli endpoint corretti. Istiod è un componente del piano di controllo. Per ulteriori informazioni, vedi Istiod.

I componenti di Knative serving vengono aggiornati automaticamente con qualsiasi aggiornamento del cluster del piano di controllo GKE. Per maggiori informazioni, consulta Versioni GKE disponibili.

Utilizzo delle risorse del cluster

L'installazione iniziale per Knative serving 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 Knative serving.

Un Attivatore può consumare richieste fino 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 sidecar proxy di coda che applica limiti di contemporaneità per le richieste. Il proxy di coda prenota 25 milliCPU e non ha una prenotazione di memoria. Il consumo da parte del proxy di coda dipende da quante richieste vengono inserite in coda e dalle dimensioni delle richieste; non esistono limiti alle risorse di CPU e memoria che può utilizzare.

Crea un Service

Architettura di Knative serving Service (fai clic per ingrandire)

Knative serving estende Kubernetes definendo un set di Definizioni di risorse personalizzate (CRD): servizio, revisione, configurazione e route. Questi CRD definiscono e controllano il comportamento delle 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 l'app abbia un route, una configurazione e una nuova revisione per ogni aggiornamento del servizio.
• La revisione è uno snapshot point-in-time e immutabile del codice e della configurazione.
• La configurazione conserva le impostazioni correnti per l'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 Knative serving, si verifica quanto segue:

1. L'oggetto Knative serving Service definisce:

   1. Una configurazione su come pubblicare le tue revisioni.
   2. Una revisione immutabile per questa versione del servizio.
   3. Un percorso per gestire l'assegnazione del traffico specificata alla tua revisione.

2. L'oggetto di 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.

3. L'oggetto di revisione crea i seguenti componenti del piano di controllo: un oggetto Servizio Kubernetes e un oggetto Deployment.

4. 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 Knative serving su un cluster Google Kubernetes Engine di esempio:

Architettura dei cluster Knative serving (fai clic per ingrandire)

Il diagramma successivo si espande rispetto a quello precedente per offrire una visione approfondita del percorso di richiesta del traffico utente, descritto anche nel dettaglio di seguito:

Percorso di richiesta di Knative serving (fai clic per ingrandire)

Per un percorso di richiesta di Knative serving:

1. Il traffico arriva attraverso:

   • Gateway in entrata per il traffico proveniente dall'esterno dei cluster
   • Gateway locale del cluster per il traffico all'interno dei cluster

2. Il componente VirtualService, che specifica le regole di routing del traffico, configura i gateway in modo che il traffico degli utenti sia instradato alla revisione corretta.

3. Kubernetes Service, un componente del piano di controllo, determina il passaggio successivo del percorso di richiesta in base alla disponibilità dei pod per gestire il traffico:

   • Se la revisione non contiene alcun pod:

     1. L'attivatore mette temporaneamente in coda la richiesta ricevuta e invia una metrica al gestore della scalabilità automatica per scalare più pod.
     2. Il gestore della scalabilità automatica scala lo stato desiderato dei pod nel deployment.
     3. Il deployment crea più pod per ricevere richieste aggiuntive.
     4. L'attivatore riprova a inviare le richieste al sidecar del proxy della coda.

   • Se è stato fatto lo scale out del servizio (sono disponibili pod disponibili), il servizio Kubernetes invia la richiesta al sidecar del proxy della coda.

4. Il sidecar del proxy della coda applica i parametri della coda delle richieste, le richieste a uno o più thread, che il container può gestire contemporaneamente.

5. Se il sidecar del proxy della coda ha più richieste di quante ne possa gestire, il gestore della scalabilità automatica crea più pod per gestire le richieste aggiuntive.

6. Il sidecar del proxy di coda invia il traffico al contenitore utente.