Gestione del traffico del gateway

Autopilot . . Standard

---

Questa pagina spiega come funziona la gestione del traffico del gateway.

Panoramica

Il networking di Google Kubernetes Engine (GKE) si basa su Cloud Load Balancing. Con Cloud Load Balancing, un singolo indirizzo IP anycast fornisce traffico globale gestione dei dispositivi. Gestione del traffico di Google offre bilanciamento del carico, scalabilità automatica e capacità a livello globale e regionale per fornire una distribuzione del traffico equalizzata, stabile e a bassa latenza. L'utilizzo del Controller gateway GKE, Gli utenti GKE possono utilizzare il controllo globale della gestione del traffico di Google in modo dichiarativo e nativo di Kubernetes.

Per provare lo spillover del traffico tra i cluster, vedi Deployment del bilanciamento del carico basato sulla capacità. Per provare la scalabilità automatica basata sul traffico, consulta Scalabilità automatica in base al traffico del bilanciatore del carico.

Gestione del traffico

Il bilanciamento del carico, la scalabilità automatica e la gestione della capacità sono le basi di una di gestione del traffico. Operano insieme per uguagliare e stabilizzare carico di sistema.

• Il bilanciamento del carico distribuisce il traffico tra i pod di backend in base a posizione, integrità e diversi algoritmi di bilanciamento del carico.
• La scalabilità automatica scala le repliche dei carichi di lavoro per creare maggiore capacità di assorbimento più traffico.
• La gestione della capacità monitora l'utilizzo dei Servizi in modo da il traffico può raggiungere i backend con capacità anziché influire la disponibilità o le prestazioni delle applicazioni.

Queste funzionalità possono essere combinate in diversi modi a seconda degli obiettivi. Ad esempio:

• Se vuoi sfruttare i vantaggi a basso costo Spot VM, per ottimizzare la distribuzione uniforme del traffico tra le VM spot Costo della latenza. Utilizzando il bilanciamento del carico e la gestione della capacità, GKE supererebbe il traffico tra le regioni in base alla capacità in modo che le VM spot siano completamente utilizzate ovunque siano disponibili.

• Se vuoi ottimizzare la latenza degli utenti a costo dell'overprovisioning, potrebbe eseguire il deployment di cluster GKE in molte regioni e aumentare la capacità in modo dinamico ogni volta che il carico aumenta. Utilizzo del bilanciamento del carico e della scalabilità automatica GKE scala automaticamente il numero di pod quando aumenta il traffico, che il traffico non debba passare ad altre regioni. Le regioni di capacità di crescita in modo da poter gestire completamente il carico il più vicino possibile possibili agli utenti.

Il seguente diagramma mostra bilanciamento del carico, scalabilità automatica e gestione della capacità che operano in sinergia:

Nel diagramma, il carico di lavoro nel cluster gke-us non è riuscito. Bilanciamento del carico e il controllo di integrità svuota le connessioni attive e reindirizza il traffico alla cluster più vicino. Il carico di lavoro in gke-asia riceve più traffico ha una capacità massima, quindi riduce il carico a gke-eu. gke-eu riceve più carico del solito a causa degli eventi in gke-us e gke-asia, quindi gke-eu consente la scalabilità automatica per aumentarne la capacità di traffico.

Per saperne di più su come Cloud Load Balancing gestisce la gestione del traffico, consulta gestione globale della capacità.

Funzionalità di gestione del traffico

Le risorse Gateway, HTTPRoute, Service e Policy forniscono i controlli per gestire il traffico in GKE. La Controller gateway GKE è il piano di controllo che monitora queste risorse.

Durante il deployment sono disponibili le seguenti funzionalità di gestione del traffico Servizi in GKE:

• Capacità del servizio: la possibilità di specificare la quantità di capacità di traffico. che un servizio può ricevere prima che i pod vengano scalati automaticamente o l'overflow del traffico in altri cluster disponibili.
• Scalabilità automatica basata sul traffico: scalabilità automatica dei pod all'interno di un servizio in base Richieste HTTP ricevute al secondo.

• Bilanciamento del carico multi-cluster: la capacità di bilanciare il carico verso i servizi ospitati in più cluster GKE o in più regioni.

• Suddivisione del traffico: distribuzione esplicita del traffico basata sulla ponderazione tra di backend. La suddivisione del traffico è supportata con i gateway a cluster singolo in GA.

Assistenza per la gestione del traffico

