Panoramica dei gruppi di endpoint di rete serverless

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Un gruppo di endpoint di rete (NEG) specifica un gruppo di endpoint di backend per un bilanciatore del carico. Un NEG serverless è un backend che punta a un servizio Cloud Run, App Engine, Cloud Functions o Gateway Gateway.

Un NEG serverless può rappresentare uno dei seguenti elementi:

  • Un servizio Cloud Run o un gruppo di servizi.
  • Una funzione di Cloud Functions o un gruppo di funzioni.
  • Un'app App Engine (Standard o Flex), un servizio specifico all'interno di un'app, una versione specifica di un'app o un gruppo di servizi.
  • Un gateway API che fornisce l'accesso ai servizi tramite un'API REST coerente in tutti i servizi, a prescindere dall'implementazione del servizio. Questa funzionalità è in Anteprima.

Casi d'uso

I NEG serverless sono supportati con i seguenti bilanciatori del carico:

  • Il bilanciatore del carico HTTP(S) esterno globale e il bilanciatore del carico HTTP(S) esterno globale (classico): Cloud Run, App Engine e Cloud Functions sono supportati.
  • Bilanciatore del carico HTTP(S) esterno a livello di regione (Anteprima): È supportato solo Cloud Run.
  • Bilanciatore del carico HTTP(S) interno (Anteprima): Solo Cloud Run è supportato.

Quando il bilanciatore del carico HTTP(S) è abilitato per le app serverless, puoi:

  • Configura la tua app serverless per la pubblicazione da un indirizzo IP IPv4 dedicato che non è condiviso con altri servizi.
  • Mappare un singolo URL a più funzioni o servizi serverless che vengono gestiti nello stesso dominio. In questo documento, vedi Maschere URL.
  • Condividere lo spazio degli URL con altre piattaforme di computing Google Cloud. Utilizzando più servizi di backend, un singolo bilanciatore del carico può inviare il traffico a più tipi di backend. Il bilanciatore del carico seleziona il servizio di backend corretto in base all'host o al percorso dell'URL della richiesta.
  • Riutilizza gli stessi certificati SSL e le stesse chiavi private che utilizzi per Compute Engine, Google Kubernetes Engine e Cloud Storage. Il riutilizzo degli stessi certificati elimina la necessità di gestire certificati separati per le app serverless.

Bilanciatore del carico HTTP(S) esterno globale e bilanciatore del carico HTTP(S) esterno globale (classico)

La configurazione di un bilanciatore del carico HTTP(S) esterno globale o di un bilanciatore del carico HTTP(S) esterno globale (classico) consente alle app serverless di integrarsi con i servizi cloud esistenti. Puoi:

  • Proteggi il tuo servizio con Google Cloud Armor, un prodotto per la difesa dagli attacchi DDoS/periferico perimetrale disponibile per tutti i servizi a cui si accede tramite un bilanciatore del carico HTTP(S) esterno. Esistono alcune limitazioni associate a questa funzionalità, in particolare per Cloud Run e App Engine.
  • Abilita il servizio per ottimizzare la distribuzione utilizzando Cloud CDN. Cloud CDN memorizza i contenuti nella cache vicino agli utenti. Cloud CDN offre funzionalità come l'annullamento della convalida della cache e gli URL firmati di Cloud CDN.
  • Utilizzare l'infrastruttura Edge di Google per terminare le connessioni HTTP(S) dell'utente più vicino all'utente, riducendo così la latenza.

Per scoprire come configurare un bilanciatore del carico con un backend di computing serverless, consulta la seguente documentazione:

L'integrazione del bilanciamento del carico HTTP(S) con il gateway API consente ai tuoi backend serverless di usufruire di tutte le funzionalità fornite da Cloud Load Balancing. Per saperne di più, consulta Bilanciamento del carico HTTP(S) per il gateway API. Per configurare il bilanciamento del carico HTTP(S) per il routing del traffico verso un gateway API, consulta la Guida introduttiva al bilanciamento del carico HTTP(S) per il gateway API. Questa funzionalità è in Anteprima.

