Best practice per la scalabilità di Cloud Service Mesh su GKE

Questa guida descrive le best practice per risolvere i problemi di scalabilità delle architetture Cloud Service Mesh gestite su Google Kubernetes Engine. L'obiettivo principale di questi consigli è garantire prestazioni, affidabilità e utilizzo delle risorse ottimali per le applicazioni di microservizi man mano che crescono.

Per comprendere i limiti di scalabilità, consulta Limiti di scalabilità di Cloud Service Mesh.

La scalabilità di Cloud Service Mesh su GKE dipende dal funzionamento efficiente dei suoi due componenti principali: il piano dati e il control plane. Questo documento si concentra principalmente sulla scalabilità del piano dati.

Identificare i problemi di scalabilità del control plane e del piano dati

In Cloud Service Mesh, i problemi di scalabilità possono verificarsi nel control plane o nel piano dati. Ecco come puoi identificare il tipo di problema di scalabilità che stai riscontrando:

Sintomi di problemi di scalabilità del control plane

Service Discovery lento: i nuovi servizi o endpoint impiegano molto tempo per essere rilevati e diventare disponibili.

Ritardi nella configurazione: le modifiche alle regole di gestione del traffico o alle policy di sicurezza impiegano molto tempo per propagarsi.

Aumento della latenza nelle operazioni del control plane: le operazioni come la creazione, l'aggiornamento o l'eliminazione delle risorse Cloud Service Mesh diventano lente o non rispondono.

Errori relativi a Traffic Director: potresti osservare errori nei log di Cloud Service Mesh o nelle metriche del control plane che indicano problemi di connettività, esaurimento delle risorse o limitazione dell'API.

Ambito dell'impatto: i problemi del control plane in genere interessano l'intero mesh, causando un degrado delle prestazioni diffuso.

Sintomi di problemi di scalabilità del piano dati

Aumento della latenza nella comunicazione tra servizi: le richieste a un servizio in-mesh riscontrano una latenza o timeout più elevati, ma non si verifica un utilizzo elevato di CPU/memoria utilizzata nei container del servizio.

Utilizzo elevato di CPU o memoria utilizzata nei proxy Envoy: un utilizzo elevato di CPU o memoria utilizzata può indicare che i proxy hanno difficoltà a gestire il carico di traffico.

Impatto localizzato: i problemi del piano dati in genere interessano servizi o carichi di lavoro specifici, a seconda dei pattern di traffico e dell'utilizzo delle risorse dei proxy Envoy.

Scalare il piano dati

Per scalare il piano dati, prova le seguenti tecniche:

Configurare la scalabilità automatica orizzontale dei pod (HPA) per i carichi di lavoro

Utilizza la scalabilità automatica orizzontale dei pod (HPA) per scalare dinamicamente i carichi di lavoro con pod aggiuntivi in base all'utilizzo delle risorse. Tieni presente quanto segue quando configuri HPA:

  • Utilizza il parametro --horizontal-pod-autoscaler-sync-period per kube-controller-manager per regolare la frequenza di polling del controller HPA. La frequenza di polling predefinita è di 15 secondi e potresti prendere in considerazione di impostarla su un valore inferiore se prevedi picchi di traffico più rapidi. Per scoprire di più su quando utilizzare HPA con GKE, consulta scalabilità automatica orizzontale dei pod.

  • Il comportamento di scalabilità predefinito può comportare il deployment (o la terminazione) di un numero elevato di pod contemporaneamente, il che può causare un picco nell'utilizzo delle risorse. Valuta la possibilità di utilizzare le policy di scalabilità per limitare la velocità con cui è possibile eseguire il deployment dei pod.

  • Utilizza EXIT_ON_ZERO_ACTIVE_CONNECTIONS per evitare di eliminare le connessioni durante lo scale down.

Per ulteriori dettagli su HPA, consulta scalabilità automatica orizzontale dei pod nella documentazione di Kubernetes.

Ottimizzare la configurazione del proxy Envoy

Per ottimizzare la configurazione del proxy Envoy, prendi in considerazione i seguenti consigli:

Limiti delle risorse

Puoi definire richieste e limiti di risorse per i sidecar Envoy nelle specifiche dei pod. In questo modo si evita la contesa delle risorse e si garantisce un rendimento coerente.

Puoi anche configurare i limiti di risorse predefiniti per tutti i proxy Envoy nel mesh utilizzando le annotazioni delle risorse.

I limiti di risorse ottimali per i proxy Envoy dipendono da fattori quali il volume di traffico, la complessità del carico di lavoro e le risorse dei nodi GKE. Monitora e ottimizza continuamente il service mesh per garantire prestazioni ottimali.

Considerazione importante:

  • Qualità del servizio (QoS): l'impostazione sia delle richieste sia dei limiti garantisce che i proxy Envoy abbiano una qualità del servizio prevedibile.

Ambito delle dipendenze del servizio

