Panoramica dei gruppi di endpoint di rete serverless

Un gruppo di endpoint di rete (NEG) specifica un gruppo di endpoint di backend per un carico con il bilanciatore del carico di rete passthrough esterno regionale. Un NEG serverless è un backend che punta a un Cloud Run, App Engine, Cloud Functions, oppure Gateway API completamente gestito di Google Cloud.

Un NEG serverless può rappresentare uno dei seguenti elementi:

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

Bilanciatori del carico supportati

Nella tabella seguente sono elencati i prodotti serverless supportati da ogni Bilanciatore del carico delle applicazioni. I NEG serverless non sono supportati dai bilanciatori del carico di rete proxy e i bilanciatori del carico di rete passthrough.

Piattaforma serverless Bilanciatori del carico delle applicazioni
Interno
regionale		 Interno
tra regioni		 Global
external		 Classico Esterno
regionale
Cloud Run
App Engine
Cloud Functions

Casi d'uso

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

  • Configura l'app serverless in modo che venga pubblicata da un indirizzo IP IPv4 dedicato che non viene condiviso con altri servizi.
  • Mappare un singolo URL a più funzioni o servizi serverless che operano su lo stesso dominio. In questo documento, consulta le maschere degli URL.
  • Condividi spazio URL con altre piattaforme di computing Google Cloud. Utilizzando più 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 l'host o il 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 per le app serverless.

Bilanciatore del carico delle applicazioni esterno globale e bilanciatore del carico delle applicazioni classico

Configurazione di un bilanciatore del carico delle applicazioni esterno globale o Bilanciatore del carico delle applicazioni classico consente l'integrazione delle app serverless con i servizi cloud esistenti. Puoi procedi nel seguente modo:

  • Proteggi il tuo servizio con Google Cloud Armor, una difesa DDoS perimetrale e Prodotto di sicurezza WAF disponibile per tutti i servizi a cui si accede tramite un un bilanciatore del carico delle applicazioni esterno. Esistono alcune limitazioni associate a questa funzionalità, in particolare per Cloud Run in App Engine.
  • Abilita il tuo servizio per 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 URL firmati di Cloud CDN.
  • Utilizza l'infrastruttura perimetrale di Google per Connessioni HTTP(S) più vicine all'utente, con una conseguente riduzione della latenza.

Scopri come configurare un bilanciatore del carico con un serverless computing consulta la documentazione seguente:

Integrazione di un bilanciatore del carico delle applicazioni esterno con API Gateway consente ai backend serverless di sfruttare tutte le funzionalità fornite da Cloud Load Balancing. Per saperne di più, vedi Bilanciatore del carico delle applicazioni esterno per API Gateway. Per configurare un bilanciatore del carico delle applicazioni esterno per instradare il traffico a un API Gateway: consulta la guida introduttiva all'utilizzo di un bilanciatore del carico delle applicazioni esterno per API Gateway. Questa funzionalità è in Anteprima.

Bilanciatore del carico delle applicazioni esterno regionale

Utilizzo di un bilanciatore del carico delle applicazioni esterno regionale consente di eseguire carichi di lavoro con requisiti normativi o di conformità Cloud Run. Ad esempio, se richiedono che le configurazioni di rete e la terminazione del traffico della tua applicazione che risiedono in una regione specifica, un bilanciatore del carico delle applicazioni esterno regionale è spesso la soluzione l'opzione per conformarsi ai controlli giurisdizionali necessari.

Scopri come configurare un bilanciatore del carico delle applicazioni esterno regionale con un serverless computing vedi Configurare un bilanciatore del carico delle applicazioni esterno regionale con in Cloud Run.

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

