Configura un bilanciatore del carico delle applicazioni esterno globale con Cloud Run, App Engine o Cloud Run Functions

Questa pagina mostra come creare un bilanciatore del carico delle applicazioni esterno per instradare le richieste ai backend serverless. Il termine serverless si riferisce ai seguenti prodotti di calcolo serverless:

• App Engine
• Cloud Run Functions
• Cloud Run

L'integrazione dei bilanciatori del carico delle applicazioni esterni con API Gateway consente ai tuoi backend serverless di sfruttare tutte le funzionalità fornite da Cloud Load Balancing. Per configurare un bilanciatore del carico delle applicazioni esterno per instradare il traffico a un gateway API, consulta Guida introduttiva a un bilanciatore del carico delle applicazioni esterno per API Gateway. Il supporto del bilanciatore del carico delle applicazioni esterno per API Gateway è in anteprima.

I NEG serverless ti consentono di utilizzare le app serverless con i bilanciatori del carico delle applicazioni esterni.Google Cloud Dopo aver configurato un bilanciatore del carico con il backend NEG serverless, le richieste al bilanciatore del carico vengono indirizzate al backend dell'app serverless.

Per saperne di più sui NEG serverless, leggi la panoramica dei NEG serverless.

Prima di iniziare

1. Esegui il deployment di un servizio App Engine, Cloud Run Functions o Cloud Run.
2. Se non l'hai ancora fatto, installa Google Cloud CLI.
3. Configurare le autorizzazioni.
4. Aggiungi una risorsa del certificato SSL.

Esegui il deployment di un servizio App Engine, Cloud Run Functions o Cloud Run

Le istruzioni riportate in questa pagina presuppongono che tu abbia già un servizio Cloud Run, Cloud Run Functions o App Engine in esecuzione.

Per l'esempio in questa pagina, abbiamo utilizzato la guida rapida di Cloud Run Python per eseguire il deployment di un servizio Cloud Run nella regione us-central1. Il resto di questa pagina mostra come configurare un bilanciatore del carico delle applicazioni esterno che utilizza un backend NEG serverless per instradare le richieste a questo servizio.

Se non hai ancora eseguito il deployment di un'app serverless o se vuoi provare un NEG serverless con un'app di esempio, utilizza una delle seguenti guide rapide. Puoi creare un'app serverless in qualsiasi regione, ma devi utilizzare la stessa regione in un secondo momento per creare il NEG serverless e il bilanciatore del carico.

Cloud Run

Per creare una semplice applicazione Hello World, pacchettizzala in un'immagine container e poi esegui il deployment dell'immagine container in Cloud Run, consulta Guida rapida: crea ed esegui il deployment.

Se hai già caricato un container di esempio in Container Registry, consulta la Guida rapida: eseguire il deployment di un container di esempio preimpostato.

Cloud Run Functions

Vedi Cloud Run Functions: Guida rapida Python.

App Engine

Consulta le seguenti guide rapide di App Engine per Python 3:

• Ambiente standard
• Ambiente flessibile

Installa Google Cloud CLI

Installa Google Cloud CLI. Per informazioni concettuali e sull'installazione dello strumento, consulta la panoramica di gcloud.

Se non hai mai eseguito l'interfaccia alla gcloud CLI, esegui prima gcloud init per inizializzare la directory gcloud.

Configura autorizzazioni

Per seguire questa guida, devi creare un NEG serverless e un bilanciatore del carico HTTP(S) esterno in un progetto. Devi essere proprietario o editor di un progetto oppure disporre dei seguenti ruoli IAM di Compute Engine:

Prenotare un indirizzo IP esterno

Ora che i servizi sono operativi, configura un indirizzo IP esterno statico globale che i clienti utilizzano per raggiungere il bilanciatore del carico.

gcloud compute addresses create example-ip \
    --network-tier=PREMIUM \
    --ip-version=IPV4 \
    --global