Le funzionalità di gestione del traffico disponibili dipendono dal GatewayClass che di cui esegui il deployment. Per un elenco completo delle funzioni supportate, vedi Funzionalità GatewayClass. La tabella seguente riassume il supporto di GatewayClass per la gestione del traffico:

GatewayClass	Capacità del servizio	Scalabilità automatica del traffico	Bilanciamento del carico multi-cluster	Suddivisione del traffico^1
gke-l7-global-external-managed
gke-l7-regional-external-managed
gke-l7-rilb
gke-l7-gxlb
gke-l7-global-external-managed-mc
gke-l7-regional-external-managed-mc
gke-l7-rilb-mc
gke-l7-gxlb-mc

¹ La suddivisione del traffico è supportata con i gateway a cluster singolo in GA.

Bilanciamento del carico globale, regionale e a livello di zona

La capacità, la località e l'integrità del servizio determinano il volume di traffico generato dal carico da un bilanciatore del carico a un determinato backend. Le decisioni relative al bilanciamento del carico vengono prese livelli successivi, a partire da Global per bilanciatori del carico globali e per i bilanciatori del carico a livello di regione:

• Globale: il traffico viene inviato alla regione Google Cloud più vicina a il client che ha backend integri con capacità. Finché la regione ha riceve tutto il traffico più vicino. Se una regione non ha capacità massima, il traffico in eccesso va oltre la regione successiva più vicina con capacità. Per scoprire di più, consulta la sezione sul bilanciamento del carico globale.
• A livello di regione: il traffico viene inviato dal bilanciatore del carico a una regione specifica. La il traffico viene bilanciato tra le zone in proporzione alla disponibilità e capacità di distribuzione. Per saperne di più, consulta Bilanciamento del carico a livello di regione.
• Zonal: dopo aver determinato il traffico per una zona specifica, il bilanciatore del carico distribuisce uniformemente il traffico tra i backend all'interno di quella zona. TCP esistente le connessioni e le impostazioni di persistenza della sessione vengono conservate, in modo che in futuro va agli stessi backend, purché il pod di backend sia integro. A Per saperne di più, consulta Bilanciamento del carico a livello di zona.

Bilanciamento del carico globale e overflow del traffico

Per provare i seguenti concetti nel tuo cluster, vedi Bilanciamento del carico basato sulla capacità.

In condizioni normali, il traffico viene inviato al backend più vicino al client. Il traffico termina al POP Google più vicino allo e poi attraversa il backbone di Google fino a raggiungere il più vicino come determinato dalla latenza di rete. Quando i backend in una regione non ha capacità rimanente, il traffico va in overflow verso il cluster successivo più vicino integre e con capacità sufficiente. Se meno del 50% dei pod di backend in un una zona non è integro, quindi esegue gradualmente il failover del traffico verso altre zone o regioni indipendentemente dalla capacità configurata.

L'overflow del traffico si verifica solo nelle seguenti condizioni:

• Stai utilizzando un Gateway multi-cluster.
• Il deployment dello stesso servizio è stato eseguito in più cluster, gestito dal un gateway multi-cluster.
• Sono state configurate capacità di servizio in modo che il traffico superi il servizio solo in un cluster, ma non in altri.

Il seguente diagramma mostra il funzionamento del bilanciamento del carico globale con il traffico overflow:

Nel diagramma:

• Un gateway multi-cluster fornisce il bilanciamento del carico internet globale per Servizio store. Il deployment del servizio viene eseguito in due cluster, uno in us-west1 e l'altro in europe-west1. Ogni cluster che esegue 2 repliche.
• Ogni servizio è configurato con max-rate-per-endpoint="10", il che significa che Ogni servizio ha una capacità totale di 2 repliche * 10 RPS = 20 RPS in ogni cluster.
• I PoP di Google in Nord America ricevono 6 RPS. Tutto il traffico viene inviato alla il backend integro più vicino con capacità, il cluster GKE us-west1.
• I PoP europei ricevono 30 RPS cumulativi. I backend più vicini si trovano europe-west1, ma ha solo 20 RPS di capacità. Poiché i backend in us-west1 hanno capacità in eccesso, 10 RPS vengono overflow in us-west1 in modo che riceve 16 RPS in totale e distribuisce 8 RPS a ogni pod.

Nota: se utilizzi gateway a cluster singolo, un servizio di tipo LoadBalancer, o risorse Ingress, questo esempio di bilanciamento del carico globale non si applica poiché queste risorse bilanciano il carico solo in un singolo cluster all'interno di una singola regione. I gateway multi-cluster sono consigliati se disponi di di bilanciamento del carico a livello globale.

