Questa pagina è stata tradotta dall'API Cloud Translation.

Panoramica dei gruppi di endpoint di rete serverless

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 una risorsa Cloud Run, App Engine, Cloud Run Functions o API Gateway.

Un NEG serverless può rappresentare uno dei seguenti elementi:

Una risorsa Cloud Run o un gruppo di risorse.
Una funzione Cloud Run o un gruppo di funzioni (in precedenza funzioni Cloud Run2ª generazionen.).
Una funzione Cloud Run (1ª generazione.) o un gruppo di funzioni
Un'app dell'ambiente standard di App Engine o dell'ambiente flessibile di App Engine, un servizio specifico all'interno di un'app, una versione specifica di un'app o un gruppo di servizi.
Un API Gateway che fornisce l'accesso ai tuoi servizi tramite un'API REST coerente in tutti i servizi, indipendentemente dall'implementazione del servizio. Questa funzionalità è in anteprima.

Bilanciatori del carico supportati

La tabella seguente elenca i prodotti serverless supportati da ciascun bilanciatore del carico delle applicazioni. I NEG serverless non sono supportati dai bilanciatori del carico di rete proxy e dai bilanciatori del carico di rete passthrough.

Tipo di NEG serverless	Bilanciatori del carico delle applicazioni
Tipo di NEG serverless	interno regionale	Interno tra regioni	Global external	Classico	Esterno regionale
Cloud Run Supporta Cloud Run e Cloud Run Functions (2ª generazione.)
App Engine
Cloud Functions Supporta le funzioni Cloud Run (1ª generazione.), precedentemente note come Cloud Functions (1ª generazione.)

Casi d'uso

Quando il bilanciatore del carico è abilitato per le app serverless, puoi:

Configura la tua app serverless in modo che venga pubblicata da un indirizzo IP IPv4 dedicato che non sia condiviso con altri servizi.
Mappa un singolo URL a più servizi o funzioni serverless che vengono pubblicati nello stesso dominio. In questo documento, vedi Maschere URL.
Condividere lo spazio URL con altre piattaforme di calcolo Google Cloud . Utilizzando più servizi di backend, un singolo bilanciatore del carico può inviare 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 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 delle applicazioni esterno globale e bilanciatore del carico delle applicazioni classico

La configurazione di un bilanciatore del carico delle applicazioni esterno globale o di un bilanciatore del carico delle applicazioni classico consente alle tue app serverless di integrarsi con i servizi cloud esistenti. Puoi fare quanto segue:

Proteggi il tuo servizio con Google Cloud Armor, un prodotto di sicurezza WAF e di difesa DDoS perimetrale disponibile per tutti i servizi a cui si accede tramite un bilanciatore del carico delle applicazioni esterno. Esistono alcune limitazioni associate a questa funzionalità, in particolare per Cloud Run e App Engine.
Consenti al tuo servizio di ottimizzare la distribuzione utilizzando Cloud CDN. Cloud CDN memorizza nella cache i contenuti vicini ai tuoi utenti. Cloud CDN offre funzionalità come l'annullamento della convalida della cache e gli URL firmati di Cloud CDN.
Utilizza l'infrastruttura perimetrale 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 calcolo serverless, consulta la seguente documentazione:

L'integrazione di un bilanciatore del carico delle applicazioni esterno con API Gateway consente ai tuoi backend serverless di sfruttare tutte le funzionalità fornite da Cloud Load Balancing. Per ulteriori informazioni, consulta Bilanciatore del carico delle applicazioni esterno per API Gateway. Per configurare un bilanciatore del carico delle applicazioni esterno per instradare il traffico a un gateway API, consulta la sezione Introduzione a un bilanciatore del carico delle applicazioni esterno per API Gateway. Questa funzionalità è in anteprima.

Bilanciatore del carico delle applicazioni esterno regionale

L'utilizzo di un bilanciatore del carico delle applicazioni esterno regionale consente di eseguire carichi di lavoro con requisiti normativi o di conformità sui backend Cloud Run o Cloud Run Functions (2ª generazione). Ad esempio, se richiedi che le configurazioni di rete e la terminazione del traffico della tua applicazione si trovino in una regione specifica, un bilanciatore del carico delle applicazioni esterno regionale è spesso l'opzione preferita per rispettare i controlli giurisdizionali necessari.

