Gestione del traffico del gateway

Autopilot Standard

---

Questa pagina spiega come funziona la gestione del traffico di Gateway.

Panoramica

Il networking di Google Kubernetes Engine (GKE) si basa su Cloud Load Balancing. Con Cloud Load Balancing, un singolo indirizzo IP anycast consente la gestione del traffico globale. 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. Utilizzando il controller GKE Gateway, gli utenti GKE possono utilizzare il controllo della gestione del traffico globale di Google in modo dichiarativo e nativo di Kubernetes.

Per provare il trasferimento del traffico tra i cluster, consulta Eseguire il deployment del bilanciamento del carico in base alla 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 un sistema di gestione del traffico. Lavorano insieme per equalizzare e stabilizzare il carico del sistema.

• Il bilanciamento del carico distribuisce il traffico tra i pod di backend in base a posizione, stato e diversi algoritmi di bilanciamento del carico.
• La scalabilità automatica esegue lo scaling delle repliche del carico di lavoro per creare una maggiore capacità di assorbire 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 a spot vengano utilizzate al massimo ovunque siano disponibili.

• Se vuoi ottimizzare la latenza utente a costo di un over-provisioning, puoi eseguire il deployment di cluster GKE in molte regioni e aumentare la capacità dinamicamente 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 essere trasferito ad altre regioni. Le regioni aumenteranno la capacità in modo da poter gestire completamente il carico il più vicino possibile agli utenti.

Il seguente diagramma mostra il bilanciamento del carico, la scalabilità automatica e la gestione della capacità in azione:

Nel diagramma, il workload nel cluster gke-us non è riuscito. Il bilanciamento del carico e i controlli di integrità interrompono le connessioni attive e reindirizzano il traffico al prossimo cluster più vicino. Il carico di lavoro in gke-asia riceve più traffico di quanto possa gestire, quindi riduce il carico su 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 scoprire di più su come Cloud Load Balancing gestisce la gestione del traffico, consulta la sezione sulla gestione della capacità globale.

Funzionalità di gestione del traffico

Le risorse Gateway, HTTPRoute, Service e Policy forniscono i controlli per gestire il traffico in GKE. Il controller GKE Gateway è 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 venga trasferito ad 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 del traffico esplicita in base al peso tra i 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 da GatewayClass che hai implementato. Per un elenco completo del supporto delle funzionalità, consulta Funzionalità di GatewayClass. La seguente tabella 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 al cliente che dispone di backend funzionanti con capacità. Finché la regione ha sufficiente capacità, riceve tutto il traffico più vicino. Se una regione non ha sufficiente capacità, il traffico in eccesso viene trasferito alla regione più vicina con capacità disponibile. Per saperne di più, consulta il bilanciamento del carico globale.
• Regionale: il traffico viene inviato dal bilanciatore del carico a una regione specifica. Il traffico viene bilanciato in base al carico tra le zone in proporzione alla capacità di servizio disponibile della zona. 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, a condizione che 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, consulta Bilanciamento del carico in base alla 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 la rete backbone di Google fino a raggiungere il backend più vicino, come stabilito dalla latenza della rete. Quando i backend di una regione non hanno capacità rimanente, il traffico viene trasferito al cluster più vicino con backend integri e con capacità disponibile. Se meno del 50% dei pod di backend all'interno di una zona non è integro, il traffico viene trasferito gradualmente ad altre zone o regioni, indipendentemente dalla capacità configurata.

Il traffico in eccesso si verifica solo alle seguenti condizioni:

• Stai utilizzando un gateway multi-cluster.
• Hai lo stesso servizio di cui è stato eseguito il deployment in più cluster, gestito dal 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 come funziona il bilanciamento del carico globale con il sovraccarico del traffico:

Nel diagramma:

• Un gateway multicluster fornisce il bilanciamento del carico di internet globale per il serviziostore. 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 in europe-west1, ma hanno una capacità di soli 20 RPS. Poiché i backend in us-west1 hanno una capacità in eccesso, 10 RPS vengono trasferiti a 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 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 hai requisiti di bilanciamento del carico globale.

Evitare il sovraccarico 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 cluster.