Come evitare l'overflow del traffico

L'overflow del traffico aiuta a evitare il superamento della capacità dell'applicazione che può influire le prestazioni o la disponibilità.

Tuttavia, ti consigliamo di non sovraccaricare il traffico. applicazioni sensibili alla latenza, Ad esempio, potrebbero non trarre vantaggio dall'overflow del traffico verso un punto backend.

Per evitare l'overflow del traffico, puoi utilizzare uno qualsiasi dei seguenti metodi:

• Utilizza solo gateway a cluster singolo che possono ospitare servizi in un solo in un cluster Kubernetes.

• Anche se utilizzi gateway multi-cluster, le repliche di un'applicazione di cui è stato eseguito il deployment il deployment in più cluster può essere eseguito come servizi separati. Da dal gateway, questo consente il bilanciamento del carico multi-cluster, non aggrega tutti gli endpoint di un servizio tra i cluster.

• Imposta le capacità del servizio a un livello sufficientemente elevato da non consentire mai la capacità di traffico realisticamente superati se non strettamente necessario.

Bilanciamento del carico all'interno di una regione

All'interno di una regione, il traffico viene distribuito tra le zone in base al numero e le capacità dei backend. Questa funzionalità non usa l'overflow, ma carica bilanciamento in proporzione diretta alle capacità del Servizio in ciascuna zona. Qualsiasi un singolo flusso o una singola sessione vengono sempre inviati a un unico pod di backend coerente e non è suddiviso.

Il seguente diagramma mostra come il traffico viene distribuito all'interno di una regione:

Nel diagramma:

• Il deployment di un servizio viene eseguito in un cluster GKE a livello di regione. Il Servizio ha quattro pod, il cui deployment viene eseguito in modo non uniforme tra le zone. 3 pod si trovano nella zona A, 1 pod si trova nella zona B e 0 pod si trovano nella zona C.
• Il servizio è configurato con max-rate-per-endpoint="10". La zona A ha 30 RPS della capacità totale, la zona B ha 10 RPS di capacità totale e la zona C ha 0 RPS della capacità totale, perché non ha pod.
• Il gateway riceve un totale di 16 RPS di traffico da client diversi. Questo traffico viene distribuito nelle zone in proporzione al traffico rimanente in ogni zona.
• Il flusso di traffico da ogni singola sorgente o cliente viene caricato costantemente. bilanciato in un singolo pod di backend in base alla persistenza della sessione impostazioni. La distribuzione del traffico si suddivide tra diversi tipi di traffico di origine in modo che i singoli flussi non vengano mai suddivisi. Di conseguenza, un valore minimo è necessaria una varietà di origini o clienti per distribuire in modo granulare e il traffico tra i backend.

Ad esempio, se il traffico in entrata aumenta da 16 RPS a 60 RPS, si verificherebbero i seguenti scenari:

• Se utilizzi gateway a cluster singolo, non esistono altri cluster o regioni del traffico. Il traffico continua a essere distribuito alle capacità di zona relative, anche se il traffico in entrata supera il totale e la capacità di archiviazione. Di conseguenza, la zona A riceve 45 RPS e la zona B riceve 15 RPS.
• Se utilizzi gateway multi-cluster con i servizi distribuiti su più cluster, il traffico può sovraccaricare altri cluster e altre regioni descritto in Bilanciamento del carico globale e overflow del traffico. La zona A riceve 30 RPS, la zona B riceve 10 RPS e 20 RPS overflow in un altro cluster.

Nota: Cloud Load Balancing non elimina automaticamente il traffico quando i backend sono sovra-capacità. Il traffico va in overflow verso tutti i backend disponibili che e la capacità di archiviazione. Se tutti i backend hanno capacità eccessiva, il traffico di overflow viene distribuito tra tutti i backend in proporzione alle loro capacità totali. Questo supera la capacità totale del servizio.

Bilanciamento del carico all'interno di una zona

Una volta inviato a una zona, il traffico viene distribuito uniformemente tra tutte le zone all'interno di quella zona. Le sessioni HTTP sono permanenti a seconda della sessione dell'impostazione di affinità. A meno che il backend non diventi non disponibile, le connessioni non vengono mai spostate in un backend diverso. Ciò significa che i pod continuano ad andare allo stesso pod di backend anche se nuove connessioni overflow a causa della capacità limitata. Il bilanciatore del carico dà priorità al mantenimento esistenti rispetto a quelle nuove.