Bilanciatore del carico HTTP(S) esterno a livello di area geografica

L'utilizzo di un bilanciatore del carico HTTP(S) esterno a livello di regione ti consente di eseguire carichi di lavoro con requisiti normativi o di conformità sui backend (Cloud Run). Ad esempio, se le configurazioni di rete e la terminazione del traffico dell'applicazione si trovano in una regione specifica, spesso il bilanciatore del carico HTTP(S) esterno a livello di area geografica è la soluzione preferita per rispettare i controlli giurisdizionali necessari.

Per scoprire come configurare un bilanciatore del carico HTTP(S) esterno a livello di regione con un backend di calcolo serverless, consulta Configurazione di un bilanciatore del carico HTTP(S) esterno a livello di regione con Cloud Run.

Bilanciatore del carico HTTP(S) interno

Quando il bilanciamento del carico HTTP(S) interno è configurato con i backend (Cloud Run), puoi:

  • Abilita le funzionalità di gestione avanzata del traffico HTTP(S) interno per, ad esempio, l'inserimento di errori, le riscritture delle intestazioni, i reindirizzamenti, la suddivisione del traffico e altro ancora, per i tuoi servizi Cloud Run.
  • Esegui facilmente la migrazione dei servizi legacy da Compute Engine, GKE o on-premise a Cloud Run e sfrutta la suddivisione del traffico basata sul peso per spostare gradualmente il traffico su Cloud Run senza tempi di inattività.
  • Proteggi i tuoi servizi Cloud Run con i Controlli di servizio VPC.
  • Stabilisci un singolo punto di accesso interno che applica il criterio per i servizi in esecuzione in Cloud Run, Compute Engine e GKE.

Per scoprire come configurare un bilanciatore del carico HTTP(S) interno con un backend di computing serverless, consulta la pagina Configurare un bilanciatore del carico HTTP(S) interno con Cloud Run.

Il resto di questa pagina illustra come utilizzare i NEG serverless con i bilanciatori del carico HTTP(S).

Per ulteriori informazioni su altri tipi di NEG, consulta la panoramica dei gruppi di endpoint di rete.

Tipi di endpoint

I NEG serverless non hanno endpoint di rete come porte o indirizzi IP. Possono indirizzare solo a un servizio Cloud Run, App Engine, Gateway API o Cloud Functions esistente che si trova nella stessa area geografica del NEG.

Quando crei un NEG serverless, specifichi il nome di dominio completo (FQDN) del servizio Cloud Run, App Engine, Gateway API o Cloud Functions. Il tipo di endpoint è SERVERLESS. Gli altri tipi di endpoint non sono supportati in un NEG serverless.

Un NEG serverless non può avere più di un endpoint. L'endpoint punta a un'applicazione serverless o a una maschera URL. Il bilanciatore del carico funge da frontend per l'applicazione di computing serverless e trasmette il traffico all'endpoint specificato. Tuttavia, se il servizio di backend contiene più NEG serverless in diverse aree geografiche, il bilanciatore del carico invia il traffico al NEG nella regione più vicina per ridurre al minimo la latenza delle richieste.

Livello di rete

Per i bilanciatori del carico HTTP(S) esterni globali, puoi utilizzare un NEG serverless in un bilanciatore del carico utilizzando i livelli di servizio di rete Standard o Premium. Il livello Premium è necessario solo se vuoi configurare i NEG serverless in più aree geografiche.

I bilanciatori del carico HTTP(S) esterni a livello di area geografica sono sempre livello standard.

I bilanciatori del carico HTTP(S) interni sono sempre di livello Premium.

Componenti di bilanciamento del carico

Un bilanciatore del carico che utilizza un backend NEG serverless richiede una configurazione speciale solo per il servizio di backend. La configurazione del frontend è la stessa di qualsiasi altro bilanciatore del carico Google Cloud basato su proxy. Inoltre, i bilanciatori del carico HTTP(S) interni richiedono una subnet solo proxy per l'esecuzione dei proxy Envoy per tuo conto.