Per scoprire come configurare un bilanciatore del carico delle applicazioni esterno regionale con un backend di computing serverless, consulta Configura un bilanciatore del carico delle applicazioni esterno regionale con Cloud Run.

Bilanciatore del carico delle applicazioni interno regionale e bilanciatore del carico delle applicazioni interno tra regioni

Quando un bilanciatore del carico delle applicazioni interno è configurato con backend Cloud Run o Cloud Run Functions 2ª generazionen.), puoi:

Attiva le funzionalità avanzate di gestione del traffico, come l'inserimento di errori, la riscrittura degli header, i reindirizzamenti, la suddivisione del traffico e altro ancora, per i tuoi servizi Cloud Run e Cloud Run Functions (2ª generazione).
Esegui la migrazione senza problemi dei servizi legacy da Compute Engine, GKE o on-premise a Cloud Run e Cloud Run Functions 2ª generazionen.) per sfruttare 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 e Cloud Run Functions (2ª generazione.) con Controlli di servizio VPC.
Stabilisci un unico punto di ingresso interno che applichi i criteri per i tuoi servizi in esecuzione in Cloud Run, Cloud Run Functions 2ª generazionen), Compute Engine e GKE.

Per scoprire come configurare un bilanciatore del carico delle applicazioni interno regionale con un backend di serverless computing, consulta Configura un bilanciatore del carico delle applicazioni interno regionale con Cloud Run.

Il resto di questa pagina spiega come utilizzare i NEG serverless con i bilanciatori del carico delle applicazioni. Per ulteriori informazioni su altri tipi di NEG, vedi Panoramica dei gruppi di endpoint di rete.

Tipi di endpoint

I NEG serverless non hanno endpoint di rete come porte o indirizzi IP. Possono puntare solo a una risorsa Cloud Run, App Engine, API Gateway o Cloud Run Functions esistente che si trova nella stessa regione del NEG.

Quando crei un NEG serverless, devi specificare il nome di dominio completo (FQDN) della risorsa Cloud Run, App Engine, API Gateway o Cloud Run Functions. L'endpoint è di tipo SERVERLESS. 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 calcolo serverless e proxy il traffico all'endpoint specificato. Tuttavia, se il servizio di backend contiene più NEG serverless in regioni diverse, 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 delle applicazioni 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 NEG serverless in più regioni.

I bilanciatori del carico delle applicazioni esterni regionali sono sempre di livello Standard.

I bilanciatori del carico delle applicazioni interni tra regioni e i bilanciatori del carico delle applicazioni interni regionali 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 delle applicazioni interni richiedono una subnet solo proxy per eseguire i proxy Envoy per tuo conto.

I seguenti diagrammi mostrano un deployment NEG serverless di esempio.

Esterno globale

Questo diagramma mostra come si inserisce un NEG serverless in un bilanciatore del carico delle applicazioni esterno globale architettura.

Esterno regionale

Questo diagramma mostra come una NEG serverless si inserisce in un bilanciatore del carico delle applicazioni esterno regionale.

Interno a livello di regione

Questo diagramma mostra come un NEG serverless si inserisce nel modello di bilanciatore del carico delle applicazioni interno regionale.

Bilanciatore del carico delle applicazioni interno regionale per app serverless. — Bilanciatore del carico delle applicazioni interno regionale per app serverless (fai clic per ingrandire).

Tra regioni

Questo diagramma mostra come un NEG serverless si inserisce nel modello di bilanciatore del carico delle applicazioni interno tra regioni.

Componenti frontend

Non è necessaria alcuna configurazione speciale del 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 in base a indirizzo IP, porta e protocollo. Il proxy di destinazione termina quindi le connessioni dai client.

Le mappe URL vengono utilizzate dai bilanciatori del carico delle applicazioni per configurare l'instradamento delle richieste basato su URL ai servizi di backend appropriati.

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

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 seconda del tipo di bilanciatore del carico, si applicano le seguenti limitazioni:

Un servizio di backend globale utilizzato dai bilanciatori del carico delle applicazioni esterni globali può avere più NEG serverless collegati, ma solo un NEG serverless per regione.
Un servizio di backend regionale utilizzato dai bilanciatori del carico delle applicazioni interni regionali e dai bilanciatori del carico delle applicazioni esterni regionali può avere collegato un solo NEG serverless.
Un servizio di backend globale utilizzato dai bilanciatori del carico delle applicazioni interni tra regioni può avere solo risorse Cloud Run e Cloud Run Functions (2ª generazione) collegate.

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

