Gestione del traffico del gateway

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

Questa pagina è destinata a sviluppatori, operatori e specialisti di networking che vogliono eseguire il deployment e gestire il traffico utilizzando l'API Gateway.

Panoramica

Il networking di Google Kubernetes Engine (GKE) si basa su Cloud Load Balancing. Con Cloud Load Balancing, un singolo indirizzo IP anycast gestisce il traffico globale. La gestione del traffico di Google fornisce bilanciamento del carico globale e regionale, scalabilità automatica e gestione della capacità per fornire una distribuzione del traffico uniforme, 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 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. Funzionano 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, integrità e diversi algoritmi di bilanciamento del carico.
• La scalabilità automatica scala le repliche del carico di lavoro per creare più capacità per assorbire più traffico.
• La gestione della capacità monitora l'utilizzo dei servizi in modo che il traffico possa essere trasferito ai backend con capacità anziché influire sulla disponibilità o sulle prestazioni dell'applicazione.

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

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

• Se vuoi ottimizzare la latenza degli utenti a costo di un provisioning eccessivo, puoi eseguire il deployment dei cluster GKE in molte regioni e aumentare la capacità in modo dinamico ovunque aumenti il carico. Utilizzo del bilanciamento del carico e della scalabilità automatica GKE scala automaticamente il numero di pod quando il traffico aumenta in modo da non dover superare il limite di altre regioni. Le regioni aumenterebbero 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à che operano insieme:

Nel diagramma, il workload nel cluster gke-us non è riuscito. Il bilanciamento del carico e il controllo di integrità esauriscono le connessioni attive e reindirizzano il traffico al cluster più vicino successivo. Il workload in gke-asia riceve più traffico di quanto possa gestire, quindi scarica il carico su gke-eu. gke-eu riceve un carico maggiore del normale a causa degli eventi in gke-us e gke-asia, pertanto gke-eu esegue la scalabilità automatica per aumentare la capacità di traffico.

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

Funzionalità di gestione del traffico ed estensioni di servizio

Le risorse Gateway, HTTPRoute, Service e Policy forniscono i controlli per gestire il traffico in GKE. Il controller GKE Gateway è il control plane che monitora queste risorse.

Le estensioni del servizio GKE Gateway personalizzano ed estendono la gestione del traffico in GKE. Le estensioni inseriscono una logica personalizzata per il controllo avanzato del traffico.

Quando esegui il deployment dei 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 basata sul traffico: scalabilità automatica dei pod all'interno di un servizio in base alle richieste HTTP ricevute al secondo.
• Bilanciamento del carico multicluster: la possibilità di bilanciare il carico dei servizi ospitati in più cluster GKE o in più regioni.
• Suddivisione del traffico: distribuzione del traffico esplicita e basata sul peso tra i backend.

• Gestione personalizzata del traffico con Service Extensions:

  Le estensioni di servizio ti consentono di:

  • Modifica le intestazioni e i payload per le richieste e le risposte HTTP.
  • Implementa una logica di routing personalizzata per controllare il flusso di traffico.
  • Eseguire l'integrazione con servizi esterni per funzioni come l'autorizzazione.

Assistenza per la gestione del traffico

Le funzionalità di gestione del traffico disponibili dipendono da GatewayClass che implementi. Per un elenco completo delle funzionalità supportate, consulta Funzionalità di GatewayClass. La seguente tabella riassume il supporto di GatewayClass per la gestione del traffico:

Gestione del traffico con bilanciamento del carico basato su metriche personalizzate

Trusted Cloud by S3NS I bilanciatori del carico delle applicazioni distribuiscono il traffico in base a metriche personalizzate. Queste metriche possono includere il carico di utilizzo della GPU o altri indicatori di utilizzo specifici dell'applicazione. Le metriche personalizzate forniscono una visione più accurata del rendimento del carico di lavoro. La tua applicazione riporta queste metriche utilizzando lo standard Open Request Cost Aggregation (ORCA). Per ulteriori informazioni, consulta Metriche personalizzate per il bilanciatore del carico delle applicazioni.

In GKE, puoi integrare questa funzionalità avanzata di gestione del traffico tramite l'API GKE Gateway. L'API è utile per i workload con utilizzo variabile delle risorse, ad esempio l'inferenza dell'AI generativa. Puoi configurare un comportamento del traffico personalizzato configurando i seguenti criteri:

• GCPBackendPolicy per la selezione del backend: la risorsa GCPBackendPolicy consente di controllare con precisione il modo in cui i servizi di backend di un bilanciatore del carico distribuiscono il traffico ai relativi backend. Questa policy include campi specifici che consentono di configurare varie modalità di bilanciamento del carico, come l'utilizzo di metriche personalizzate. Per configurare la selezione del backend con GCPBackendPolicy, consulta Configurare la selezione del backend utilizzando GCPBackendPolicy.