I seguenti diagrammi mostrano un deployment NEG serverless di esempio.

HTTP(S) esterni

Questo diagramma mostra in che modo un NEG serverless si adatta a un'architettura globale del bilanciatore del carico HTTP(S) esterno.

Bilanciamento del carico HTTP(S) esterno globale per le app serverless
Bilanciamento del carico HTTP(S) esterno globale per le app serverless

Questo diagramma mostra in che modo un NEG serverless si adatta all'architettura di un bilanciatore del carico HTTP(S) esterno a livello di regione.

Bilanciamento del carico HTTP(S) esterno a livello di regione per le app serverless
Bilanciamento del carico HTTP(S) a livello di area geografica per le app serverless

HTTP(S) interni

Questo diagramma mostra in che modo un NEG serverless si adatta al modello di bilanciamento del carico HTTP(S) interno.

Bilanciamento del carico HTTPS semplice (fai clic per ingrandire)
Bilanciamento del carico HTTP(S) interno per le app serverless

Componenti del frontend

Non è necessaria alcuna configurazione speciale di frontend per il bilanciamento del carico con i backend NEG serverless. Le regole di forwarding vengono utilizzate per instradare il traffico verso un proxy di destinazione, nonché un indirizzo IP, una porta e un protocollo. Il proxy di destinazione termina quindi le connessioni dai client.

Le mappe URL vengono utilizzate dai bilanciatori del carico HTTP(S) per configurare il routing basato su URL delle richieste ai servizi di backend appropriati.

Per ulteriori dettagli su ciascuno di questi componenti, consulta le sezioni sull'architettura delle panoramiche specifiche del bilanciatore del carico:

Servizio di backend

I servizi di backend forniscono informazioni di configurazione al bilanciatore del carico. I bilanciatori del carico utilizzano le informazioni in un servizio di backend per indirizzare il traffico in entrata a uno o più backend collegati. I NEG serverless possono essere utilizzati come backend per determinati bilanciatori del carico.

A un servizio di backend globale (utilizzato dai bilanciatori del carico HTTP(S) esterni globali) possono essere collegati diversi NEG serverless, ma un solo NEG serverless per area geografica. A un servizio di backend regionale (utilizzato da bilanciatori del carico HTTP(S) interni e bilanciatori del carico HTTP(S) esterni a livello di regione) è possibile collegare un solo NEG serverless.

Ogni NEG serverless può puntare a uno dei seguenti elementi:

  • Il nome di dominio completo per una singola funzione o servizio
  • Una maschera dell'URL che rimanda a più funzioni o servizi che vengono pubblicati nello stesso dominio

Una maschera URL è un modello di schema URL che indica al backend NEG serverless come mappare la richiesta dell'utente al servizio corretto. Le maschere dell'URL sono utili se utilizzi un dominio personalizzato per l'applicazione serverless e disponi di più servizi nello stesso dominio. Anziché creare un NEG serverless senza server per ogni funzione o servizio, puoi creare un NEG con una maschera URL generica per il dominio personalizzato. Per ulteriori informazioni ed esempi, consulta la pagina relativa alle mascherine degli URL.

Per ulteriori limitazioni quando aggiungi un NEG serverless come backend, consulta le limitazioni.

Maschere URL

Un backend NEG serverless può indirizzare a un singolo servizio Cloud Run (o App Engine o Cloud Functions, se applicabile) o a una maschera URL che rimanda a più servizi. Una maschera URL è un modello dello schema dell'URL. Il NEG serverless utilizza questo modello per mappare la richiesta al servizio appropriato.

Le maschere URL sono una funzionalità facoltativa che semplifica la configurazione dei NEG serverless quando la tua applicazione serverless è composta da più servizi Cloud Run, Cloud Functions o App Engine. I NEG serverless utilizzati con i bilanciatori del carico HTTP(S) interni possono utilizzare solo una maschera URL che punta ai servizi Cloud Run.

