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) è basato su Cloud Load Balancing. Con Cloud Load Balancing, un singolo indirizzo IP anycast offre la gestione del traffico globale. La gestione del traffico di Google fornisce bilanciamento del carico, scalabilità automatica e gestione della capacità a livello globale e a livello di regione per fornire una distribuzione del traffico uniforme, stabile e a bassa latenza. Utilizzando il 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, consulta 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 un sistema di gestione del traffico. Questi interagiscono tra loro per equalizzare e stabilizzare il carico del 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 più capacità e assorbire più traffico.
• La gestione della capacità monitora l'utilizzo dei servizi in modo che il traffico possa essere overflow nei backend con capacità, invece di influire sulla disponibilità o sulle prestazioni delle applicazioni.

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

• Se vuoi sfruttare VM spot a basso costo, ti consigliamo di ottimizzare la distribuzione uniforme del traffico tra le VM spot ai costi della latenza. Utilizzando il bilanciamento del carico e la gestione della capacità, GKE eseguiva l'overflow del traffico tra le regioni in base alla capacità, in modo che le VM spot vengano utilizzate appieno ovunque siano disponibili.

• Se vuoi ottimizzare la latenza degli utenti a scapito del provisioning eccessivo, potresti eseguire il deployment dei cluster GKE in molte regioni e aumentare la capacità in modo dinamico ogni volta che il carico aumenta. Utilizzando il bilanciamento del carico e la scalabilità automatica, GKE scala automaticamente il numero di pod in caso di picchi di traffico, in modo che il traffico non debba passare in altre regioni. La capacità delle regioni aumenta, in modo da poter gestire completamente il carico il più vicino possibile agli utenti.

Il seguente diagramma mostra il funzionamento congiunto di bilanciamento del carico, scalabilità automatica e gestione della capacità:

Nel diagramma, si è verificato un errore del carico di lavoro nel cluster gke-us. Il bilanciamento del carico e il controllo di integrità svuota le connessioni attive e reindirizza il traffico al cluster successivo più vicino. Il carico di lavoro in gke-asia riceve più traffico di quante ne abbia la capacità, quindi trasferisce il carico a gke-eu. gke-eu riceve più carico del solito a causa degli eventi in gke-us e gke-asia, perciò gke-eu scala automaticamente per aumentare la capacità di traffico.

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

Funzionalità di gestione del traffico

Le risorse gateway, HTTPRoute, di servizio e dei criteri forniscono i controlli per gestire il traffico in GKE. Il controller gateway GKE è il piano di controllo che monitora queste risorse.

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

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

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

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

Supporto per la gestione del traffico

Le funzionalità disponibili di gestione del traffico dipendono dal GatewayClass di cui esegui il deployment. Per un elenco completo del supporto delle funzionalità, consulta Funzionalità di 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, a livello di regione e di zona

Capacità, località e integrità del servizio determinano tutti la quantità di traffico che il bilanciatore del carico invia a un determinato backend. Le decisioni di bilanciamento del carico vengono prese ai seguenti livelli, a partire da quelli globali per i bilanciatori del carico globali e a livello di regione per i bilanciatori del carico a livello di regione:

• Globale: il traffico viene inviato alla regione Google Cloud più vicina al client con backend integri con capacità. È sufficiente che la regione abbia capacità a disposizione, riceve tutto il traffico più vicino. Se una regione non ha capacità, il traffico in eccesso viene superato alla regione con capacità più vicina più vicina. Per scoprire di più, consulta la pagina relativa al bilanciamento del carico globale.
• A livello di regione: il traffico viene inviato dal bilanciatore del carico a una regione specifica. Il carico del traffico viene bilanciato tra le zone in proporzione alla capacità di gestione disponibile della zona. Per scoprire di più, consulta la pagina relativa al bilanciamento del carico a livello di regione.
• A livello di zona: dopo aver determinato il traffico per una zona specifica, il bilanciatore del carico distribuisce il traffico in modo uniforme tra i backend all'interno di quella zona. Le connessioni TCP esistenti e le impostazioni di persistenza delle sessioni vengono conservate, in modo che le richieste future vengano indirizzate agli stessi backend, a condizione che il pod di backend sia integro. Per scoprire di più, consulta il bilanciamento del carico a livello di zona.