Quando viene configurato un bilanciatore del carico delle applicazioni interno Cloud Run, puoi:

  • Attivare la gestione avanzata del traffico come come fault injection, riscrittura di intestazioni, reindirizzamenti, suddivisione del traffico e altro ancora, per i tuoi servizi Cloud Run.
  • Esegui facilmente la migrazione dei servizi legacy da Compute Engine, da GKE, o on-premise, a Cloud Run sfruttare la suddivisione del traffico basata sulla ponderazione per spostare gradualmente il traffico a Cloud Run senza tempi di inattività.
  • Proteggi i tuoi servizi Cloud Run con Controlli di servizio VPC.
  • Stabilisci un punto di ingresso interno unico per l'applicazione dei criteri per i tuoi servizi in esecuzione in Cloud Run, Compute Engine con GKE.

Scopri come configurare un bilanciatore del carico delle applicazioni interno regionale con un serverless computing vedi Configurare un bilanciatore del carico delle applicazioni interno regionale con in Cloud Run.

Il resto di questa pagina illustra come utilizzare i NEG serverless con Bilanciatori del carico delle applicazioni. Per ulteriori informazioni su altri tipi di NEG, consulta 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 un modello Cloud Run, App Engine, Gateway API o Cloud Functions che si trova nella stessa regione di il NEG.

Quando crei un NEG serverless, specifichi il nome di dominio completo (FQDN) di Cloud Run, App Engine, Gateway API o Cloud 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 rimanda a a operare un'applicazione serverless o una maschera URL. Il bilanciatore del carico funge da frontend per l'applicazione e i proxy di serverless computing per il traffico verso l'endpoint specificato. Tuttavia, se il servizio di backend contiene più NEG serverless in regioni diverse, il bilanciatore del carico invia 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 al livello Standard o Premium di Network Service Tiers. Il livello Premium è richiesto 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 Premium livello.

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 come per qualsiasi altro bilanciatore del carico Google Cloud basato su proxy. Inoltre, i bilanciatori del carico delle applicazioni interni richiedono una subnet solo proxy da eseguire Envoy proxy per tuo conto.

I seguenti diagrammi mostrano un deployment di esempio di NEG serverless.

Esterno globale

Questo diagramma mostra il modo in cui un NEG serverless si inserisce in un bilanciatore del carico delle applicazioni esterno globale dell'architettura.

Bilanciatore del carico delle applicazioni esterno globale per app serverless.
Bilanciatore del carico delle applicazioni esterno globale per app serverless (fai clic per ingrandire).

Esterno regionale

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

Bilanciatore del carico delle applicazioni esterno regionale per le app serverless.
Bilanciatore del carico delle applicazioni esterno regionale per le app serverless (fai clic per ingrandire).

Interno a livello di regione

Questo diagramma mostra il modo in cui un NEG serverless si inserisce nel bilanciatore del carico delle applicazioni interno regionale model.

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

Tra regioni

Questo diagramma mostra il modo in cui un NEG serverless si inserisce nel bilanciatore del carico delle applicazioni interno tra regioni model.

Bilanciatore del carico delle applicazioni interno tra regioni con deployment di Cloud Run.
Bilanciatore del carico delle applicazioni interno tra regioni con deployment Cloud Run (fai clic per ingrandire).

Componenti del frontend

Non è richiesta una configurazione frontend speciale per il bilanciamento del carico con un ambiente serverless Backend del NEG. Regole di forwarding vengono utilizzati per instradare il traffico per indirizzo IP, porta e protocollo a un proxy di destinazione. A questo punto, il proxy di destinazione termina e connessioni dai client.

Le mappe URL vengono utilizzate da i bilanciatori del carico delle applicazioni per configurare il routing basato su URL delle richieste dai servizi di backend appropriati.

Per ulteriori dettagli su ciascuno di questi componenti, fai riferimento alle sezioni sull'architettura le panoramiche specifiche dei bilanciatori del carico:

Servizio di backend