Le maschere dell'URL sono utili se l'app serverless è mappata a un dominio personalizzato anziché all'indirizzo predefinito fornito da Google Cloud. Con un dominio personalizzato, ad esempio example.com, potresti avere più servizi implementati in sottodomini o percorsi diversi sullo stesso dominio. In questi casi, invece di creare un backend NEG serverless separato per ogni servizio, puoi creare un singolo NEG serverless con una maschera URL generica per il dominio personalizzato (ad esempio, example.com/<service>). Il NEG estrae il nome del servizio dall'URL della richiesta.

L'illustrazione seguente mostra un bilanciatore del carico HTTP(S) esterno con un singolo servizio di backend e NEG serverless, che utilizza una maschera URL per mappare le richieste degli utenti a servizi diversi.

Distribuzione del traffico nelle app serverless (fai clic per ingrandire)
Utilizzare una maschera URL per distribuire il traffico su servizi diversi

Le maschere dell'URL funzionano meglio quando i servizi della tua applicazione utilizzano uno schema URL prevedibile. Il vantaggio di utilizzare una maschera URL invece di una mappa URL è che non è necessario creare NEG serverless per i servizi login e search. Inoltre, non è necessario modificare la configurazione del bilanciatore del carico ogni volta che aggiungi un nuovo servizio alla tua applicazione.

Per scoprire come creare e configurare una maschera URL per un NEG serverless, consulta:

Limitazioni

  • Un NEG serverless non può avere endpoint di rete come un indirizzo IP o una porta.
  • I NEG serverless possono puntare solo ad applicazioni serverless che si trovano nella stessa area geografica in cui viene creato il NEG.
  • Per un bilanciatore del carico che utilizza un backend NEG serverless, il NEG serverless deve essere creato nello stesso progetto dei servizi Cloud Run, App Engine, API Gateway o Cloud Functions di supporto a cui punta il NEG. Potresti visualizzare richieste non riuscite se connetti un servizio che non si trova nello stesso progetto del NEG serverless.
  • Un bilanciatore del carico configurato con un NEG serverless non è in grado di rilevare se l'app o il servizio serverless sottostante funziona come previsto. Ciò significa che, anche se il servizio restituisce errori, il bilanciatore del carico continua a indirizzarvi il traffico. Assicurati di testare accuratamente le nuove versioni dei tuoi servizi prima di indirizzarvi il traffico.

Limitazioni relative ai servizi di backend

Le seguenti limitazioni si applicano ai servizi di backend che hanno un backend NEG serverless:

  • Un servizio di backend globale può avere un NEG serverless per area geografica. Per combinare più NEG serverless in un singolo servizio di backend, tutti i NEG devono rappresentare deployment funzionalmente equivalenti in diverse aree geografiche. Ad esempio, i NEG possono puntare allo stesso servizio Cloud Run, App Engine o Cloud Functions di cui è stato eseguito il deployment in diverse aree geografiche.
  • A un servizio di backend a livello di area geografica può essere associato un solo NEG serverless.
  • Il servizio di backend deve essere creato nello stesso progetto del NEG serverless e del servizio Cloud Run, App Engine, API Gateway o Cloud Functions di supporto. Se stai configurando un deployment VPC condiviso con riferimenti a servizi tra progetti, i componenti frontend del bilanciatore del carico (indirizzo IP, regola di forwarding, proxy di destinazione e mappa URL) possono essere creati in un progetto diverso.
  • L'impostazione di timeout del servizio di backend non si applica ai servizi di backend con backend NEG serverless. Il tentativo di modificare la proprietà resource.timeoutSec del servizio di backend genera il seguente errore: Timeout sec is not supported for a backend service with Serverless network endpoint groups.
    Per i servizi di backend con backend NEG serverless, il timeout predefinito è 60 minuti. Questo timeout non è configurabile. Se la tua applicazione ha bisogno di connessioni a lunga esecuzione, configura i tuoi client in modo che eseguano un nuovo tentativo delle richieste in caso di errore.
  • Anche tutti i NEG serverless combinati in un servizio di backend devono utilizzare lo stesso tipo di backend. Ciò significa che i NEG serverless di Cloud Run possono essere combinati solo con altri NEG serverless di Cloud Run, i NEG serverless di App Engine possono essere combinati solo con i NEG serverless di App Engine e così via.
  • Non è possibile combinare i NEG serverless con altri tipi di NEG (a livello di zona o di Internet) nello stesso servizio di backend. Ad esempio, non puoi eseguire il routing a un cluster GKE e a un servizio Cloud Run dallo stesso servizio di backend.
  • Quando configuri i servizi di backend che eseguono il routing ai NEG serverless, alcuni campi sono limitati:
    • Non puoi specificare una modalità di bilanciamento. In altre parole, i valori RATE, UTILIZATION e CONNECTION non hanno effetto sulla distribuzione del traffico del bilanciatore del carico.
    • I controlli di integrità non sono supportati per i backend serverless. Pertanto, i servizi di backend contenenti backend NEG serverless non possono essere configurati con i controlli di integrità.
  • Non puoi utilizzare il comando gcloud compute backend-services edit per modificare un servizio di backend con un backend NEG serverless. Per risolvere il problema, utilizza il comando gcloud compute backend-services update.