Il nome di dominio completo per una singola risorsa
Una maschera URL che rimanda a più risorse che vengono pubblicate 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 URL sono utili se utilizzi un dominio personalizzato per la tua applicazione serverless e hai più servizi che vengono pubblicati nello stesso dominio. Invece di creare un NEG serverless separato per ogni risorsa, puoi creare il NEG con una maschera URL generica per il dominio personalizzato. Per ulteriori informazioni ed esempi, consulta Maschere URL.

Per ulteriori limitazioni quando aggiungi un NEG serverless come backend, vedi Limitazioni.

Rilevamento outlier per i NEG serverless

Il rilevamento dei valori anomali è una configurazione facoltativa che può essere abilitata su un servizio di backend globale a cui sono collegati NEG serverless. L'analisi del rilevamento di valori anomali è disponibile solo per un bilanciatore del carico delle applicazioni interno tra regioni, un bilanciatore del carico delle applicazioni esterno globale e non per un bilanciatore del carico delle applicazioni classico. L'analisi di rilevamento dei valori anomali identifica i NEG serverless non integri in base ai loro pattern di risposta HTTP e riduce il tasso di errore indirizzando la maggior parte delle nuove richieste dalle risorse non integre a quelle integre. Per scoprire come funziona l'algoritmo di rilevamento dei valori anomali e comprenderne i limiti, consulta il seguente esempio.

Supponiamo che esista un servizio di backend a cui sono collegati due NEG serverless, uno nella regione REGION_A e l'altro nella regione REGION_B. Se il NEG serverless che funge da backend per un bilanciatore del carico delle applicazioni esterno globale nella regione REGION_A non risponde, il rilevamento degli outlier identifica il NEG serverless come non integro. In base all'analisi del rilevamento degli outlier, alcune delle nuove richieste vengono inviate al NEG serverless nella regione REGION_B.

In base al tipo di errore del server riscontrato, puoi utilizzare uno dei seguenti metodi di rilevamento degli outlier per attivare il rilevamento degli outlier:

Errori 5xx consecutivi. Un codice di stato HTTP della serie 5xx è considerato un errore.
Errori consecutivi del gateway. Solo i codici di stato HTTP 502, 503 e 504 sono considerati errori.

Tieni presente che anche dopo aver attivato il rilevamento dei valori anomali, è probabile che alcune richieste vengano inviate alla risorsa non integra e che quindi restituiscano errori 5XX ai client. Questo perché i risultati dell'algoritmo di rilevamento outlier (espulsione degli endpoint dal pool di bilanciamento del carico e reinserimento nel pool) vengono eseguiti in modo indipendente da ogni istanza proxy del bilanciatore del carico. Nella maggior parte dei casi, più di un'istanza proxy gestisce il traffico ricevuto da un servizio di backend. Pertanto, è possibile che un endpoint non integro venga rilevato ed espulso solo da alcuni proxy e, mentre ciò accade, altri proxy potrebbero continuare a inviare richieste allo stesso endpoint non integro.

Per ridurre ulteriormente i tassi di errore, puoi configurare parametri di rilevamento degli outlier più aggressivi. Ti consigliamo di configurare valori più elevati per le soglie di espulsione (outlierDetection.baseEjectionTime). Ad esempio, i nostri test dimostrano che l'impostazione di outlierDetection.baseEjectionTime a 180 secondi con un QPS sostenuto superiore a 100 comporta tassi di errore osservati inferiori al 5%. Per saperne di più sull'API di rilevamento degli outlier, consulta outlierDetection nella documentazione dell'API del servizio di backend globale.

I seguenti campi outlierDetection non sono supportati quando al servizio di backend è collegato un NEG serverless:

outlierDetection.enforcingSuccessRate
outlierDetection.successRateMinimumHosts
outlierDetection.successRateRequestVolume
outlierDetection.successRateStdevFactor

Per scoprire come configurare il rilevamento degli outlier, consulta Configurare un bilanciatore del carico delle applicazioni esterno globale con un backend serverless: attivare il rilevamento degli outlier.

Maschere URL

Un backend NEG serverless può puntare a una singola risorsa Cloud Run (o App Engine o Cloud Run Functions, se applicabile) oppure a una maschera URL che punta a più risorse. Una maschera URL è un modello dello schema dell'URL. Il NEG serverless utilizza questo modello per mappare la richiesta alla risorsa appropriata.

