Queste informazioni sono utili per i seguenti tipi di utenti:
- Utenti che iniziano a utilizzare Cloud Run for Anthos.
- Operatori con esperienza nell'esecuzione di cluster GKE.
- Gli sviluppatori di applicazioni che hanno bisogno di saperne di più su come Cloud Run for Anthos si integra con i cluster Kubernetes per progettare applicazioni migliori o configurare la loro applicazione Cloud Run for Anthos.
Componenti nell'installazione predefinita
Quando installi Cloud Run for Anthos come componente aggiuntivo nel cluster Google Kubernetes Engine, gli spazi dei nomi knative-serving e gke-system vengono creati automaticamente. Il deployment dei seguenti componenti viene eseguito in uno di questi spazi dei nomi:
Componenti in esecuzione nello spazio dei nomi
knative-serving:- Attivatore: quando i pod vengono ingranditi a zero o vengono sovraccaricati con richieste inviate alla revisione, Activator accoda temporaneamente le richieste e invia le metriche al gestore della scalabilità automatica per avviare più pod. Quando la scalabilità automatica scala la revisione in base alle metriche segnalate e ai pod disponibili, Activator inoltra le richieste in coda alla revisione. Attivatore è un componente del piano dati; i componenti del piano dati gestiscono tutte le funzioni e i processi che inoltrano il traffico degli utenti.
- Autoscaler: aggrega ed elabora le metriche di Activator e del container collaterale proxy di coda, un componente del piano dati che applica i limiti di contemporaneità della richiesta. Il gestore della scalabilità automatica calcola quindi la contemporaneità osservata per la revisione e regola le dimensioni del deployment in base al conteggio dei 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 ridimensionati a zero, è un componente del piano dati.
- Controller: crea e aggiorna le risorse figlio di Autoscaler 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 determinano il percorso della richiesta del traffico degli utenti.
- Webhook: consente di impostare valori predefiniti, rifiutare oggetti incoerenti e non validi e convalidare e mutare le chiamate API Kubernetes rispetto alle risorse Cloud Run for Anthos. Il webhook è un componente del piano di controllo.
Componenti in esecuzione nello spazio dei nomi
gke-system:- Gateway locale del cluster: bilanciatore del carico nel piano dati responsabile della gestione del traffico interno che arriva da un Cloud Run for Anthos 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: il 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.
- Istio Pilot: configura il gateway locale cluster e il gateway Ingress in entrata per gestire le richieste HTTP agli endpoint corretti. Istio è un componente del piano di controllo. Per ulteriori informazioni, vedi Istio Pilot.
I componenti di Cloud Run for Anthos vengono aggiornati automaticamente con qualsiasi aggiornamento del cluster del piano di controllo GKE. Per ulteriori informazioni, consulta la sezione Versioni di GKE disponibili.
Utilizzo delle risorse del cluster
L'installazione iniziale di Cloud Run for Anthos 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 Cloud Run for Anthos.
Un Attivatore può consumare richieste a un massimo di 1000 milliCPU e 600 MiB di RAM. Quando un Attivatore esistente non supporta il numero di richieste in entrata, viene attivato un altro Activator che richiede una prenotazione di 300 milliCPU e 60 MiB di RAM.
Ogni pod creato dal servizio Cloud Run for Anthos crea un file collaterale proxy di coda che applica limiti di contemporaneità delle richieste. Il proxy di coda riserva 25 milliCPU e non ha prenotazione di memoria. Il consumo del proxy della coda dipende dal numero di richieste in coda e dalle dimensioni delle richieste; non ci sono limiti alla CPU e alle risorse di memoria che può consumare.
Crea un Service
Cloud Run for Anthos estende Kubernetes definendo un set di definizioni di risorse personalizzate (CRD): Service, Revision, Configuration e Route. Questi CRD definiscono e controllano il comportamento delle applicazioni nel cluster:
- Cloud Run for Anthos Service è la risorsa personalizzata di primo livello definita da Cloud Run for Anthos. 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 è uno snapshot immutabile point-in-time del codice e della configurazione.
- Configuration 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 associa l'endpoint a una o più revisioni a cui vengono inoltrate le richieste.
Quando un utente crea un servizio Cloud Run for Anthos, si verifica quanto segue:
L'oggetto servizio Cloud Run for Anthos definisce:
- Una configurazione per la pubblicazione delle revisioni.
- Una revisione immutabile per questa versione del servizio.
- Un percorso per gestire l'allocazione del traffico specificata alla tua revisione.
L'oggetto route crea VirtualService. L'oggetto VirtualService configura il gateway gateway e il gateway locale cluster per instradare il traffico gateway alla revisione corretta.
L'oggetto revisione crea i seguenti componenti del piano di controllo: un oggetto Service 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 generale di un possibile percorso di richiesta per il traffico degli utenti attraverso i componenti del piano dati di Cloud Run for Anthos in un cluster di esempio di Google Kubernetes Engine:
Il diagramma successivo si espande rispetto al diagramma precedente per fornire una visione approfondita del percorso della richiesta del traffico utente, descritto anche in dettaglio di seguito:
Per un percorso di richiesta Cloud Run for Anthos:
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 indirizzato alla revisione corretta.
Il servizio Kubernetes, un componente del piano di controllo, determina il passaggio successivo del percorso della richiesta in base alla disponibilità dei pod per gestire il traffico:
Se non ci sono pod nella revisione:
- Attivatore mette temporaneamente in coda la richiesta ricevuta ed esegue il push di una metrica al gestore della scalabilità automatica per scalare più pod.
- Il gestore della scalabilità automatica esegue la scalabilità in base allo stato desiderato dei pod in Deployment.
- Il deployment crea più pod per ricevere richieste aggiuntive.
- L'attuatore tenta di ripetere le richieste al file collaterale proxy della coda.
Se è lo scale out del servizio (sono disponibili pod), il servizio Kubernetes invia la richiesta al file collaterale proxy della coda.
Il file collaterale proxy della coda applica parametri alla coda delle richieste, a richiesta singola o multi-thread, che il container può gestire alla volta.
Se il file collaterale proxy della coda contiene un numero di richieste superiore a quello che può gestire, il gestore della scalabilità automatica crea più pod per gestire le richieste aggiuntive.
Il file collaterale proxy della coda invia il traffico al contenitore dell'utente.