Valuta la possibilità di ridurre il grafico delle dipendenze del mesh dichiarando tutte le dipendenze tramite l'API Sidecar. In questo modo si limita la dimensione e la complessità della configurazione inviata a un determinato carico di lavoro, il che è fondamentale per i mesh più grandi.

Ad esempio, di seguito è riportato il grafico del traffico per l'applicazione di esempio Online Boutique.

Albero del grafico del traffico dell'applicazione di esempio Online Boutique con molte foglie

Molti di questi servizi sono foglie nel grafico e, di conseguenza, non devono avere informazioni in uscita per nessuno degli altri servizi nel mesh. Puoi applicare una risorsa Sidecar che limiti l'ambito della configurazione del sidecar per questi servizi foglia, come mostrato nell'esempio seguente.

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: leafservices
  namespace: default
spec:
  workloadSelector:
    labels:
      app: cartservice
      app: shippingservice
      app: productcatalogservice
      app: paymentservice
      app: emailservice
      app: currencyservice
  egress:
  -   hosts:
    -   "~/*"

Per i dettagli su come eseguire il deployment di questa applicazione di esempio, consulta Applicazione di esempio Online Boutique.

Un altro vantaggio dell'ambito del sidecar è la riduzione delle query DNS non necessarie. L'ambito delle dipendenze del servizio garantisce che un sidecar Envoy esegua query DNS solo per i servizi con cui comunicherà effettivamente, anziché per ogni cluster nel mesh di servizi.

Per tutti i deployment su larga scala che riscontrano problemi con le dimensioni delle configurazioni di grandi dimensioni nei sidecar, l'ambito delle dipendenze del servizio è vivamente consigliato per la scalabilità del mesh.

Per limitare l'ambito di configurazione per tutti i carichi di lavoro all'interno di un singolo spazio dei nomi, crea una risorsa Sidecar in quello spazio dei nomi. In questo modo, tutti i proxy Envoy all'interno di questo spazio dei nomi riceveranno solo la configurazione per i servizi nel proprio spazio dei nomi.

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: sidecar
  namespace: my-app
spec:
  egress:
  -   hosts:
    -   "my-app/*"

Puoi applicare il comportamento predefinito a ogni spazio dei nomi nel mesh applicando una singola risorsa Sidecar allo spazio dei nomi radice, in genere istio-system.

Il seguente sidecar limita il traffico in uscita di ogni sidecar nel mesh ai servizi che si trovano all'interno del proprio spazio dei nomi.

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: sidear
  namespace: istio-system
spec:
  egress:
  -   hosts:
    -   "./*"

Tieni presente che Cloud Service Mesh impone un limite al numero totale di risorse Sidecar che possono essere create all'interno di un singolo mesh. A causa di questo vincolo, la creazione di Sidecar a livello di spazio dei nomi è la pratica consigliata.

Monitorare e ottimizzare

Dopo aver impostato i limiti di risorse iniziali, è fondamentale monitorare i proxy Envoy per assicurarsi che funzionino in modo ottimale. Utilizza le dashboard GKE per monitorare l'utilizzo di CPU e memoria utilizzata e regolare i limiti di risorse in base alle esigenze.

Per determinare se un proxy Envoy richiede limiti di risorse maggiori, monitora il consumo di risorse in condizioni di traffico tipiche e di picco. Ecco cosa devi cercare:

  • Utilizzo elevato della CPU: se l'utilizzo della CPU di Envoy si avvicina costantemente al limite o lo supera, potrebbe avere difficoltà a elaborare le richieste, con conseguente aumento della latenza o eliminazione delle richieste. Valuta la possibilità di aumentare il limite della CPU.

    In questo caso, potresti essere propenso a scalare utilizzando la scalabilità orizzontale, ma se il proxy sidecar non è in grado di elaborare le richieste con la stessa rapidità del container dell'applicazione, la regolazione dei limiti della CPU potrebbe produrre i risultati migliori.

  • Utilizzo elevato della memoria: se la memoria utilizzata di Envoy si avvicina al limite o lo supera, potrebbe iniziare a eliminare le connessioni o riscontrare errori di memoria insufficiente (OOM). Aumenta il limite di memoria per evitare questi problemi.

  • Log degli errori: esamina i log di Envoy per verificare la presenza di errori relativi all'esaurimento delle risorse, ad esempio errori upstream connect error o disconnect or reset before headers o too many open files. Questi errori potrebbero indicare che il proxy ha bisogno di più risorse. Per altri errori relativi ai problemi di scalabilità, consulta i documenti sulla risoluzione dei problemi di scalabilità.

  • Metriche sul rendimento: monitora le metriche sul rendimento chiave, come la latenza delle richieste, le percentuali di errore e la velocità effettiva. Se noti un degrado del rendimento correlato a un utilizzo elevato delle risorse, potrebbe essere necessario aumentare i limiti.

Impostando e monitorando attivamente i limiti di risorse per i proxy del piano dati, puoi assicurarti che il service mesh venga scalato in modo efficiente su GKE.

Scalare il control plane

Questa sezione descrive le impostazioni da regolare per scalare il control plane.

Selettori di rilevamento

