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. La gestione del traffico di Google offre bilanciamento del carico, scalabilità automatica e gestione della capacità a livello globale e regionale per garantire una distribuzione del traffico equa, 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 in base al 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 che il traffico possa essere indirizzato ai backend con capacità anziché influire sulla disponibilità o sulle prestazioni dell'applicazione.

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

• Se vuoi sfruttare le VM spot a basso costo, ti consigliamo di ottimizzare la distribuzione uniforme del traffico tra le VM spot, a costo della latenza. Utilizzando il bilanciamento del carico e la gestione della capacità, GKE sposterebbe il traffico tra le regioni in base alla capacità in modo che le VM Spot vengano utilizzate al massimo 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, per evitare che il traffico venga trasferito ad altre regioni. Le regioni aumenteranno la capacità in modo da essere in grado di gestire completamente il carico il più vicino possibile 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 un carico superiore alla media a causa di eventi in gke-us e gke-asia, pertanto gke-eu si ridimensiona automaticamente per aumentare 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.

Quando esegui il deployment di servizi in GKE, sono disponibili le seguenti funzionalità di gestione del traffico:

• 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 che il traffico si riversi su altri cluster disponibili.
• Scalabilità automatica in base al traffico: scalabilità automatica dei pod all'interno di un servizio in base alle richieste HTTP ricevute al secondo.

• Bilanciamento del carico multi-cluster: la possibilità di bilanciare il carico per i servizi ospitati su più cluster GKE o 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 versione GA.

Bilanciamento del carico globale, regionale e a livello di zona

La capacità, la posizione e l'integrità del servizio determinano la quantità di traffico inviata dal bilanciatore del carico a un determinato backend. Le decisioni di bilanciamento del carico vengono prese ai seguenti livelli, a partire da globale per i bilanciatori del carico globali e regionale per i bilanciatori del carico regionali:

• Globale: il traffico viene inviato alla regione Google Cloud più vicina a il client che ha backend integri con capacità. Finché la regione ha sufficiente capacità, 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 alle disponibilità e capacità di distribuzione. Per saperne di più, consulta la sezione sul bilanciamento del carico a livello di regione.
• Zonal: dopo aver determinato il traffico per una zona specifica, il bilanciatore del carico lo distribuisce in modo uniforme tra i backend all'interno di quella zona. Le impostazioni di persistenza della sessione e le connessioni TCP esistenti vengono conservate, in modo che le richieste future vengano inviate agli stessi backend, purché il pod di backend sia integro. Per approfondire, consulta la sezione sul 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 cliente e poi attraversa la rete backbone di Google fino a raggiungere lo stato 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.
• Le capacità di servizio sono configurate in modo che il traffico superi le capacità di servizio 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 servizio viene disegnato su due cluster GKE, uno in us-west1 e un altro in europe-west1. In ogni cluster vengono eseguite 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 al backend integro più vicino con capacità, il cluster GKE in 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 su un singolo cluster all'interno di un'unica regione. I gateway multi-cluster sono consigliati se disponi di di bilanciamento del carico a livello globale.

Prevenzione dell'overflow del traffico

Il traffico in eccesso aiuta a evitare il superamento della capacità dell'applicazione, che può influire sulle prestazioni o sulla disponibilità.

Tuttavia, è consigliabile evitare di sovraccaricare il traffico. Ad esempio, le applicazioni sensibili alla latenza potrebbero non trarre vantaggio dall'overflow del traffico verso un backend molto più distante.

Per evitare il sovraccarico del traffico, puoi utilizzare uno 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 su più cluster possono essere implementate come servizi distinti. Dal punto di vista del gateway, questo consente il bilanciamento del carico multi-cluster, ma non aggrega tutti gli endpoint di un servizio tra i cluster.

• Imposta le capacità di servizio a un livello sufficientemente elevato in modo che la capacità di traffico non venga mai superata in modo realistico, a meno che non sia assolutamente necessario.

Bilanciamento del carico all'interno di una regione

All'interno di una regione, il traffico viene distribuito tra le zone in base alle capacità disponibili dei backend. Non viene utilizzato il sovraccarico, ma il bilanciamento del carico in proporzione diretta alle capacità del servizio in ogni 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 viene distribuito il traffico all'interno di una regione:

Nel diagramma:

• Un servizio viene disegnato in un cluster GKE a livello di regione. Il servizio ha 4 pod di cui è stato eseguito il deployment in modo non uniforme nelle zone. 3 pod si trovano nella zona A, 1 pod si trova nella zona B e nessun pod si trova 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 tra le zone in proporzione alla capacità rimanente in ciascuna zona.
• Il flusso di traffico da qualsiasi singola sorgente o client viene bilanciato in modo coerente su un singolo pod di backend in base alle impostazioni di persistenza della sessione. 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 verifica uno dei seguenti scenari:

• Se utilizzi gateway a cluster singolo, non ci sono altri cluster o regioni in cui questo traffico può essere trasferito. 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 servizi distribuiti su più cluster, il traffico può essere trasferito ad altri cluster e altre regioni come 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 vengono trasferiti a un altro cluster.