gcloud compute addresses describe example-ip \
    --format="get(address)" \
    --global

Crea una risorsa del certificato SSL

Per creare un bilanciatore del carico HTTPS, devi aggiungere una risorsa certificato SSL al frontend del bilanciatore del carico. Crea una risorsa del certificato SSL utilizzando un certificato SSL gestito da Google o un certificato SSL autogestito.

• Certificati gestiti da Google. L'utilizzo di certificati gestiti da Google è consigliato perché Google Cloud ottiene, gestisce e rinnova questi certificati automaticamente. Per creare un certificato gestito da Google, devi disporre di un dominio e dei record DNS per quel dominio affinché il certificato venga sottoposto a provisioning.

  Inoltre, devi aggiornare il record A DNS del dominio in modo che punti all'indirizzo IP del bilanciatore del carico creato nel passaggio precedente (example-ip). Se hai più domini in un certificato gestito da Google, devi aggiornare i record DNS per tutti i domini e i sottodomini in modo che puntino all'indirizzo IP del bilanciatore del carico. Per istruzioni dettagliate, vedi Utilizzo dei certificati gestiti da Google.

• Certificati autofirmati. Se non vuoi configurare un dominio in questo momento, puoi utilizzare un certificato SSL autofirmato per i test.

Questo esempio presuppone che tu abbia già creato una risorsa del certificato SSL.

Se vuoi testare questa procedura senza creare una risorsa certificato SSL (o un dominio come richiesto dai certificati gestiti da Google), puoi comunque utilizzare le istruzioni riportate in questa pagina per configurare un bilanciatore del carico HTTP.

Crea il bilanciatore del carico

Nel seguente diagramma, il bilanciatore del carico utilizza un backend NEG serverless per indirizzare le richieste a un servizio Cloud Run serverless. Per questo esempio, abbiamo utilizzato la guida rapida di Cloud Run Python per eseguire il deployment di un servizio Cloud Run.

Poiché i controlli di integrità non sono supportati per i servizi di backend con backend NEG serverless, non è necessario creare una regola firewall che consenta i controlli di integrità se il bilanciatore del carico ha solo backend NEG serverless.

Collegare il dominio al bilanciatore del carico

Dopo aver creato il bilanciatore del carico, prendi nota dell'indirizzo IP associato al bilanciatore del carico, ad esempio 30.90.80.100. Per indirizzare il tuo dominio al bilanciatore del carico, crea un record A utilizzando il servizio di registrazione del dominio. Se hai aggiunto più domini al certificato SSL, devi aggiungere un record A per ciascuno, tutti indirizzati all'indirizzo IP del bilanciamento del carico. Ad esempio, per creare record A per www.example.com e example.com, utilizza quanto segue:

NAME                  TYPE     DATA
www                   A        30.90.80.100
@                     A        30.90.80.100

Se utilizzi Cloud DNS come provider DNS, consulta Aggiungere, modificare ed eliminare record.

Testa il bilanciatore del carico

Ora che hai configurato il bilanciatore del carico, puoi iniziare a inviare traffico al suo indirizzo IP. Se hai configurato un dominio, puoi inviare traffico anche al nome di dominio. Tuttavia, la propagazione DNS può richiedere tempo per essere completata, quindi puoi iniziare utilizzando l'indirizzo IP per i test.

1. Nella console Google Cloud , vai alla pagina Bilanciamento del carico.

   Vai a Bilanciamento del carico

2. Fai clic sul bilanciatore del carico che hai appena creato.

3. Prendi nota dell'indirizzo IP del bilanciatore del carico.

4. Per un bilanciatore del carico HTTP, puoi testare il bilanciatore del carico utilizzando un browser web andando su http://IP_ADDRESS. Sostituisci IP_ADDRESS con l'indirizzo IP del bilanciatore del carico. Dovresti essere indirizzato alla home page del servizio helloworld.
   