Le maschere URL sono una funzionalità facoltativa che semplifica la configurazione dei NEG serverless quando l'applicazione serverless è composta da più risorse Cloud Run, Cloud Run Functions o App Engine. I NEG serverless utilizzati con i bilanciatori del carico delle applicazioni interni possono utilizzare solo una maschera URL che punta ai servizi Cloud Run o Cloud Run Functions 2ª generazionen).

Le maschere URL sono utili se la tua app serverless è mappata a un dominio personalizzato anziché all'indirizzo predefinito fornito da Google Cloud . Con un dominio personalizzato come example.com, potresti avere più risorse di cui è stato eseguito il deployment in sottodomini o percorsi diversi dello stesso dominio. In questi casi, invece di creare un backend NEG serverless separato per ogni risorsa, 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.

La seguente illustrazione mostra un bilanciatore del carico delle applicazioni esterno con un singolo servizio di backend e un NEG serverless che utilizza una maschera URL per mappare le richieste degli utenti a servizi diversi.

Distribuzione del traffico alle app serverless. — Utilizzo di una maschera URL per distribuire il traffico a servizi diversi (fai clic per ingrandire).

Le maschere URL funzionano al meglio quando le risorse dell'applicazione utilizzano uno schema URL prevedibile. Il vantaggio di utilizzare una maschera URL anziché una mappa URL è che non devi creare NEG serverless separati per i servizi login e search. Inoltre, non devi modificare la configurazione del bilanciamento del carico ogni volta che aggiungi una nuova risorsa all'applicazione.

Limitazioni

Un NEG serverless non può avere endpoint di rete come indirizzo IP o porta.
I NEG serverless possono puntare solo a risorse serverless che si trovano nella stessa regione 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 delle risorse di backend Cloud Run, App Engine, API Gateway o Cloud Run Functions 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 può rilevare se la risorsa serverless sottostante funziona come previsto. Ciò significa che anche se la risorsa restituisce errori, il bilanciatore del carico continua a indirizzarvi il traffico. Assicurati di testare a fondo le nuove versioni delle risorse prima di indirizzarvi il traffico degli utenti.

Limitazioni con i servizi di backend

Si applicano le seguenti limitazioni ai servizi di backend che hanno un backend NEG serverless:

Un servizio di backend globale utilizzato dai bilanciatori del carico delle applicazioni esterni globali può avere un solo NEG serverless per regione. Per combinare più NEG serverless in un unico servizio di backend, tutti i NEG devono rappresentare deployment funzionalmente equivalenti in regioni diverse. Ad esempio, i NEG possono puntare alla stessa risorsa Cloud Run, App Engine o Cloud Run Functions di cui è stato eseguito il deployment in regioni diverse.
Un servizio di backend globale utilizzato dai bilanciatori del carico delle applicazioni interni tra regioni può avere collegata una sola risorsa Cloud Run o Cloud Run Functions 2ª generazionen.).
Un servizio di backend regionale può avere un solo NEG serverless collegato.
Il riferimento ai servizi tra progetti in un deployment VPC condiviso è supportato con configurazioni che contengono un NEG serverless. Per utilizzare questa funzionalità, crea i componenti frontend del bilanciatore del carico (indirizzo IP, regola di forwarding, proxy di destinazione e mappa URL) in un progetto diverso dai componenti backend del bilanciatore del carico (servizio di backend e NEG serverless). Tieni presente che il servizio di backend, i NEG serverless associati e la risorsa serverless di supporto (Cloud Run, App Engine, API Gateway o Cloud Run Functions) devono sempre essere creati nello stesso progetto.
L'impostazione del 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 richiede connessioni a lunga esecuzione, configura i client in modo che ritentino le richieste in caso di errore.
Tutti i NEG serverless combinati in un servizio di backend devono utilizzare lo stesso tipo di backend. Ciò significa che i NEG serverless Cloud Run possono essere combinati solo con altri NEG serverless Cloud Run e i NEG serverless App Engine possono essere combinati solo con altri NEG serverless App Engine.
Non puoi combinare i NEG serverless con altri tipi di NEG 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 servizi di backend che indirizzano a NEG serverless, alcuni campi sono limitati:
- Non puoi specificare una modalità di bilanciamento. ovvero i valori RATE,UTILIZATION e CONNECTION non influiscono sulla distribuzione del traffico del bilanciatore del carico.
- I controlli di integrità non sono supportati per i backend serverless. Pertanto, i servizi di backend che contengono backend NEG serverless non possono essere configurati con controlli di integrità. Tuttavia, puoi attivare facoltativamente il rilevamento degli outlier per identificare le risorse serverless non integre e indirizzare le nuove richieste a una risorsa serverless integra.
Non puoi utilizzare il comando gcloud compute backend-services edit per modificare un servizio di backend con un backend NEG serverless. Come soluzione alternativa, utilizza il comando gcloud compute backend-services update.

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