Si applicano limitazioni aggiuntive a seconda del tipo di bilanciatore del carico e del backend serverless.

Limitazioni con bilanciamento del carico HTTP(S) interno

  • I NEG serverless utilizzati con i bilanciatori del carico HTTP(S) interni possono puntare solo a servizi Cloud Run.
  • Non puoi utilizzare Google Cloud Console per configurare un bilanciatore del carico HTTP(S) interno con un backend NEG serverless
  • Deve essere presente almeno una VM nella rete VPC per poter configurare un bilanciatore del carico HTTP(S) interno con un backend serverless.

Limitazioni con bilanciatori del carico HTTP(S) esterni a livello di regione

  • I NEG serverless utilizzati con i bilanciatori del carico HTTP(S) esterni a livello di area geografica possono puntare solo ai servizi Cloud Run.
  • Non puoi utilizzare Google Cloud Console per configurare un bilanciatore del carico HTTP(S) esterno a livello di area geografica con un backend NEG serverless.
  • Deve essere presente almeno una VM nella rete VPC per poter configurare un bilanciatore del carico HTTP(S) esterno a livello di regione con un backend serverless.

Limitazioni con Cloud Run

  • Il bilanciamento del carico HTTP(S) esterno con NEG serverless non è supportato con Cloud Run for Anthos.
  • Il bilanciamento del carico HTTP(S) esterno non supporta le richieste autenticate nei servizi Cloud Run.

Limitazioni con Cloud Functions

  • IAP non funziona con Cloud Functions.

Limitazioni con App Engine

  • Il bilanciamento del carico in più aree geografiche non è supportato con App Engine. Questo perché App Engine richiede una regione per progetto.
  • Sul percorso della richiesta è consentito un solo criterio IAP. Ad esempio, se hai già impostato un criterio IAP nel servizio di backend, non devi impostare un altro criterio IAP nell'applicazione App Engine.
  • Ti consigliamo di utilizzare i controlli di traffico in entrata in modo che la tua app riceva solo le richieste inviate dal bilanciatore del carico (e il VPC se lo utilizzi). In caso contrario, gli utenti possono utilizzare l'URL di App Engine della tua app per ignorare il bilanciatore del carico, i criteri di sicurezza di Google Cloud Armor, i certificati SSL e le chiavi private trasmesse attraverso il bilanciatore del carico.

Limitazioni con API Gateway

Per ulteriori informazioni, consulta la pagina Limitazioni sui NEG serverless e sul gateway API.

Prezzi

Per informazioni sui prezzi per i bilanciatori del carico con NEG serverless, consulta la pagina Prezzi della rete.

Passaggi successivi