• 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. Ogni singolo flusso o sessione viene sempre inviato a un singolo pod di backend coerente e non viene 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 maxRatePerEndpoint="10". La zona A ha una capacità totale di 30 RPS, la zona B di 10 RPS e la zona C di 0 RPS, perché non ha pod.
• Il gateway riceve un totale di 16 RPS di traffico da diversi client. 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 viene suddivisa in diversi flussi di traffico di origine in modo che i singoli flussi non vengano mai suddivisi. Di conseguenza, è necessaria una quantità minima di origini o clienti diversi per distribuire in modo granulare 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 in base alle relative capacità zonali, anche se il traffico in entrata supera la capacità totale. Di conseguenza, la zona A riceve 45 RPS e la zona B 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: Cloud Load Balancing non riduce automaticamente il traffico quando i backend superano la capacità. Il traffico viene trasferito a tutti i backend disponibili con sufficiente capacità. Se tutti i backend hanno superato la capacità, il traffico in eccesso viene distribuito su 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 tutti i backend all'interno della 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 le connessioni di lunga durata continuano a essere indirizzate allo stesso pod di backend anche se le nuove connessioni superano la capacità limitata. Il bilanciatore del carico dà la priorità al mantenimento delle connessioni esistenti rispetto a quelle nuove.

Capacità del servizio

Con la capacità di 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:

• Supportato solo con le risorse GatewayClass e i tipi di ingressi definiti in Supporto per la gestione del traffico.

• Ha effetto sul bilanciamento del carico solo se utilizzi la scalabilità automatica in base al traffico o gateway multicluster. Se non utilizzi queste funzionalità, la capacità del servizio non influisce sul traffico di rete.

Configura la capacità del servizio

Gateway a cluster singolo

Assicurati che il cluster GKE esegui la versione 1.31.1-gke.2008000 o successive. Le versioni precedenti possono utilizzare l'annotazione networking.gke.io/max-rate-per-endpoint come descritto nella scheda Gateway multi-cluster.

Per utilizzare i gateway a cluster singolo per configurare la capacità del servizio, crea un servizio e un GCPBackendPolicy associato. Utilizza il seguente manifest per creare un servizio:

apiVersion: v1
kind: Service
metadata:
  name: store
spec:
  ports:
  - port: 8080
    targetPort: 8080
    name: http
  selector:
    app: store
  type: ClusterIP

Configura l'oggetto GCPBackendPolicy utilizzando il campo maxRatePerEndpoint con un valore RPS massimo. Utilizza il seguente manifest per configurare l'oggetto GCPBackendPolicy:

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: store
spec:
  default:
    maxRatePerEndpoint: "RATE_PER_SECOND"
  targetRef:
    group: ""
    kind: Service
    name: store

Gateway multi-cluster

Per utilizzare i gateway multi-cluster per configurare la capacità del servizio, crea un servizio utilizzando l'annotazione networking.gke.io/max-rate-per-endpoint. Utilizza il seguente manifest per creare 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 un singolo pod di questo servizio deve ricevere.

Il valore maxRatePerEndpoint crea una capacità dinamica per un servizio in base al numero di pod al suo interno. Il valore della capacità del servizio totale viene calcolato moltiplicando il valore maxRatePerEndpoint per il numero di repliche, come descritto nella seguente formula:

Total Service capacity = maxRatePerEndpoint * number of replicas

Se un ridimensionatore aumenta il numero di pod all'interno di un servizio, la capacità totale del servizio viene calcolata di conseguenza. Se un servizio viene ridotto a zero pod, ha una capacità pari a zero e non riceve traffico dal bilanciatore del carico.

Nota: la configurazione della capacità del servizio che utilizza il campo maxRatePerEndpoint in GCPBackendPolicy si applica solo al traffico in entrata tramite un gateway supportato. Non influisce sul bilanciamento del carico in base alla capacità per il tipo ClusterIP all'interno del cluster o per i servizi di tipo LoadBalancer.

Capacità del servizio e NEG autonomi

La capacità di servizio può essere configurata anche quando si utilizzano NEG autonomi, ma non viene utilizzata l'impostazione maxRatePerEndpoint. Quando utilizzi NEG autonomi, il valore maxRatePerEndpoint 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 il deployment manuale di bilanciatori del carico interni ed esterni utilizzando NEG autonomi
• Quando esegui il deployment di Cloud Service Mesh su GKE utilizzando NEG autonomi

Non esiste alcuna differenza funzionale nella configurazione della capacità di 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 maxRatePerEndpoint è 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 l'applicazione sia nell'ambiente di test sia in quello di produzione se configurata senza capacità di servizio.
• Utilizza Cloud Monitoring per creare una correlazione tra le richieste di traffico e gli obiettivi del livello di servizio (SLO) relativi alle 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. Potrebbero essere uno o più dei seguenti, a seconda di cosa consideri un rendimento "insufficiente" o "instabile". Tutte le seguenti informazioni possono essere raccolte dalle metriche del bilanciatore del carico di Cloud Monitoring:
  • Codici di errore di risposta
  • Risposta o latenza totale
  • Instabilità 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