Bilanciamento del carico globale e overflow del traffico

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

In condizioni normali, il traffico viene inviato al backend più vicino al client. Il traffico termina nel punto di presenza (PoP) di Google più vicino al client e poi attraversa il backbone di Google fino a raggiungere il backend più vicino, come determinato dalla latenza di rete. Quando i backend in un'area geografica non hanno capacità rimanente, il traffico esce dal cluster più vicino al successivo cluster più vicino con backend integri con capacità disponibile. Se meno del 50% dei pod di backend all'interno di una zona è in stato non integro, il traffico viene eseguito gradualmente in altre zone o regioni, indipendentemente dalla capacità configurata.

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

• Stai utilizzando un gateway multi-cluster.
• Hai lo stesso servizio di cui hai eseguito il deployment in più cluster, gestito dal gateway multi-cluster.
• Le capacità di servizio sono configurate in modo tale che il traffico superi quella di servizio in un cluster, ma non in altri.

Il seguente diagramma mostra come funziona il bilanciamento del carico globale con l'overflow del traffico:

Nel diagramma:

• Un gateway multi-cluster fornisce il bilanciamento del carico internet globale per il servizio store. Il deployment del servizio viene eseguito in due cluster GKE, uno in us-west1 e un altro in europe-west1. Ogni cluster 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 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 in europe-west1, ma hanno solo 20 RPS di capacità. Poiché i backend in us-west1 hanno capacità in eccesso, 10 RPS vengono sottoposti a overflow in us-west1, in modo che riceva 16 RPS in totale e distribuisca 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 è applicabile, poiché queste risorse eseguono il bilanciamento del carico solo in un singolo cluster all'interno di una singola regione. I gateway multi-cluster sono consigliati se hai requisiti di bilanciamento del carico globali.

Prevenzione dell'overflow del traffico

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

Tuttavia, potresti non volere un overflow del traffico. Le applicazioni sensibili alla latenza, ad esempio, potrebbero non trarre vantaggio dall'overflow del traffico verso un backend molto più distante.

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

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

• Anche se utilizzi gateway multi-cluster, il deployment delle repliche di un'applicazione su più cluster può essere eseguito come servizi separati. 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 alto da non superare mai realisticamente la capacità di traffico, se non è 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. Questa operazione non utilizza l'overflow, ma il bilanciamento del carico in modo direttamente proporzionale alle capacità del servizio in ogni zona. Ogni singolo flusso o sessione viene sempre inviata a un singolo pod di backend coerente e non viene suddiviso.

Il seguente diagramma mostra la distribuzione del traffico 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 4 pod, il cui deployment viene eseguito in modo non uniforme nelle varie 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 di capacità totale, la zona B ha 10 RPS di capacità totale e la zona C ha 0 RPS di 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 ogni zona.
• Il flusso di traffico da qualsiasi origine o client viene bilanciato in modo coerente in un unico pod di backend in base alle impostazioni di persistenza della sessione. La distribuzione del traffico viene suddivisa su diversi flussi di traffico di origine in modo che i singoli flussi non vengano mai suddivisi. Di conseguenza, è necessaria una quantità minima di diversità di origini o client per distribuire in modo granulare il traffico tra i backend.

Ad esempio, se i picchi di traffico in entrata da 16 RPS a 60 RPS, si verificherebbero uno dei seguenti scenari:

• Se utilizzi gateway a cluster singolo, non ci sono altri cluster o regioni a cui eseguire l'overflow del traffico. Il traffico continua a essere distribuito in base alle relative capacità di zona, anche se il traffico in entrata supera la capacità totale. Come risultato, la zona A riceve 45 RPS e la zona B ne riceve 15.
• Se utilizzi gateway multi-cluster con servizi distribuiti in più cluster, il traffico può passare in overflow ad altri cluster e ad altre regioni, come descritto in Bilanciamento del carico globale e overflow del traffico. La zona A riceve 30 RPS, la zona B ne riceve 10 e 20 overflow di RPS in un altro cluster.