• GCPTrafficDistributionPolicy per il routing a livello di endpoint: la GCPTrafficDistributionPolicy configura l'algoritmo di bilanciamento del carico per la selezione degli endpoint all'interno di un backend. Quando selezioni WEIGHTED_ROUND_ROBIN, il bilanciatore del carico utilizza pesi derivati dalle metriche riportate (incluse le metriche personalizzate) per distribuire il traffico alle singole istanze o endpoint. Per configurare le metriche a livello di endpoint, vedi Configurare il routing a livello di endpoint con GCPTrafficDistributionPolicy.

Norme basate sulla posizione

Puoi applicare queste norme basate sulla posizione a zone o regioni specifiche utilizzando uno specificatore di posizione. Trusted Cloud by S3NS Specifica della località utile per implementazioni canary, implementazioni in fasi o test delle modifiche ai criteri in regioni isolate. Per ulteriori informazioni, consulta Configurare le risorse del gateway utilizzando i criteri.

Monitorare le metriche personalizzate per i backend GKE

I bilanciatori del carico delle applicazioni esterni globali e i bilanciatori del carico delle applicazioni interni forniscono funzionalità di logging e monitoraggio che ti consentono di osservare le metriche personalizzate riportate dai backend GKE per informazioni dettagliate sul traffico. Per saperne di più, consulta Logging e monitoraggio del bilanciatore del carico delle applicazioni esterno globale.

Puoi utilizzare le etichette delle metriche GKE per eseguire query sulle metriche personalizzate per servizio, cluster e spazio dei nomi GKE.

Per visualizzare le metriche personalizzate segnalate dai backend GKE, vai a Cloud Monitoring e visualizza le metriche personalizzate nella risorsa monitorata network.googleapis.com/loadbalancer/backend/. Puoi utilizzare etichette specifiche di GKE per eseguire query e filtrare queste metriche.

Le metriche disponibili includono:

• /error_rate: errori restituiti da ogni gruppo di backend al secondo.
• /custom_metrics: l'utilizzo corrente di ciascun gruppo di backend, in base alle metriche personalizzate che hai definito.
• /fullness: pienezza (carico o capacità) attuale di ogni gruppo di backend, che i bilanciatori del carico utilizzano per le decisioni di routing.
• /rate: richieste ricevute da ogni gruppo di backend al secondo.

Le etichette specifiche di GKE che migliorano il monitoraggio di queste metriche includono gke_service_name, gke_namespace e gke_cluster. Puoi utilizzare queste etichette per esplorare i dati delle metriche per servizio, spazio dei nomi e cluster GKE. Tieni presente che queste etichette GKE vengono compilate solo se backend_type è ZONAL_NETWORK_ENDPOINT_GROUP.

La seguente tabella elenca le etichette specifiche di GKE:

Le voci di log dei bilanciatori del carico delle applicazioni esterni globali contengono informazioni utili per monitorare ed eseguire il debug del traffico HTTP(S).

Bilanciamento del carico globale, regionale e a livello di zona

La capacità, la posizione e l'integrità del servizio determinano 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 quello globale per i bilanciatori del carico globali e da quello regionale per i bilanciatori del carico regionali:

• Globale: il traffico viene inviato alla regione Trusted Cloud più vicina al client che dispone di backend integri con capacità. Finché la regione ha capacità, riceve tutto il traffico più vicino. Se una regione non ha capacità, il traffico in eccesso viene trasferito alla regione successiva più vicina con capacità. Per saperne di più, consulta Bilanciamento del carico globale.
• Regionale: il traffico viene inviato dal bilanciatore del carico a una regione specifica. Il traffico viene bilanciato tra le zone in proporzione alla capacità di servizio disponibile della zona. Per scoprire di più, consulta la sezione Bilanciamento del carico regionale.
• Zonale: 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 della sessione vengono conservate, in modo che le richieste future vengano inviate agli stessi backend, purché il pod di backend sia integro. Per scoprire 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 nel Point of Presence (PoP) di Google più vicino al client e poi attraversa la rete backbone di Google fino a raggiungere il backend più vicino, come determinato dalla latenza di rete. Quando i backend in una regione non hanno capacità residua, il traffico viene trasferito al cluster più vicino successivo con backend integri con capacità. Se più del 50% dei pod di backend all'interno di una zona non è integro, il failover del traffico viene eseguito gradualmente in altre zone o regioni, indipendentemente dalla capacità configurata.