I servizi di backend forniscono informazioni di configurazione al bilanciatore del carico. Carica usano le informazioni contenute 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 di 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 NEG serverless collegati, ma solo un NEG serverless per regione.
  • Un servizio di backend regionale utilizzato da Application Load Balancer interni regionali e ai bilanciatori del carico delle applicazioni esterni regionali può essere collegato un solo NEG serverless.
  • Un servizio di backend globale utilizzato dai bilanciatori del carico delle applicazioni interni tra regioni può avere solo servizi Cloud Run collegati.

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

  • Il nome di dominio completo per una singola funzione o un singolo servizio
  • Una maschera URL che punta a più funzioni o servizi pubblicati nella 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 per gli URL sono utili se utilizzando un dominio personalizzato per la tua applicazione serverless e avere di Google Cloud nello stesso dominio. Invece di creare una rete NEG serverless per ogni funzione o servizio, puoi creare il NEG con maschera URL generica per il dominio personalizzato. Per ulteriori informazioni ed esempi, vedi Maschere URL.

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

Rilevamento outlier per NEG serverless

Il rilevamento outlier è una configurazione facoltativa che può essere abilitata su un database di servizio di backend a cui sono collegati NEG serverless. Il rilevamento outlier l'analisi è 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 degli outlier identifica NEG serverless non integri in base ai pattern di risposta HTTP e riduce di errore instradando la maggior parte delle nuove richieste da servizi non integri a servizi integre i servizi di machine learning. Scoprire come funziona l'algoritmo di rilevamento di outlier e comprenderne , vedi l'esempio che segue.

Supponiamo che esista un servizio di backend con due NEG serverless collegate, una nella regione REGION_A e un'altra nella Regione REGION_B. Se il NEG serverless che funge da backend per Il bilanciatore del carico delle applicazioni esterno globale nella regione REGION_A non è reattivo, outlier il rilevamento identifica il NEG serverless come non integro. In base al rilevamento di outlier dei dati, alcune delle nuove richieste vengono quindi inviate al NEG serverless Regione REGION_B.

In base al tipo di errore del server che si è verificato, puoi utilizzare uno dei seguenti metodi di rilevamento degli outlier per abilitare il rilevamento degli outlier:

  • Errori 5xx consecutivi. Un codice di stato HTTP della serie 5xx è considerato .
  • Errori consecutivi del gateway. Solo codici di stato HTTP 502, 503 e 504 possono essere considerate un errore.

Tieni presente che anche dopo aver abilitato il rilevamento outlier, probabilmente visualizzerai alcune richieste al servizio non integro e di conseguenza restituendo errori 5XX al clienti. Ciò è dovuto al fatto che i risultati dell'algoritmo di rilevamento di outlier (espulsione di dal pool di bilanciamento del carico e li restituendo al pool) sono eseguite in modo indipendente da ciascuna istanza proxy del bilanciatore del carico. Nella maggior parte dei casi, casi, più di un'istanza proxy gestisce il traffico ricevuto da un backend completamente gestito di Google Cloud. Pertanto, è possibile che un endpoint non integro venga rilevato ed espulso da alcuni proxy e, sebbene ciò si verifichi, altri proxy potrebbero continuare per inviare richieste allo stesso endpoint in stato non integro.

Per ridurre ulteriormente i tassi di errore, puoi configurare un rilevamento outlier più aggressivo parametri. Consigliamo di configurare valori più alti per le soglie di espulsione (outlierDetection.baseEjectionTime). Ad esempio, i nostri test mostrano che Impostazione di outlierDetection.baseEjectionTime su 180 secondi con un Un valore QPS superiore a 100 genera tassi di errore osservati inferiori al 5%. Per ulteriori informazioni sull'API di rilevamento di outlier, consulta outlierDetection nell'API del servizio di backend globale documentazione.

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

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

Per scoprire come configurare il rilevamento di outlier, consulta Configurare un Bilanciatore del carico delle applicazioni esterno globale con backend serverless: abilita l'outlier il rilevamento.

Maschere URL

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