5. Per un bilanciatore del carico HTTPS, puoi testare il bilanciatore del carico utilizzando un browser web andando all'indirizzo https://IP_ADDRESS. Sostituisci IP_ADDRESS con l'indirizzo IP del bilanciatore del carico. Dovresti essere indirizzato alla home page del servizio helloworld.
   Se il problema persiste e utilizzi un certificato gestito da Google, verifica che lo stato della risorsa certificato sia ACTIVE. Per ulteriori informazioni, consulta Stato della risorsa certificato SSL gestito da Google.
   Se hai utilizzato un certificato autofirmato per i test, il browser visualizza un avviso. Devi indicare esplicitamente al browser di accettare un certificato autofirmato. Fai clic sull'avviso per visualizzare la pagina effettiva.

Opzioni di configurazione aggiuntive

Questa sezione espande l'esempio di configurazione per fornire opzioni di configurazione alternative e aggiuntive. Tutte le attività sono facoltative. Puoi eseguirle in qualsiasi ordine.

Configura il bilanciamento del carico multiregionale

Nell'esempio descritto in precedenza in questa pagina, abbiamo un solo servizio Cloud Run che funge da backend nella regione us-central1. Poiché il NEG serverless può puntare a un solo endpoint alla volta, il bilanciamento del carico non viene eseguito in più regioni. Il bilanciatore del carico delle applicazioni esterno funge solo da frontend e fa da proxy per il traffico verso l'endpoint dell'app helloworld specificato. Tuttavia, potresti voler pubblicare la tua app Cloud Run da più di una regione per migliorare la latenza per gli utenti finali.

Se a un servizio di backend sono collegati diversi NEG serverless, il bilanciatore del carico bilancia il traffico inoltrando le richieste al NEG serverless nella regione disponibile più vicina. Tuttavia, i servizi di backend possono contenere solo un NEG serverless per regione. Per rendere disponibile il tuo servizio Cloud Run da più regioni, devi configurare il routing tra regioni. Dovresti essere in grado di utilizzare un singolo schema URL che funzioni ovunque nel mondo, ma che gestisca le richieste degli utenti dalla regione più vicina.

Per configurare la pubblicazione multiregionale, devi utilizzare il livello di rete Premium per assicurarti che tutti i deployment Cloud Run regionali siano compatibili e pronti a gestire il traffico da qualsiasi regione.

Per configurare un bilanciatore del carico multiregionale:

1. Configura due servizi Cloud Run in regioni diverse. Supponiamo di aver eseguito il deployment di due servizi Cloud Run: uno in una regione degli Stati Uniti e l'altro in una regione d'Europa.
2. Crea un bilanciatore del carico delle applicazioni esterno con la seguente configurazione:
   1. Configura un servizio di backend globale con due NEG serverless:
      1. Crea il primo NEG nella stessa regione del servizio Cloud Run di cui è stato eseguito il deployment negli Stati Uniti.
      2. Crea il secondo NEG nella stessa regione del servizio Cloud Run di cui è stato eseguito il deployment in Europa.
   2. Configura la configurazione frontend con il livello di servizio di rete Premium.

La configurazione risultante è mostrata nel seguente diagramma.

Questa sezione si basa sulla configurazione del bilanciatore del carico descritta in precedenza in questa pagina, in cui hai creato un NEG serverless nella regione us-central1 che punta a un servizio Cloud Run nella stessa regione. Inoltre, presuppone che tu abbia creato un secondo servizio Cloud Run nella regione europe-west1. Il secondo NEG serverless che crei punterà a questo servizio Cloud Run nella regione europe-west1.

In questo esempio, completerai i seguenti passaggi:

1. Crea un secondo NEG serverless nella regione europe-west1.
2. Collega il secondo NEG serverless al servizio di backend.

Per aggiungere un secondo NEG serverless a un servizio di backend esistente, segui questi passaggi.

Utilizzare una sottoscrizione push Pub/Sub autenticata con un deployment Cloud Run multiregionale