Nota: Cloud Load Balancing non elimina automaticamente il traffico quando i backend presentano una capacità eccessiva. Il traffico viene eccessivo in qualsiasi backend disponibile con capacità. Se tutti i backend hanno una capacità in eccesso, il traffico in eccesso viene distribuito tra tutti i backend in proporzione alle loro capacità totali. Viene superata 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 tutti i backend all'interno della zona. Le sessioni HTTP sono permanenti a seconda dell'impostazione di affinità sessione. A meno che il backend non sia più disponibile, le connessioni TCP esistenti non vengono mai spostate in un backend diverso. Ciò significa che le connessioni di lunga durata continuano a essere indirizzate allo stesso pod di backend anche in caso di overflow di nuove connessioni 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 RPS per pod in media che un servizio può ricevere. Questo valore è configurabile nei 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 Supporto per la gestione del traffico.

• Ha impatto sul bilanciamento del carico solo se utilizzi la scalabilità automatica basata sul traffico o gateway multi-cluster. Se non usi queste funzionalità, la capacità del servizio non ha alcun effetto 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 un 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 dovrebbe ricevere un singolo pod in questo servizio.

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 viene calcolato moltiplicando il valore max-rate-per-endpoint per il numero 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 zero pod, ha una capacità pari a zero e non riceve traffico dal bilanciatore del carico.

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

Capacità del servizio e NEG autonomi

La capacità del servizio può essere configurata anche quando si utilizzano NEG autonomi, ma non utilizza l'annotazione max-rate-per-endpoint. Quando si utilizzano NEG autonomi, il max-rate-per-endpoint viene configurato manualmente quando si aggiunge il NEG a una risorsa del 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 singolarmente.

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

• Quando esegui il deployment manuale di bilanciatori del carico interni ed esterni utilizzando NEG autonomi
• Quando esegui il deployment di Traffic Director su GKE con NEG autonomi

Non esiste alcuna differenza funzionale quando si configura la capacità del servizio con NEG autonomi. Sono supportate sia la scalabilità automatica del traffico sia la spillover del traffico.

Determina la capacità del servizio

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

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

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

• Definisci gli SLO delle prestazioni per la tua applicazione. Potrebbero essere uno o più degli elementi riportati di seguito, a seconda di ciò che consideri "scarso" o "instabile". Tutti i seguenti dati possono essere raccolti dalle metriche del bilanciatore del carico di Cloud Monitoring:
  • Codici di errore di risposta
  • Latenza totale o di risposta
  • Integrità o inattività del backend
• Osserva l'applicazione sotto carico di traffico sia in ambienti di test che di produzione. Negli ambienti di test, sottoponi l'applicazione a un carico di richieste crescente, in modo da poter vedere l'impatto sulle diverse metriche delle prestazioni con l'aumento del traffico. In ambienti di produzione, osserva livelli di modelli di traffico realistici.

Capacità predefinita del servizio

Tutti i servizi collegati alle risorse GKE hanno una capacità predefinita di servizio configurata, anche se non è configurata esplicitamente tramite l'annotazione. Per scoprire di più, consulta Capacità di servizio predefinita.

La tabella seguente descrive le capacità predefinite:

Tipo di risorsa di bilanciamento del carico	Valore predefinito: max-rate-per-endpoint
In entrata (interno ed esterno)	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 in modo nativo gli indicatori di traffico dai bilanciatori del carico ai pod con scalabilità automatica. La scalabilità automatica basata sul traffico è 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 limiti di capacità che non si riflettono sull'utilizzo di CPU o memoria.
• Il traffico, o richieste al secondo (RPS), è una metrica più facile da comprendere in alcuni casi perché è più in linea con l'utilizzo delle app e le metriche aziendali, come le visualizzazioni di pagina o gli utenti attivi giornalieri (DAU).
• Il traffico è un indicatore iniziale 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 fornisce un modo olistico di scalabilità automatica delle applicazioni che utilizza più dimensioni per garantire che il provisioning della capacità venga 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 il deployment.
• Il gateway riceve traffico dai client che passano al servizio store. 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 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 della scalabilità automatica

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

Nel diagramma, il proprietario del servizio ha configurato la capacità del servizio del negozio su 10 RPS, il che significa che ogni pod può ricevere un massimo di 10 RPS. HorizontalPodAutoscaler è configurato con 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 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, che rientrano nell'utilizzo target di 7 RPS.