Nota: il bilanciamento del carico su cloud non riduce automaticamente il traffico quando i backend superano la 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 dell'impostazione di affinità della sessione. A meno che il backend non diventi non disponibile, le connessioni TCP esistenti non vengono mai spostate in un altro backend. 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à la priorità al mantenimento delle connessioni 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 richieste al secondo per pod in media che un servizio può ricevere. Questo valore è configurabile in Servizi e viene utilizzato per determinare la scalabilità automatica in base al traffico e il bilanciamento del carico in base alla 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à, la capacità del servizio non influisce sul traffico di rete.

Configura la 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 numero massimo di richieste HTTP/HTTPS al secondo che un singolo pod in questo servizio deve ricevere.

Il valore max-rate-per-endpoint crea una capacità dinamica per un servizio in base al numero di pod al suo interno. 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 che utilizza l'annotazione max-rate-per-endpoint si applica solo al traffico in entrata tramite un 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 aggiungi il NEG a una risorsa di servizio di backend. Utilizzando il comando gcloud compute backend-services add- backend , il flag --max-rate-per-endpoint può configurare la capacità per ogni NEG individualmente.

Questa opzione può essere utile per uno 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 di prestazioni delle applicazioni e gli obiettivi di bilanciamento del carico. Le seguenti strategie possono aiutarti a definire le caratteristiche di prestazioni delle applicazioni:

• 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 metriche del bilanciatore del carico, come https o request_count per mappare i livelli di RPS.

• Definisci gli SLO relativi alle prestazioni per la tua applicazione. Potrebbe trattarsi di uno di questi o più dei seguenti, a seconda di ciò che consideri "scarso" o "instabile" le prestazioni dei dispositivi. Tutte le seguenti informazioni possono essere raccolte dalle metriche del bilanciatore del carico di Cloud Monitoring:
  • Codici di errore di risposta
  • Latenza totale o risposta
  • Stato non integro o tempi di inattività del backend
• Osserva l'applicazione sotto il carico del traffico sia negli ambienti di test sia in quelli di produzione. Negli ambienti di test, sottoponi la tua applicazione a un carico crescente di richieste per vedere in che modo le diverse metriche sul rendimento vengono influenzate dall'aumento del traffico. Negli ambienti di produzione, osserva livelli di modelli di traffico realistici.

Capacità del 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 Capacità del servizio predefinita.

La seguente tabella descrive le capacità predefinite:

Tipo di risorsa di bilanciamento del carico	Valore predefinito: max-rate-per-endpoint
Ingresso (interno ed esterno)	1 RPS
Gateway (tutte le classi 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 in base al 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 limiti di capacità che non si riflettono nel loro utilizzo della CPU o della memoria.
• Il traffico o le richieste al secondo (RPS) è una metrica più facile da comprendere in alcuni casi perché è più in linea con le metriche di utilizzo dell'app e aziendali, come le visualizzazioni di pagina o gli utenti attivi giornalieri (DAU).
• Il traffico è un indicatore principale che rappresenta la domanda istantanea rispetto alla CPU o alla memoria, che sono indicatori in ritardo.
• La combinazione di metriche di scalabilità automatica di CPU, memoria e traffico offre un modo olistico per eseguire la scalabilità automatica delle applicazioni che utilizza più dimensioni per garantire il provisioning appropriato della capacità.

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 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 è uguale al traffico effettivo ricevuto da un singolo pod diviso per la capacità configurata del pod.
• Il gestore della scalabilità automatica dei pod GKE esegue lo scale up o lo scale down dei pod in base all'utilizzo target configurato.

Comportamento di scalabilità automatica

Il seguente diagramma mostra come funziona la scalabilità automatica basata sul traffico in 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 in modo da ottenere 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 peso, che definisce la proporzione di richieste HTTP inviate a un servizio. Le risorse HTTPRoute ti consentono di configurare i pesi in un elenco di servizi. I pesi relativi tra i servizi definiscono la suddivisione del traffico tra di loro. Questo è utile per suddividere il traffico durante i rollout, le modifiche con canary o per le emergenze.

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

Nel diagramma:

• Il proprietario del servizio configura due servizi per un singolo percorso, con una regola che suddivide il traffico per il 90% in store-v1 e per il 10% in 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 le implementazioni delle versioni 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. Le importazioni di servizi rappresentano servizi multi-cluster e consentono la suddivisione del traffico tra diversi servizi su cluster diversi. L'esercizio Routing blu/verde multi-cluster con Gateway dimostra la suddivisione del traffico tra i cluster.

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

Peso e capacità

Sia i pesi che le capacità controllano la quantità di traffico inviata ai diversi 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. Nell'esempio di suddivisione del traffico, se store-v2 avesse una capacità eccessiva o se tutte le sue repliche non fossero riuscite, il 10% del traffico verrebbe comunque allocato a store-v2, con un potenziale calo del traffico. Questo perché il peso non modifica la proporzione del traffico in base all'utilizzo o allo stato.

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

• Spostamento del traffico tra le diverse versioni di un servizio per le implementazioni.
• Operazioni preliminari per i 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:

• Impedire l'utilizzo eccessivo del backend durante i picchi di traffico.
• Controllo della frequenza della scalabilità automatica rispetto al traffico.

La configurazione della capacità del servizio per il traffico in eccesso potrebbe non essere sempre un comportamento voluto. 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 migliore rispetto all'assorbimento del 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

• Scopri di più sul deployment dei gateway.

• Scopri di più sul deployment di gateway multi-cluster.