Per le richieste push autenticate, Cloud Run prevede un campo audience specifico per la regione per impostazione predefinita. In caso di deployment Cloud Run multiregionale, se la richiesta push viene indirizzata a un servizio Cloud Run in un'altra regione, la verifica del token JWT non va a buon fine a causa di una mancata corrispondenza del pubblico.

Per ovviare a questa limitazione specifica per regione:

1. Configura un segmento di pubblico personalizzato che sia lo stesso per i deployment di servizi in regioni diverse.
2. Configura i messaggi push Pub/Sub in modo che utilizzino il segmento di pubblico personalizzato come segmento di pubblico nel token JWT.

Configurare il routing regionale

Un motivo comune per la pubblicazione di applicazioni da più regioni è soddisfare i requisiti di località dei dati. Ad esempio, potresti voler assicurarti che le richieste effettuate dagli utenti europei vengano sempre gestite da una regione situata in Europa. Per configurare questa opzione, devi disporre di uno schema di URL con URL separati per gli utenti dell'UE e non UE e indirizzare gli utenti dell'UE agli URL dell'UE.

In questo scenario, utilizzeresti la mappa URL per instradare le richieste da URL specifici alle regioni corrispondenti. Con questa configurazione, le richieste destinate a una regione non vengono mai inviate a un'altra regione. Ciò garantisce l'isolamento tra le regioni. D'altra parte, quando una regione non funziona, le richieste non vengono indirizzate a un'altra regione. Pertanto, questa configurazione non aumenta la disponibilità del servizio.

Per configurare il routing regionale, devi utilizzare il livello di rete Premium in modo da poter combinare diverse regioni in un'unica regola di forwarding.

Per configurare un bilanciatore del carico con routing regionale:

1. Configura due servizi Cloud Run in regioni diverse. Supponiamo di aver eseguito il deployment di due servizi Cloud Run: hello-world-eu in una regione in Europa e hello-world-us in una regione negli Stati Uniti.
2. Crea un bilanciatore del carico delle applicazioni esterno con la seguente configurazione:
   1. Configura un servizio di backend con un NEG serverless in Europa. Il NEG serverless deve essere creato nella stessa regione del servizio Cloud Run di cui è stato eseguito il deployment in Europa.
   2. Configura un secondo servizio di backend con un altro NEG serverless negli Stati Uniti. Questo NEG serverless deve essere creato nella stessa regione del servizio Cloud Run di cui è stato eseguito il deployment negli Stati Uniti.
   3. Configura la mappa URL con le regole host e percorso appropriate in modo che un insieme di URL venga instradato al servizio di backend europeo, mentre tutte le richieste vengano instradate al servizio di backend statunitense.
   4. Configura la configurazione frontend con il livello di rete Premium.

Il resto della configurazione può essere lo stesso descritto in precedenza. La configurazione risultante dovrebbe essere simile a questa:

Utilizzare una maschera URL

Quando crei un NEG serverless, anziché selezionare un servizio Cloud Run specifico, puoi utilizzare una maschera URL per indirizzare più servizi che vengono pubblicati nello stesso dominio. Una maschera URL è un modello dello schema dell'URL. Il NEG serverless utilizzerà questo modello per estrarre il nome del servizio dall'URL della richiesta in entrata e mappare la richiesta al servizio appropriato.

Le maschere URL sono particolarmente utili se il tuo servizio è mappato a un dominio personalizzato anziché all'indirizzo predefinito fornito daGoogle Cloud per il servizio di cui è stato eseguito il deployment. Una maschera URL ti consente di scegliere come target più servizi e versioni con una singola regola anche quando la tua applicazione utilizza un pattern URL personalizzato.

Se non l'hai ancora fatto, assicurati di leggere Panoramica dei NEG serverless: maschere URL.

Costruire una maschera URL