Nota: le variazioni dei livelli di traffico o i picchi di traffico possono causare l'approssimazione dell'equazione delle repliche target da parte del gestore della scalabilità automatica. In condizioni di stato stazionario, la quantità di repliche si avvicina al target, ma potrebbe non essere sempre esatta, soprattutto con le fluttuazioni del traffico.

Suddivisione del traffico

La suddivisione del traffico utilizza un rapporto esplicito, chiamato peso, che definisce la percentuale di richieste HTTP inviate a un servizio. Le risorse HTTPRoute consentono di configurare le ponderazioni in un elenco di servizi. Le ponderazioni relative tra i servizi definiscono la suddivisione del traffico tra i servizi. Questo è utile per suddividere il traffico durante le implementazioni, le modifiche canary o per 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 che suddivide il traffico al 90% in store-v1 e al 10% in store-v2.
• Il gateway riceve il traffico dai client che rimandano all'URL dell'applicazione del negozio e il traffico viene suddiviso in base alla regola configurata. Il 90% delle rotte del traffico per store-v1 e il 10% delle route per store-v2.

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

• Suddivisione del traffico tra servizi: utilizzata per la suddivisione del traffico per le implementazioni delle versioni dell'applicazione. Utilizzando l'esempio di suddivisione del traffico, avresti due deployment separati, store-v1 e store-v2, ciascuno con il proprio servizio store-v1 e store-v2. Le ponderazioni vengono configurate tra i due servizi in modo da spostare gradualmente il traffico fino all'implementazione completa di store-v2.

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

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

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

Peso e capacità

Sia le ponderazioni che le capacità controllano la quantità di traffico inviata a servizi diversi. Sebbene abbiano effetti simili, funzionano in modo diverso e hanno casi d'uso diversi. Possono e devono essere usati insieme, ma per scopi diversi.

Ponderazione

La ponderazione è un controllo esplicito del traffico. Definisce le proporzioni esatte di traffico, indipendentemente dal traffico in entrata e dall'utilizzo del backend. Nell'esempio di suddivisione del traffico, se store-v2 presentava una capacità eccessiva o se tutte le sue repliche non funzionavano, il 10% del traffico verrebbe comunque allocato a store-v2, causando una potenziale perdita di traffico. Questo perché la ponderazione non cambia la proporzione di traffico in base all'utilizzo o all'integrità.

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

• Spostare il traffico tra le diverse versioni di un servizio per le implementazioni.
• Onboarding manuale dei servizi con suddivisione del traffico esplicita.
• Spostare il traffico da un insieme di backend per scopi di emergenza o manutenzione.

Capacità

La capacità è un controllo implicito del traffico. Definisce le proporzioni di traffico indirettamente in quanto dipendono dalla quantità di traffico in entrata, dall'utilizzo del backend e dalla posizione di origine del traffico. La capacità è una proprietà intrinseca di un servizio e in genere viene aggiornata molto meno di frequente.

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

• Impedisce l'utilizzo eccessivo del backend durante i picchi di traffico.
• Controllare la frequenza di scalabilità automatica in relazione al traffico.

La configurazione della capacità del servizio per l'overflow del traffico potrebbe non essere sempre un comportamento desiderato. Considera l'esempio di bilanciamento del carico globale. La capacità del servizio protegge i backend da un uso eccessivo grazie all'overflow del traffico, ma ciò potrebbe causare una latenza aggiuntiva per le richieste in overflow, poiché queste richieste si spostano in una regione più remota.

Se la tua applicazione non è molto sensibile alla sovrautilizzo, potrebbe essere opportuno configurare una capacità di servizio molto elevata in modo che il traffico non superi mai il traffico in un'altra regione. Se la disponibilità o la latenza dell'applicazione sono sensibili alla sovrautilizzo, l'overflow del traffico verso altri cluster o aree geografiche potrebbe essere migliore che assorbire il traffico in eccesso nei backend sovrautilizzati. Per saperne di più su come configurare la capacità del servizio per la tua applicazione, vedi Determinare la capacità del servizio.

Passaggi successivi

• Scopri di più sul deployment dei gateway.

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