I selettori di rilevamento sono un campo in MeshConfig che ti consente di specificare l'insieme di spazi dei nomi che i control plane prendono in considerazione quando calcolano gli aggiornamenti della configurazione per i sidecar.

Per impostazione predefinita, Cloud Service Mesh monitora tutti gli spazi dei nomi nel cluster. Questo può rappresentare un collo di bottiglia per i cluster di grandi dimensioni che non devono monitorare tutte le risorse.

Utilizza discoverySelectors per ridurre il carico computazionale sul control plane limitando il numero di risorse Kubernetes (come servizi, pod ed endpoint) monitorate ed elaborate.

Quando utilizzi l'implementazione del control plane TRAFFIC_DIRECTOR, Cloud Service Mesh crea solo Google Cloud risorse, come i servizi di backend e i gruppi di endpoint di rete, per le risorse Kubernetes negli spazi dei nomi specificati in discoverySelectors.

Per ulteriori informazioni, consulta Selettori di rilevamento nella documentazione di Istio.

Creare resilienza

Puoi regolare le seguenti impostazioni per creare resilienza nel mesh di servizi:

Rilevamento outlier

Il rilevamento outlier monitora gli host in un servizio upstream e li rimuove dal pool di bilanciamento del carico al raggiungimento di una determinata soglia di errore.

  • Configurazione chiave:
    • outlierDetection: impostazioni che controllano l'eliminazione degli host con problemi di integrità dai pool di bilanciamento del carico.
  • Vantaggi: mantiene un insieme di host integri nel pool di bilanciamento del carico.

Per ulteriori informazioni, consulta Rilevamento outlier nella documentazione di Istio.

Nuovi tentativi

Mitiga gli errori temporanei riprovando automaticamente le richieste non riuscite.

  • Configurazione chiave:
    • attempts: numero di tentativi di ripetizione.
    • perTryTimeout: timeout per tentativo di ripetizione. Imposta questo valore su un valore inferiore al timeout complessivo. Determina per quanto tempo attenderai ogni singolo tentativo di ripetizione.
    • retryBudget: numero massimo di tentativi simultanei.
  • Vantaggi: percentuali di successo più elevate per le richieste, impatto ridotto degli errori intermittenti.

Fattori da considerare:

  • Idempotenza: assicurati che l'operazione di cui stai riprovando sia idempotente, il che significa che può essere ripetuta senza effetti collaterali indesiderati.
  • Numero massimo di tentativi: limita il numero di tentativi (ad es. massimo 3 tentativi) per evitare loop infiniti.
  • Interruzione del circuito: integra i tentativi con gli interruttori di circuito per impedire i tentativi quando un servizio non funziona in modo coerente.

Per ulteriori informazioni, consulta Nuovi tentativi nella documentazione di Istio.

Timeout

Utilizza i timeout per definire il tempo massimo consentito per l'elaborazione delle richieste.

  • Configurazione chiave:
    • timeout: timeout della richiesta per un servizio specifico.
    • idleTimeout: tempo durante il quale una connessione può rimanere inattiva prima della chiusura.
  • Vantaggi: maggiore reattività del sistema, prevenzione delle perdite di risorse, protezione dal traffico dannoso.

Fattori da considerare:

  • Latenza di rete: tieni conto del tempo di round trip (RTT) previsto tra i servizi. Lascia un po' di buffer per ritardi imprevisti.
  • Grafico delle dipendenze del servizio: per le richieste concatenate, assicurati che il timeout di un servizio chiamante sia inferiore al timeout cumulativo delle relative dipendenze per evitare errori a cascata.
  • Tipi di operazioni: le attività a lunga esecuzione potrebbero richiedere timeout significativamente più lunghi rispetto ai recuperi dei dati.
  • Gestione degli errori: i timeout devono attivare una logica di gestione degli errori appropriata (ad es. ripetizione, fallback, interruzione del circuito).

Per ulteriori informazioni, consulta Timeout nella documentazione di Istio.

Monitorare e ottimizzare

Ti consigliamo di iniziare con le impostazioni predefinite per timeout, rilevamento outlier e tentativi, quindi di regolarle gradualmente in base ai requisiti specifici del servizio e ai pattern di traffico osservati. Ad esempio, esamina i dati reali sul tempo di risposta dei tuoi servizi. Quindi, regola i timeout in modo che corrispondano alle caratteristiche specifiche di ogni servizio o endpoint.

Telemetria

Utilizza la telemetria per monitorare continuamente il mesh di servizi e regolarne la configurazione per ottimizzare le prestazioni e l'affidabilità.

  • Metriche: utilizza metriche complete, in particolare volumi di richieste, latenza e percentuali di errore. Integra con Cloud Monitoring per la visualizzazione e gli avvisi.
  • Tracciamento distribuito: abilita l'integrazione del tracciamento distribuito con Cloud Trace per ottenere informazioni approfondite sui flussi di richieste tra i servizi.
  • Logging: configura il logging degli accessi per acquisire informazioni dettagliate su richieste e risposte.

Letture aggiuntive