Capacità del servizio

Con la capacità del servizio, puoi definire un valore di richieste al secondo (RPS) per pod in un servizio. Questo valore rappresenta il numero massimo di RPS per pod in media che un che può ricevere. Questo valore è configurabile in Servizi e viene utilizzato per Determinare la scalabilità automatica basata sul traffico e il bilanciamento del carico basato sulla capacità.

Requisiti

La capacità del servizio presenta i seguenti requisiti e limitazioni:

• Supportata solo con le risorse GatewayClass e i tipi Ingress definiti in Assistenza per la gestione del traffico.

• Influisce sul bilanciamento del carico solo se utilizzi la scalabilità automatica basata sul traffico gateway multi-cluster. Se non utilizzi queste funzionalità, il Servizio non influisce sul traffico di rete.

Configura capacità del servizio

Per configurare la capacità del servizio, crea un servizio utilizzando l'annotazione networking.gke.io/max-rate-per-endpoint. Il seguente file manifest descrive Servizio con un numero massimo di RPS:

apiVersion: v1
kind: Service
metadata:
  name: store
  annotations:
    networking.gke.io/max-rate-per-endpoint: "RATE_PER_SECOND"
spec:
  ports:
  - port: 8080
    targetPort: 8080
    name: http
  selector:
    app: store
  type: ClusterIP

Sostituisci RATE_PER_SECOND con il valore massimo HTTP/HTTPS richieste al secondo che un singolo pod in questo servizio dovrebbe ricevere.

Il valore max-rate-per-endpoint crea una capacità dinamica per un servizio basato in base al numero di pod nel servizio. Il valore totale della capacità di servizio è calcolato moltiplicando il valore max-rate-per-endpoint per il numero di di repliche, come descritto nella seguente formula:

Total Service capacity = max-rate-per-endpoint * number of replicas

Se un gestore della scalabilità automatica fa lo scale up del numero di pod all'interno di un servizio, La capacità totale del servizio viene calcolata di conseguenza. Se viene fatto lo scale down di un servizio a con zero pod, non ha capacità e non riceve traffico con il bilanciatore del carico di rete passthrough esterno regionale.

Nota: la configurazione della capacità del servizio utilizzando max-rate-per-endpoint l'annotazione si applica solo al traffico che entra attraverso una gateway supportato. Non influenza il bilanciamento del carico basato sulla capacità per il bilanciamento del carico di ClusterIP all'interno del cluster o per servizi di tipo LoadBalancer.

Capacità di servizio e NEG autonomi

La capacità del servizio può essere configurata anche quando si utilizza NEG autonomi, tuttavia non utilizza l'annotazione max-rate-per-endpoint. Quando utilizzi NEG autonomi, max-rate-per-endpoint viene configurato manualmente quando si aggiunge il NEG a un Risorsa del servizio di backend. L'utilizzo del gcloud compute backend-services add- backend il flag --max-rate-per-endpoint può configurare la capacità per ogni NEG singolarmente.

Ciò può essere utile per uno qualsiasi dei seguenti flussi di lavoro:

• Quando esegui manualmente il deployment di bilanciatori del carico interni ed esterni utilizzando la modalità autonoma NEG
• Durante il deployment Cloud Service Mesh su GKE con NEG autonomi

Non c'è alcuna differenza funzionale quando si configura la capacità del servizio con NEG autonomi. Sono supportati sia la scalabilità automatica del traffico sia lo spillover del traffico.

Determina la capacità del servizio

Per determinare il valore di max-rate-per-endpoint è necessario comprendere le caratteristiche prestazionali delle applicazioni e gli obiettivi di bilanciamento del carico. La le seguenti strategie possono aiutarti a definire le prestazioni della tua applicazione caratteristiche:

• osserva la tua applicazione in ambienti sia di test che di produzione quando è configurata senza capacità di servizio.
• Utilizza Cloud Monitoring per creare una correlazione tra richieste di traffico e gli obiettivi del livello di servizio (SLO) per le prestazioni.

• Utilizza le funzionalità di metriche del bilanciatore del carico, come https o request_count per mappare i livelli RPS.

• Definisci gli SLO di prestazioni per la tua applicazione. Potrebbe trattarsi di uno di questi o più dei seguenti, a seconda di ciò che consideri "scarso" o "instabile" delle prestazioni. Tutti i seguenti dati possono essere raccolti da Cloud Monitoring metriche del bilanciatore del carico:
  • Codici di errore di risposta
  • Latenza totale o risposta
  • Integrità o tempo di inattività del backend