Limitazioni con i bilanciatori del carico delle applicazioni interni regionali e i bilanciatori del carico delle applicazioni esterni regionali

I NEG serverless utilizzati con bilanciatori del carico delle applicazioni interni regionali o bilanciatori del carico delle applicazioni esterni regionali possono puntare solo a risorse Cloud Run o Cloud Run Functions (2ª generazione.).
Per i progetti che utilizzano NEG serverless, il limite di query al secondo (QPS) è di 5000 QPS per progetto per il traffico inviato a qualsiasi NEG serverless configurato con bilanciatori del carico delle applicazioni esterni regionali o bilanciatori del carico delle applicazioni interni regionali. Questo limite viene aggregato in tutti i bilanciatori del carico delle applicazioni esterni regionali e nei bilanciatori del carico delle applicazioni interni regionali del progetto. Questo non è un limite per bilanciatore del carico.

Limitazioni con i bilanciatori del carico delle applicazioni interni tra regioni

I NEG serverless utilizzati con i bilanciatori del carico delle applicazioni interni multiregionali possono puntare solo a risorse Cloud Run o Cloud Run Functions 2ª generazioneen).

Limitazioni con i bilanciatori del carico delle applicazioni esterni globali

In questa sezione sono elencate le limitazioni che incontrerai durante la configurazione dei NEG serverless con i bilanciatori del carico delle applicazioni esterni globali.

Limitazioni di Cloud Run

Un bilanciatore del carico delle applicazioni esterno con NEG serverless non supporta Knative Serving.
I bilanciatori del carico delle applicazioni esterni non supportano l'autenticazione delle richieste degli utenti finali alle risorse Cloud Run. Tuttavia, puoi utilizzare IAP per autenticare gli utenti all'interno della tua organizzazione. Se vuoi attivare IAP, ricorda che IAP e Cloud CDN non sono compatibili tra loro. Non possono essere abilitati sullo stesso servizio di backend.

Limitazioni di App Engine

Il bilanciamento del carico multiregionale non è supportato con App Engine. Questo perché App Engine richiede una regione per progetto.
Se utilizzi IAP, devi utilizzare lo stesso ID client OAuth per tutti i servizi App Engine associati a un singolo bilanciamento del carico.
È consentito un solo criterio IAP nel percorso della richiesta. Ad esempio, se hai già impostato un criterio IAP nel servizio di backend, non devi impostarne un altro nell'app App Engine.
I bilanciatori del carico delle applicazioni esterni globali con backend dell'ambiente flessibile di App Engine e backend dell'ambiente standard di App Engine non supportano il riferimento tra progetti.

Ti consigliamo di utilizzare i controlli di ingresso in modo che la tua app riceva solo le richieste inviate dal bilanciamento del carico (e dal VPC, se lo utilizzi). In caso contrario, gli utenti possono utilizzare l'URL App Engine della tua app per bypassare il bilanciatore del carico, i criteri di sicurezza di Cloud Armor, i certificati SSL e le chiavi private che vengono passati tramite il bilanciatore del carico.

Limitazioni di API Gateway

Per ulteriori informazioni, consulta Limitazioni relative ai NEG serverless e ad API Gateway.

Limitazioni delle funzionalità di gestione del traffico

Le funzionalità di gestione avanzata del traffico, come la policy di località di bilanciamento del carico e l'affinità sessione, non sono supportate con i backend NEG serverless.
La specifica di un'affinità di sessione su un servizio di backend con un backend NEG serverless non funzionerà. Come soluzione alternativa per Cloud Run, utilizza la funzionalità specifica di affinità sessione.

Prezzi

Per visualizzare le informazioni sui prezzi dei bilanciatori del carico con NEG serverless, consulta Tutti i prezzi di networking: Cloud Load Balancing.