Per creare una maschera URL per il bilanciatore del carico, inizia con l'URL del tuo servizio. Per questo esempio, utilizzeremo un'app serverless di esempio in esecuzione all'indirizzo https://example.com/login. Questo è l'URL in cui verrà pubblicato il servizio login dell'app.

1. Rimuovi http o https dall'URL. Ti rimangono example.com/login.
2. Sostituisci il nome del servizio con un segnaposto per la maschera URL.
   1. Cloud Run: sostituisci il nome del servizio Cloud Run con il segnaposto <service>. Se il servizio Cloud Run ha un tag associato, sostituisci il nome del tag con il segnaposto <tag>. In questo esempio, la maschera URL rimanente è example.com/<service>.
   2. Funzioni Cloud Run: sostituisci il nome della funzione con il segnaposto <function>. In questo esempio, la maschera URL rimanente è example.com/<function>.
   3. App Engine: sostituisci il nome del servizio con il segnaposto <service>. Se al servizio è associata una versione, sostituiscila con il segnaposto <version>. In questo esempio, la maschera URL rimanente è example.com/<service>.
   4. API Gateway: sostituisci il nome del gateway con il segnaposto <gateway>. In questo esempio, la maschera URL rimanente è example.com/<gateway>.

3. (Facoltativo) Se il nome del servizio (o la funzione, la versione o il tag) può essere estratto dalla parte del percorso dell'URL, il dominio può essere omesso. La parte del percorso della maschera URL è distinta dal primo carattere /. Se / non è presente nella maschera URL, si presume che la maschera rappresenti solo l'host. Pertanto, per questo esempio, la maschera URL può essere ridotta a /<service>, /<gateway> o /<function>.

   Allo stesso modo, se il nome del servizio può essere estratto dalla parte host dell'URL, puoi omettere completamente il percorso dalla maschera URL.

   Puoi anche omettere qualsiasi componente di host o sottodominio che precede il primo segnaposto, nonché qualsiasi componente di percorso che segue l'ultimo segnaposto. In questi casi, il segnaposto acquisisce le informazioni richieste per il componente.

Ecco alcuni altri esempi che dimostrano queste regole:

Crea un NEG serverless con una maschera URL

gcloud compute network-endpoint-groups create helloworld-neg-mask \
  --region=us-central1 \
  --network-endpoint-type=serverless \
  --cloud-run-url-mask="example.com/<service>"

gcloud compute network-endpoint-groups create helloworld-neg-mask \
 --region=us-central1 \
 --network-endpoint-type=serverless \
 --cloud-function-url-mask="example.com/<service>"

gcloud compute network-endpoint-groups create helloworld-neg-mask \
    --region=us-central1 \
    --network-endpoint-type=serverless \
    --app-engine-url-mask="example.com/<service>"

gcloud beta compute network-endpoint-groups create helloworld-neg-mask \
  --region=us-central1 \
  --network-endpoint-type=serverless \
  --serverless-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-resource=my-gateway \
  --serverless-deployment-url-mask="example.com/<gateway>"

Per scoprire come il bilanciatore del carico gestisce i problemi relativi alle mancate corrispondenze della maschera URL, consulta Risoluzione dei problemi relativi ai NEG serverless.

Sposta il tuo dominio personalizzato in modo che venga gestito dal bilanciatore del carico delle applicazioni esterno

Se le tue app di serverless computing vengono mappate a domini personalizzati, potresti voler aggiornare i record DNS in modo che il traffico inviato agli URL dei domini personalizzati esistenti di Cloud Run, Cloud Run Functions, API Gateway o App Engine venga instradato tramite il bilanciatore del carico.

Ad esempio, se hai un dominio personalizzato chiamato example.com e tutti i tuoi servizi Cloud Run sono mappati a questo dominio, devi aggiornare il record DNS per example.com in modo che punti all'indirizzo IP del bilanciatore del carico.