• Osserva la tua applicazione sotto il carico di traffico sia in test che in produzione ambienti cloud-native. Negli ambienti di test, sottoponi la tua applicazione per capire l'impatto sulle diverse metriche relative alle prestazioni all'aumento del traffico. Negli ambienti di produzione, osserva il traffico realistico e mantenere i livelli di pattern del tuo percorso.

Capacità di servizio predefinita

Tutti i servizi collegati alle risorse GKE hanno un servizio predefinito configurata anche se non è configurata esplicitamente tramite annotazione. Per scoprire di più, consulta la sezione Capacità di servizio predefinita.

Nella tabella seguente sono descritte le capacità predefinite:

Tipo di risorsa di bilanciamento del carico	Valore predefinito: max-rate-per-endpoint
In entrata (interna ed esterna)	1 RPS
Gateway (tutti i GatewayClass)	100.000.000 RPS
MultiClusterIngress	100.000.000 RPS

Scalabilità automatica basata sul traffico

La scalabilità automatica basata sul traffico è una funzionalità di GKE che, integra gli indicatori di traffico dai bilanciatori del carico alla scalabilità automatica dei pod. Basato sul traffico la scalabilità automatica è supportata solo per i gateway a cluster singolo.

Per utilizzare la scalabilità automatica basata sul traffico, consulta Scalabilità automatica in base al traffico del bilanciatore del carico.

La scalabilità automatica basata sul traffico offre i seguenti vantaggi:

• Le applicazioni che non sono strettamente legate alla CPU o alla memoria potrebbero avere capacità limiti che non si riflettono nell'utilizzo di CPU o memoria.
• Traffico o richieste al secondo (RPS) è una metrica più facile da comprendere in alcuni casi perché è più allineato con le metriche aziendali e di utilizzo dell'app come le visualizzazioni di pagina o gli utenti attivi giornalieri (DAU).
• Il traffico è un indicatore principale che rappresenta la domanda istantanea rispetto a con CPU o memoria, che sono indicatori di ritardo.
• La combinazione di metriche di scalabilità automatica di CPU, memoria e traffico un modo olistico di scalare le applicazioni utilizzando più dimensioni per per verificare che il provisioning della capacità sia stato eseguito in modo appropriato.

Il seguente diagramma mostra come funziona la scalabilità automatica basata sul traffico:

Nel diagramma:

• Il proprietario del servizio configura la capacità del servizio e un utilizzo target per per il deployment.
• Il gateway riceve traffico dai client che vanno al servizio store. La Il gateway invia la telemetria di utilizzo al gestore della scalabilità automatica del pod GKE. L'utilizzo equivale al traffico effettivo ricevuto da un singolo pod divisa per la capacità configurata del pod.
• Il gestore della scalabilità automatica del pod GKE esegue lo scale up o lo scale down dei pod in base per l'utilizzo target configurato.

Comportamento di scalabilità automatica

Il seguente diagramma mostra come funziona la scalabilità automatica basata sul traffico un'applicazione che riceve 10 RPS tramite il bilanciatore del carico:

Nel diagramma, il proprietario del servizio ha configurato la capacità del datastore Servizio a 10 RPS, il che significa che ogni pod può ricevere un massimo di 10 RPS. È configurato HorizontalPodAutoscaler e averageUtilization è impostato su 70, il che significa che l'utilizzo target è il 70% di 10 RPS per pod.

Il gestore della scalabilità automatica tenta di scalare le repliche per raggiungere la seguente equazione:

replicas = ceiling[ current traffic / ( averageUtilization * max-rate-per-endpoint) ]

Nel diagramma, questa equazione calcola:

ceiling[ 10 rps / (0.7 * 10 rps) ] = ceiling[ 1.4 ] = 2 replicas

10 RPS di traffico generano 2 repliche. Ogni replica riceve 6 RPS, con un utilizzo target di 7 RPS.

Nota: le variazioni dei livelli di traffico o dei picchi di traffico possono indurre il gestore della scalabilità automatica a è simile all'equazione delle repliche target. In condizioni stazionarie, la quantità di repliche si avvicina al target, ma potrebbe non essere sempre esatto, con traffico fluttuante.

Suddivisione del traffico