Le maschere URL sono una funzionalità facoltativa che semplifica la configurazione del serverless NEG quando la tua applicazione serverless è composta da più Cloud Run, Cloud Functions o App Engine i servizi di machine learning. I NEG serverless utilizzati con i bilanciatori del carico delle applicazioni interni possono usare solo una maschera URL che punta ai servizi Cloud Run.

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

L'illustrazione seguente mostra un bilanciatore del carico delle applicazioni esterno con un singolo backend e NEG serverless, che utilizza una maschera URL per mappare le richieste dell'utente diversi servizi.

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

Le maschere URL funzionano al meglio quando i servizi della tua applicazione usano un URL prevedibile . Il vantaggio di utilizzare una maschera URL anziché una mappa URL è che devi creare NEG serverless separati per i servizi login e search. Inoltre, non devi modificare la configurazione del bilanciatore del carico ogni volta che aggiungi un nuovo servizio alla tua applicazione.

Limitazioni

  • Un NEG serverless non può avere endpoint di rete come indirizzo IP o porta.
  • I NEG serverless possono puntare solo ad applicazioni serverless che risiedono nella stessa regione in cui è creato il NEG.
  • Per un bilanciatore del carico che utilizza un backend NEG serverless, il NEG serverless deve essere creato nello stesso progetto del supporto Cloud Run, App Engine Servizi API Gateway o Cloud Functions a cui puntano il NEG. Potresti notare che le richieste non vanno a buon fine se colleghi un servizio che non è nello stesso progetto del NEG serverless.
  • Un bilanciatore del carico configurato con un NEG serverless non può rilevare se le l'app o il servizio serverless sottostante funziona come previsto. Ciò significa che anche se il servizio restituisce errori, il bilanciatore del carico continua e indirizzare il traffico verso quest'ultima. Assicurati di eseguire test approfonditi delle nuove versioni dei servizi prima di instradarvi il traffico degli utenti.

Limitazioni con i servizi di backend

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

  • 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 di servizio di backend, tutti i NEG devono rappresentare funzionalmente equivalenti in diverse regioni. Ad esempio, i NEG possono puntare allo stesso Cloud Run, App Engine o servizio Cloud Functions di cui è stato eseguito il deployment in diverse regioni.
  • Un servizio di backend globale utilizzato dai bilanciatori del carico delle applicazioni interni tra regioni può avere a un solo servizio Cloud Run.
  • A un servizio di backend regionale può essere collegato un solo NEG serverless.
  • Riferimento ai servizi tra progetti in un deployment di una rete VPC condiviso, è supportata contengono un NEG serverless. Per utilizzare questa funzionalità, devi creare il bilanciatore del carico componenti frontend (indirizzo IP, regola di forwarding, proxy di destinazione e mappa URL) in un progetto diverso dai componenti backend del bilanciatore del carico (backend e NEG serverless). Nota che il servizio di backend, associato e il servizio serverless di supporto (Cloud Run, App Engine, API Gateway o Cloud Functions), devono essere sempre create nello stesso progetto.
  • Il timeout del servizio di backend impostazione non applicabile. ai servizi di backend con backend NEG serverless. Stai tentando di modificare la proprietà resource.timeoutSec del servizio di backend restituisce quanto segue: 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 a lunga esecuzione, configura i client in modo che ripetano le richieste in caso di errore.
  • Tutti i NEG serverless combinati in anche il servizio di backend deve usare lo stesso tipo di backend. Ciò significa I NEG serverless di Cloud Run possono essere combinati solo con altri NEG serverless Cloud Run e App Engine i NEG serverless possono essere combinati solo con App Engine serverless NEG.
  • Non puoi combinare NEG serverless con altri tipi di NEG nello stesso backend completamente gestito di Google Cloud. Ad esempio, non puoi eseguire il routing a un cluster GKE Servizio Cloud Run dallo stesso servizio di backend.
  • Quando configuri i servizi di backend che eseguono l'instradamento a NEG serverless, alcuni campi sono limitati:
    • Non puoi specificare una modalità di bilanciamento. ovvero RATE, UTILIZATION e I valori CONNECTION non hanno effetto sul traffico del bilanciatore del carico distribuzione dei contenuti.
    • I controlli di integrità non sono supportati per i backend serverless. Di conseguenza, i backend i servizi che contengono backend NEG serverless non possono essere configurati con l'integrità controlli. Tuttavia, puoi facoltativamente abilitare outlier rilevamento dei problemi per identificare lo stato serverless e instradare nuove richieste a un servizio serverless integro.
  • Non puoi utilizzare il comando gcloud compute backend-services edit per modificare con un servizio di backend NEG serverless. Come soluzione alternativa, utilizza il comando Comando gcloud compute backend-services update .

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