Prima di aggiornare i record DNS, puoi testare la configurazione localmente forzando la risoluzione DNS locale del dominio personalizzato all'indirizzo IP del bilanciamento del carico. Per eseguire il test localmente, modifica il file /etc/hosts/ sulla tua macchina locale in modo che example.com punti all'indirizzo IP del bilanciatore del carico oppure utilizza il flag curl --resolve per forzare curl a utilizzare l'indirizzo IP del bilanciatore del carico per la richiesta.

Quando il record DNS per example.com viene risolto nell'indirizzo IP del bilanciatore del carico HTTP(S), le richieste inviate a example.com iniziano a essere instradate tramite il bilanciatore del carico. Il bilanciatore del carico le invia al servizio di backend pertinente in base alla mappa URL. Inoltre, se il servizio di backend è configurato con una maschera URL, il NEG serverless utilizza la maschera per instradare la richiesta al servizio Cloud Run, Cloud Run Functions, API Gateway o App Engine appropriato.

Abilita Cloud CDN

L'attivazione di Cloud CDN per il servizio Cloud Run consente di ottimizzare la distribuzione dei contenuti memorizzandoli nella cache vicino agli utenti.

Puoi attivare Cloud CDN sui servizi di backend utilizzati dai bilanciatori del carico delle applicazioni esterni globali utilizzando il comando gcloud compute backend-services update.

gcloud compute backend-services update helloworld-backend-service 

    --enable-cdn 

    --global

Cloud CDN è supportato per i servizi di backend con Cloud Run, Cloud Run Functions, API Gateway e backend App Engine.

Abilita IAP sul bilanciatore del carico delle applicazioni esterno

Puoi configurare IAP in modo che sia attivato o disattivato (impostazione predefinita). Se attivata, devi fornire valori per oauth2-client-id e oauth2-client-secret.

Per abilitare IAP, aggiorna il servizio di backend in modo da includere il flag --iap=enabled con oauth2-client-id e oauth2-client-secret.

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --iap=enabled,oauth2-client-id=ID,oauth2-client-secret=SECRET \
    --global

Se vuoi, puoi abilitare IAP per una risorsa Compute Engine utilizzando la console Google Cloud , gcloud CLI o l'API.

Attiva Google Cloud Armor

Google Cloud Armor è un prodotto di sicurezza che fornisce protezione contro gli attacchi DDoS (Distributed Denial-of-Service) a tutti i bilanciatori del carico proxy GCLB. Google Cloud Armor fornisce anche criteri di sicurezza configurabili ai servizi a cui si accede tramite un bilanciatore del carico delle applicazioni esterno. Per saperne di più sui criteri di sicurezza di Google Cloud Armor per i bilanciatori del carico delle applicazioni esterni, consulta la panoramica dei criteri di sicurezza di Google Cloud Armor.

Se utilizzi le funzioni Cloud Run, puoi assicurarti che le richieste inviate agli URL predefiniti vengano bloccate utilizzando l'impostazione di traffico in entrata internal-and-gclb.

Se utilizzi Cloud Run, puoi assicurarti che le richieste inviate agli URL predefiniti o a qualsiasi altro dominio personalizzato configurato tramite Cloud Run siano bloccate limitando il traffico in entrata a "bilanciamento del carico interno e cloud".

Se utilizzi App Engine, puoi utilizzare i controlli di ingresso in modo che la tua app riceva solo le richieste inviate dal bilanciatore del carico (e dalla VPC se la utilizzi).

Senza le impostazioni di ingresso corrette, gli utenti possono utilizzare l'URL predefinito dell'applicazione serverless per bypassare il bilanciamento del carico, le policy di sicurezza Google Cloud Armor, i certificati SSL e le chiavi private che vengono passati tramite il bilanciamento del carico.

(Facoltativo) Configura una policy di sicurezza del backend predefinita. Il criterio di sicurezza predefinito limita il traffico in base a una soglia configurata dall'utente. Per ulteriori informazioni sulle norme di sicurezza predefinite, consulta la panoramica della limitazione della frequenza.