La suddivisione del traffico utilizza un rapporto esplicito, chiamato ponderazione, che definisce proporzione di richieste HTTP inviate a un servizio. Le risorse HTTPRoute consentono devi configurare le ponderazioni in un elenco di servizi. Le ponderazioni relative tra I servizi definiscono la suddivisione del traffico tra di loro. È utile per suddividere il traffico durante le implementazioni, le modifiche canary o le emergenze.

Il seguente diagramma descrive un esempio di configurazione di suddivisione del traffico:

Nel diagramma:

• Il proprietario del servizio configura due servizi per una singola route, con una regola suddividendo il traffico per il 90% a store-v1 e per il 10% a store-v2.
• Il gateway riceve traffico dai client che vanno all'URL del negozio e il traffico viene suddiviso in base alla regola configurata. Il 90% delle route va verso store-v1 e il 10% verso store-v2.

La suddivisione del traffico è supportata tra i servizi nello stesso cluster e anche tra i servizi in diversi cluster:

• Suddivisione del traffico tra i servizi: utilizzata per suddividere il traffico per dell'applicazione. Utilizzare la suddivisione del traffico ad esempio, ci sono due deployment separati, store-v1 e store-v2, ognuno con il proprio servizio, store-v1 e store-v2. Le ponderazioni sono tra i due servizi per spostare gradualmente il traffico L'implementazione store-v2 è stata completata.

  Nota: il GatewayClass di gke-l7-gxlb non supporta la suddivisione del traffico.

• Suddivisione del traffico tra ServiceImports: utilizzata per spostare il traffico in o da cluster specifici per la manutenzione, la migrazione o le emergenze. ServiceImports rappresenta i servizi multi-cluster e abilita la suddivisione del traffico tra diversi servizi su cluster diversi. L'esercizio Routing blu/verde a più cluster con il gateway mostra la suddivisione del traffico tra i cluster.

  Nota: il GatewayClass di gke-l7-gxlb-mc non supporta la suddivisione del traffico.

Peso e capacità

Le ponderazioni e le capacità controllano la quantità di traffico inviata a diversi utenti Servizi. Pur avendo effetti simili, operano in modo diverso e hanno diversi casi d'uso. Possono e devono essere utilizzati insieme, però per diversi scopi.

Peso

La ponderazione è un controllo esplicita del traffico. Definisce le proporzioni esatte di traffico, indipendentemente dal traffico in entrata e dall'uso del backend. Nella esempio di suddivisione del traffico, se store-v2 era in eccesso o se tutte le repliche non sono riuscite, il 10% del traffico verrà comunque allocato store-v2, causando un potenziale calo del traffico. Questo perché il peso non cambia la proporzione di traffico in base all'utilizzo o all'integrità.

Il peso è più adatto per i seguenti casi d'uso:

• Spostamento del traffico tra le diverse versioni di un servizio per le implementazioni.
• Onboarding manuale dei servizi utilizzando suddivisioni esplicite del traffico.
• Spostare il traffico da un insieme di backend per un'emergenza o una manutenzione scopi.

Capacità

La capacità è un controllo implicito del traffico. Definisce le proporzioni indirettamente, poiché dipendono dalla quantità di traffico in entrata, e la località di origine del traffico. La capacità è intrinseca di un Servizio e in genere viene aggiornato con minore frequenza.

La capacità è più adatta per i seguenti casi d'uso:

• Prevenire l'utilizzo eccessivo del backend durante i picchi di traffico.
• Controllo della velocità di scalabilità automatica in relazione al traffico.

La configurazione della capacità del servizio per l'overflow del traffico potrebbe non essere sempre il comportamento desiderato. Considera l'esempio di bilanciamento del carico globale. La capacità del servizio protegge i backend dall'utilizzo eccessivo ma ciò potrebbe comportare una latenza aggiuntiva per le richieste che hanno ricevuto in overflow, poiché queste richieste sono in viaggio verso una regione più remota.

Se la tua applicazione non è molto sensibile al sovrautilizzo, potresti per configurare una capacità di servizio molto elevata in modo che sia improbabile che il traffico overflow in un'altra regione. Se la disponibilità o la latenza dell'applicazione sensibili al sovrautilizzo, provocando l'overflow del traffico verso altri cluster può essere meglio che assorbire il traffico in eccesso su backend sovrautilizzati. Per saperne di più su come configurare la capacità del servizio per la tua applicazione, consulta Determinare la capacità del servizio.

Passaggi successivi

• Informazioni su Deployment dei gateway.

• Informazioni su Deployment di gateway multi-cluster.