Limitazioni relative ai bilanciatori del carico delle applicazioni interni regionali e agli Application Load Balancer esterni regionali

  • NEG serverless utilizzati con i bilanciatori del carico delle applicazioni interni regionali, o i bilanciatori del carico delle applicazioni esterni regionali possono puntare solo a Cloud Run i servizi di machine learning.
  • Per i progetti che utilizzano NEG serverless, le query al secondo (QPS) il limite è di 5000 QPS per progetto per il traffico inviato a qualsiasi NEG serverless configurate con bilanciatori del carico delle applicazioni esterni regionali o bilanciatori del carico delle applicazioni interni regionali. Questo viene aggregato su tutti i bilanciatori del carico delle applicazioni esterni regionali di bilanciatori del carico delle applicazioni interni regionali nel progetto. Non si tratta di un bilanciatore del carico per singolo limite.

Limitazioni con i bilanciatori del carico delle applicazioni interni tra regioni

  • NEG serverless utilizzati con bilanciatori del carico delle applicazioni interni tra regioni può puntare solo ai servizi Cloud Run.

Limitazioni con i bilanciatori del carico delle applicazioni esterni globali

Questa sezione elenca le limitazioni che incontrerai durante la configurazione del serverless NEG con bilanciatori del carico delle applicazioni esterni globali

Limitazioni con App Engine

  • I bilanciatori del carico delle applicazioni esterni globali con backend dell'ambiente flessibile di App Engine non supportano l'utilizzo riferimenti di servizi tra progetti. L'ambiente standard di App Engine è supportato.

Limitazioni con 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 le proprietà autenticate richieste a dai servizi Cloud Run.

Limitazioni con Cloud Functions

  • IAP non funziona con Cloud Functions.

Limitazioni con App Engine

  • Il bilanciamento del carico multiregionale non è supportato con App Engine. Questo è perché App Engine richiede una regione per progetto.
  • È consentito un solo criterio IAP nel percorso di richiesta. Per Ad esempio, se hai già impostato un criterio IAP nel backend non devi impostare un altro criterio IAP nella dell'app App Engine.
  • Ti consigliamo di utilizzare i controlli in entrata in modo che la tua app riceva solo le richieste inviate dal bilanciatore del carico. (e il VPC, se lo usi). In caso contrario, gli utenti possono utilizzare URL di App Engine per bypassare il bilanciatore del carico, Google Cloud Armor criteri di sicurezza, certificati SSL e chiavi private che vengono trasmessi tramite il bilanciatore del carico.

Limitazioni con API Gateway

Per ulteriori informazioni, consulta Limitazioni dei NEG serverless e Gateway API.

Limitazioni delle funzionalità di gestione del traffico

  • Gestione avanzata del traffico come criterio per le località di bilanciamento del carico, affinità sessione e outlier il rilevamento non è supportato con i backend NEG serverless.
  • Specificare un affinità sessione su una con un backend NEG serverless non funzionerà. Come soluzione alternativa per Cloud Run, utilizza la sua funzione affinità sessione funzionalità.

Prezzi

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

Passaggi successivi