1. Per disattivare i criteri di sicurezza predefiniti di Google Cloud Armor, seleziona None nel menu dell'elenco dei criteri di sicurezza del backend.
2. Nella sezione Sicurezza, seleziona Norme di sicurezza predefinite.
3. Nel campo Nome criterio, accetta il nome generato automaticamente o inserisci un nome per il criterio di sicurezza.
4. Nel campo Conteggio richieste, accetta il conteggio richieste predefinito o inserisci un numero intero compreso tra 1 e 10,000.
5. Nel campo Intervallo, seleziona un intervallo.
6. Nel campo Imponi su chiave, scegli uno dei seguenti valori: Tutti, Indirizzo IP o Indirizzo IP X-Forwarded-For. Per saperne di più su queste opzioni, vedi Identificare i client per la limitazione della frequenza.

Abilitare il logging e il monitoraggio

Puoi abilitare, disabilitare e visualizzare i log per un servizio di backend del bilanciatore del carico delle applicazioni esterno. Quando utilizzi la console Google Cloud , la registrazione è abilitata per impostazione predefinita per i servizi di backend con backend NEG serverless. Puoi utilizzare gcloud per disattivare la registrazione per ogni servizio di backend in base alle esigenze. Per istruzioni, vedi Registrazione.

Il bilanciatore del carico esporta anche i dati di monitoraggio in Cloud Monitoring. Le metriche di monitoraggio possono essere utilizzate per valutare la configurazione, l'utilizzo e il rendimento di un bilanciatore del carico. Le metriche possono essere utilizzate anche per risolvere i problemi e migliorare l'utilizzo delle risorse e l'esperienza utente. Per istruzioni, vedi Monitoraggio.

Aggiorna il timeout keepalive HTTP del client

Per aggiornare il timeout keepalive HTTP del client, segui queste istruzioni.

    gcloud compute target-http-proxies update TARGET_HTTP_PROXY_NAME \
        --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
        --global
    

    gcloud compute target-https-proxies update TARGET_HTTPS_PROXY_NAME \
        --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
        --global
    

Abilita rilevamento outlier

Puoi attivare il rilevamento di outlier sui servizi di backend globali per identificare i NEG serverless non integri e ridurre il numero di richieste inviate ai NEG serverless non integri.

Il rilevamento degli outlier è abilitato nel servizio di backend utilizzando uno dei seguenti metodi:

• Il metodo consecutiveErrors (outlierDetection.consecutiveErrors), in cui un codice di stato HTTP della serie 5xx viene considerato un errore.
• Il metodo consecutiveGatewayFailure (outlierDetection.consecutiveGatewayFailure), in cui solo i codici di stato HTTP 502, 503 e 504 sono considerati errori.

Per attivare il rilevamento degli outlier per un servizio di backend esistente: Tieni presente che, anche dopo aver attivato il rilevamento dei valori anomali, alcune richieste possono essere inviate al servizio non integro e restituire un codice di stato 5xx ai client. Per ridurre ulteriormente il tasso di errore, puoi configurare valori più aggressivi per i parametri di rilevamento dei valori anomali. Per ulteriori informazioni, consulta il campo outlierDetection.

Eliminare un NEG serverless

Un gruppo di endpoint di rete non può essere eliminato se è collegato a un servizio di backend. Prima di eliminare un NEG, assicurati che sia scollegato dal servizio di backend.

gcloud compute backend-services remove-backend helloworld-backend-service \
    --network-endpoint-group=helloworld-serverless-neg \
    --network-endpoint-group-region=us-central1 \
    --global

gcloud compute network-endpoint-groups delete helloworld-serverless-neg \
    --region=us-central1

Passaggi successivi

• Utilizzo di logging e monitoraggio
• Risolvere i problemi relativi ai NEG serverless
• Pulisci la configurazione del bilanciatore del carico
• Utilizzo di un modulo Terraform per un bilanciatore del carico HTTPS esterno con un backend Cloud Run