Il superamento del traffico 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 multicluster.
• Hai configurato le capacità del servizio in modo che il traffico superi le capacità del 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 multicluster fornisce il bilanciamento del carico internet globale per il servizio store. Il servizio viene implementato in due cluster GKE, uno in us-west1 e l'altro in europe-west1. Ogni cluster esegue due 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 trasferiti a us-west1, in modo che riceva 16 RPS in totale e distribuisca 8 RPS a ogni pod.

Evitare l'overflow del traffico

Il superamento del traffico aiuta a evitare di superare la capacità dell'applicazione, il che può influire sulle prestazioni o sulla disponibilità.

Tuttavia, potresti non voler causare un overflow del traffico. Ad esempio, le applicazioni sensibili alla latenza potrebbero non trarre vantaggio dal trasferimento del traffico a 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 servizi in un solo cluster.

• Anche se utilizzi gateway multi-cluster, le repliche di un'applicazione di cui è stato eseguito il deployment in più cluster possono essere sottoposte a deployment 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à del servizio a un livello sufficientemente alto da non superare mai realisticamente la capacità di traffico, 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 si tratta di overflow, ma di bilanciamento del carico in proporzione diretta alle capacità del servizio in ogni zona. Qualsiasi 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 eseguito il deployment in un cluster GKE regionale. Il servizio ha 4 pod distribuiti 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 maxRatePerEndpoint=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 ciascuna zona.
• Il flusso di traffico da qualsiasi singola origine o client viene bilanciato in modo coerente su un singolo pod di backend in base alle impostazioni di persistenza della sessione. La distribuzione delle suddivisioni del traffico tra diversi flussi di traffico di origine in modo che i singoli flussi non vengano mai suddivisi. Di conseguenza, è necessario un importo minimo di diversità di origine o client 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 sono presenti altri cluster o regioni in cui questo traffico può essere trasferito. Il traffico continua a essere distribuito in base alle capacità zonali relative, anche se il traffico in entrata supera la capacità totale. 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ò overflow 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.

Bilanciamento del carico all'interno di una zona

Una volta inviato il traffico a una zona, viene distribuito uniformemente in tutti i backend all'interno di quella zona. Le sessioni HTTP sono persistenti a seconda dell'impostazione di affinità di sessione. A meno che il backend non diventi non disponibile, le connessioni TCP esistenti non vengono mai spostate su un altro backend. Ciò significa che le connessioni a lunga durata continuano a essere indirizzate allo stesso pod di backend anche se le nuove connessioni vanno in 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 l'RPS massimo per pod in media che un servizio può ricevere. Questo valore è configurabile sui 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:

• Supportato solo con le risorse GatewayClass e i tipi Ingress definiti in Supporto della gestione del traffico.
• Influisce sul bilanciamento del carico solo se utilizzi la scalabilità automatica basata sul traffico o i gateway multicluster. Se non utilizzi queste funzionalità, la capacità del servizio non influisce sul traffico di rete.

Configura la capacità del servizio

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

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

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 maxRatePerEndpoint crea una capacità dinamica per un servizio in base al numero di pod nel servizio. Il valore totale della capacità di servizio viene calcolato moltiplicando il valore maxRatePerEndpoint per il numero di repliche, come descritto nella seguente formula:

Total Service capacity = maxRatePerEndpoint * number of replicas

Se uno scalatore automatico aumenta il numero di pod all'interno di un servizio, la capacità totale del servizio viene calcolata di conseguenza. Se un servizio viene ridimensionato a zero pod, ha capacità zero e non riceve traffico dal bilanciatore del carico.

Capacità del servizio e NEG autonomi

La capacità del servizio può essere configurata anche quando si utilizzano NEG autonomi, ma non utilizza l'impostazione maxRatePerEndpoint. Quando utilizzi i NEG autonomi, il maxRatePerEndpoint viene configurato manualmente quando aggiungi il NEG a una risorsa Backend Service. Utilizzando il comando gcloud compute backend-services add-backend, il flag --max-rate-per-endpoint può configurare la capacità per ogni NEG singolarmente.

Questa opzione può essere utile per uno dei seguenti workflow:

• 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 i NEG autonomi

Non esiste alcuna differenza funzionale quando configuri la capacità del servizio con NEG standalone. Sono supportati sia lo scaling automatico del traffico sia il trasferimento del traffico.

Determinare la capacità del servizio

Per determinare il valore di maxRatePerEndpoint è necessario comprendere le caratteristiche prestazionali delle tue applicazioni e i tuoi obiettivi di bilanciamento del carico. Le seguenti strategie possono aiutarti a definire le caratteristiche prestazionali delle tue applicazioni:

• Osserva la tua applicazione negli ambienti di test e di produzione quando è 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) delle prestazioni.

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

• Definisci gli SLO di rendimento per la tua applicazione. Potrebbero essere uno o più dei seguenti, a seconda di ciò che consideri prestazioni "scarse" o "instabili". Tutti i seguenti dati possono essere raccolti dalle metriche del bilanciatore del carico di Cloud Monitoring:

  • Codici di errore di risposta
  • Latenza di risposta o totale
  • Stato non integro o tempi di inattività del backend

• Osserva la tua applicazione sotto carico di traffico negli ambienti di test e di produzione. Negli ambienti di test, metti sotto stress l'applicazione con un carico di richieste crescente in modo da poter vedere come vengono influenzate le diverse metriche di rendimento all'aumentare del traffico. Negli ambienti di produzione, osserva i livelli di pattern di traffico realistici.

Capacità del servizio predefinita

Tutti i servizi collegati alle risorse GKE hanno una capacità di servizio predefinita configurata anche se non è configurata in modo esplicito. Per saperne di più, consulta Capacità predefinita del servizio.

La tabella seguente descrive le capacità predefinite:

Scalabilità automatica basata sul traffico

La scalabilità automatica basata sul traffico è una funzionalità di GKE che integra in modo nativo gli indicatori di traffico dei bilanciatori del carico per scalare automaticamente i pod. 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 basata sul traffico del bilanciatore del carico.

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

• Le applicazioni che non sono strettamente vincolate alla CPU o alla memoria potrebbero avere limiti di capacità che non si riflettono nel loro 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 dell'app e con le metriche 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 ritardati.
• La combinazione di metriche di scalabilità automatica di CPU, memoria e traffico fornisce un modo olistico di scalare automaticamente le applicazioni che utilizzano più dimensioni per garantire che la capacità venga sottoposta a provisioning 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 la deploymente.
• Il gateway riceve il traffico dai client che accedono 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 di 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 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 è 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 / ( averageValue * maxRatePerEndpoint) ]

Nel diagramma, questa equazione si traduce in:

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

10 RPS di traffico generano 2 repliche. Ogni replica riceve 5 RPS, che è inferiore all'utilizzo target di 7 RPS.

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 consentono di configurare i pesi in un elenco di servizi. I pesi relativi tra i servizi definiscono la suddivisione del traffico tra loro. Questa opzione è utile per dividere il traffico durante le implementazioni, le modifiche canary o per le emergenze.

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

Nel diagramma:

• Il proprietario del servizio configura due servizi per un singolo percorso, con una regola che divide il traffico al 90% su store-v1 e al 10% su store-v2.
• Il gateway riceve il traffico dai client che accedono all'URL dell'applicazione store e il traffico viene suddiviso in base alla regola configurata. Il 90% dei percorsi di traffico 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 cluster diversi:

• Suddivisione del traffico tra i servizi: utilizzata per suddividere il traffico per i rollout delle versioni delle applicazioni. Utilizzando l'esempio di suddivisione del traffico, avresti due deployment separati, store-v1 e store-v2, ognuno con il proprio servizio, store-v1 e store-v2. I pesi vengono configurati tra i due servizi per spostare gradualmente il traffico fino a quando store-v2 non viene implementato completamente.

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

Peso e capacità

I pesi e le capacità controllano entrambi 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 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 superato la capacità o se tutte le sue repliche non fossero riuscite, il 10% del traffico verrebbe comunque allocato a store-v2, causando potenzialmente l'interruzione del traffico. Questo perché il peso non modifica la proporzione del traffico in base all'utilizzo o allo stato.

Il peso è più adatto ai 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 le proporzioni del traffico indirettamente, in quanto dipendono dalla quantità di traffico in entrata, dall'utilizzo del backend e dalla località di origine del traffico. La capacità è una proprietà intrinseca di un servizio e viene in genere aggiornata con una frequenza molto inferiore.

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

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

La configurazione della capacità del servizio per il traffico di overflow potrebbe non essere sempre un comportamento desiderato. Prendi in considerazione l'esempio di bilanciamento del carico globale. La capacità del servizio protegge i backend dall'utilizzo eccessivo dovuto al 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 all'utilizzo eccessivo, ti consigliamo di configurare una capacità del servizio molto elevata in modo che il traffico non superi mai la capacità di un'altra regione. Se la disponibilità o la latenza della tua applicazione è sensibile all'utilizzo eccessivo, il traffico di overflow ad altri cluster o regioni potrebbe essere meglio dell'assorbimento del traffico in eccesso 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.