Per tutti i servizi collegati alle risorse GKE è configurata una capacità predefinita anche se non è configurata esplicitamente. Per scoprire di più, consulta Capacità del servizio predefinita.

La seguente tabella descrive le capacità predefinite:

Tipo di risorsa di bilanciamento del carico	Predefinito maxRatePerEndpoint
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 in base al traffico è una funzionalità di GKE che integra in modo nativo gli indicatori di traffico dei bilanciatori del carico per eseguire il ridimensionamento automatico dei pod. La scalabilità automatica basata sul traffico è 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 il ridimensionamento automatico in base al traffico:

Nel diagramma:

• Il proprietario del servizio configura la capacità del servizio e un utilizzo target per il deployment.
• La porta di accesso riceve il traffico dai client diretti al servizio store. Il gateway invia la telemetria sull'utilizzo a GKE Pod Autoscaler. 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 della scalabilità automatica

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

Nel diagramma, il proprietario del servizio ha configurato la capacità del servizio di archiviazione su 10 RPS, il che significa che ogni pod può ricevere un massimo di 10 RPS. HorizontalPodAutoscaler è configurato con averageValue impostato su 70, il che significa che l'utilizzo target è del 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 / ( averageValue * maxRatePerEndpoint) ]

Nel diagramma, questa equazione corrisponde a:

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

10 RPS di traffico generano 2 repliche. Ogni replica riceve 5 RPS, ovvero meno dell'utilizzo target di 7 RPS.

Nota: le variazioni dei livelli di traffico o gli picchi di traffico possono causare l'approssimazione dell'equazione delle repliche target da parte del gestore della scalabilità automatica. In condizioni di regime stazionario, il numero di repliche si avvicina al target, ma potrebbe non essere sempre esatto, soprattutto con il 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. Questa operazione è utile per suddividere il traffico durante le implementazioni, le modifiche con 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 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 il traffico dai client che accedono all'URL dell'applicazione del negozio e il traffico viene suddiviso in base alla regola configurata. Il 90% del traffico è diretto a store-v1 e il 10% a store-v2.

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

• Suddivisione del traffico tra i servizi: utilizzata per suddividere il traffico per le implementazioni delle versioni dell'applicazione. Utilizzando l'esempio di suddivisione del traffico, avresti due deployment distinti, store-v1 e store-v2, ciascuno con il proprio servizio, store-v1 e store-v2. I pesi vengono configurati tra i due servizi per spostare gradualmente il traffico fino al completamento dell'implementazione di store-v2.

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

• Suddivisione del traffico tra ServiceImports: utilizzata per spostare il traffico verso o da cluster specifici per manutenzione, migrazione o 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. Sebbene abbiano effetti simili, funzionano in modo diverso e hanno diversi casi d'uso. Possono e devono essere utilizzati insieme, anche se per scopi diversi.

Peso

Il peso è un controllo esplicito del traffico. Definisce le proporzioni esatte del traffico, indipendentemente dal traffico in entrata e dall'utilizzo 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 diverse versioni di un servizio per i rollout.
• Eseguire l'onboarding manuale dei servizi utilizzando suddivisioni del traffico esplicite.
• Spostare il traffico da un insieme di backend per scopi di emergenza o manutenzione.

Capacità

La capacità è un controllo implicito del traffico. Definisce indirettamente le proporzioni del traffico 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 con molta meno 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. Prendi in considerazione l'esempio di bilanciamento del carico globale. La capacità del servizio protegge i backend dall'utilizzo eccessivo tramite il traffico in eccesso, ma ciò potrebbe comportare una latenza aggiuntiva per le richieste che hanno superato il limite, poiché queste richieste vengono inviate a una regione più remota.

Se la tua applicazione non è molto sensibile al sovrautilizzo, ti consigliamo di configurare una capacità del servizio molto elevata in modo che il traffico non debordi in un'altra regione. Se la disponibilità o la latenza della tua applicazione è sensibile al sovrautilizzo, potrebbe essere preferibile indirizzare il traffico in eccesso ad altri cluster o regioni anziché assorbirlo sui backend sovrautilizzati. Per scoprire 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.