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

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

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

Identificare i problemi di scalabilità del piano di controllo rispetto al piano di dati

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

Sintomi di problemi di scalabilità del piano di controllo

Rilevamento lento dei servizi: i nuovi servizi o endpoint impiegano molto tempo per essere rilevati e resi disponibili.

Ritardi nella configurazione:le modifiche alle regole di gestione del traffico o ai criteri di sicurezza richiedono molto tempo per essere propagate.

Aumento della latenza nelle operazioni del piano di controllo: 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 notare errori nei log di Cloud Service Mesh o nelle metriche del piano di controllo che indicano problemi di connettività, esaurimento delle risorse o limitazione delle API.

Ambito dell'impatto: i problemi del piano di controllo in genere interessano l'intero mesh, provocando un degrado del rendimento diffuso.

Sintomi di problemi di scalabilità del piano dati

Aumento della latenza nella comunicazione tra servizi: le richieste a un servizio in mesh presentano latenze o timeout più elevati, ma non è registrato un utilizzo elevato della CPU/memoria nei contenitori del servizio.

Utilizzo elevato della CPU o della memoria nei proxy Envoy: un utilizzo elevato della CPU o della memoria può indicare che i proxy hanno difficoltà a gestire il carico del 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.

Scalabilità del piano dati

Per scalare il piano dati, prova le seguenti tecniche:

Configura la scalabilità automatica del pod orizzontale (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. Considera quanto segue quando configuri l'HPA:

  • Utilizza il parametro --horizontal-pod-autoscaler-sync-period per kube-controller-manager regolare la frequenza di polling del controller HPA. La frequenza di polling predefinita è di 15 secondi e ti consigliamo 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 l'interruzione) contemporaneamente di un numero elevato di pod, il che può causare un picco nell'utilizzo delle risorse. Valuta la possibilità di utilizzare i criteri di scalabilità per limitare la frequenza di dispiegamento dei pod.

  • Utilizza EXIT_ON_ZERO_ACTIVE_CONNECTIONS per evitare interruzioni delle connessioni durante il ridimensionamento.

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

Ottimizzare la configurazione del proxy Envoy

Per ottimizzare la configurazione del proxy Envoy, tieni presenti i seguenti consigli:

Limiti delle risorse

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

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

I limiti di risorse ottimali per i proxy Envoy dipendono da fattori quali il volume del traffico, la complessità del carico di lavoro e le risorse dei nodi GKE. Monitora e perfeziona continuamente il tuo 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.

Dipendenze del servizio di ambito

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

Ad esempio, di seguito è riportato il grafico del traffico per l'applicazione di esempio della boutique online.

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

Molti di questi servizi sono nodi a foglia nel grafico e, pertanto, non devono avere informazioni sull'uscita per nessuno degli altri servizi nel mesh. Puoi applicare una risorsa Sidecar che limiti l'ambito della configurazione del sidecar per questi servizi principali, 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 informazioni dettagliate su come eseguire il deployment di questa applicazione di esempio, consulta App di esempio Online Boutique.

Un altro vantaggio dell'ambito sidecar è la riduzione delle query DNS non necessarie. Le dipendenze dei servizi basate sugli ambiti assicurano che un sidecar Envoy esegua query DNS solo per i servizi con cui effettivamente comunicherà, anziché per ogni cluster nel mesh di servizi.

Per qualsiasi deployment su larga scala che presenta problemi con dimensioni di configurazione elevate nei sidecar, è fortemente consigliato definire l'ambito delle dipendenze dei servizi per la scalabilità del mesh.

Monitoraggio e perfezionamento

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 e modificare i limiti di risorse in base alle esigenze.

Per determinare se un proxy Envoy richiede limiti di risorse più elevati, monitora il suo consumo di risorse in condizioni di traffico normali e di picco. Ecco cosa cercare:

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

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

  • Utilizzo elevato della memoria: se l'utilizzo della memoria di Envoy si avvicina o supera il suo limite, potrebbe iniziare a perdere connessioni o riscontrare errori di esaurimento della memoria (OOM). Aumenta il limite di memoria per evitare questi problemi.

  • Log degli errori: esamina i log di Envoy per rilevare errori relativi all'esaurimento delle risorse, ad esempio errore di connessione upstream o disconnessione o reimpostazione prima degli intestazioni o troppi file aperti. Questi errori potrebbero indicare che il proxy necessita di più risorse. Consulta la documentazione sulla risoluzione dei problemi di scalabilità per altri errori relativi a questo tipo di problemi.

  • Metriche sul rendimento:monitora le metriche sul rendimento chiave, come la latenza delle richieste, le percentuali di errore e il throughput. Se noti un peggioramento delle prestazioni correlato a un elevato utilizzo 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 tuo service mesh sia scalabile in modo efficiente su GKE.

Sviluppare la resilienza

Per scalare il piano di controllo, puoi modificare le seguenti impostazioni:

Rilevamento outlier

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

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

Per ulteriori informazioni, consulta Rilevamento delle anomalie nella documentazione di Istio.

Nuovi tentativi

Riduci gli errori temporanei riprovando automaticamente le richieste non riuscite.

  • Configurazione delle chiavi:
    • attempts: numero di tentativi di nuovo invio.
    • perTryTimeout: timeout per ogni tentativo di ripetizione. Imposta un valore inferiore al timeout complessivo. Determina il tempo di attesa per ogni singolo tentativo di ripetizione.
    • retryBudget: numero massimo di nuovi 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 viene tentato il nuovo tentativo sia idempotente, ovvero che possa essere ripetuta senza effetti collaterali indesiderati.
  • Nuovi tentativi massimi:limita il numero di nuovi tentativi (ad es. 3) per evitare loop infiniti.
  • Interruttori di sicurezza:integra i tentativi con gli interruttori di sicurezza per evitare i tentativi quando un servizio presenta costantemente errori.

Per saperne di più, consulta la sezione Ritenta nella documentazione di Istio.

Timeout

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

  • Configurazione delle chiavi:
    • timeout: timeout della richiesta per un servizio specifico.
    • idleTimeout: il tempo di inattività di una connessione prima della chiusura.
  • Vantaggi: maggiore reattività del sistema, prevenzione delle perdite di risorse, rafforzamento contro il traffico dannoso.

Fattori da considerare:

  • Latenza di rete:tieni conto del tempo di round trip (RTT) previsto tra i servizi. Lascia un po' di tempo per eventuali ritardi imprevisti.
  • Grafo delle dipendenze dei servizi:per le richieste in catena, assicurati che il timeout di un servizio chiamante sia inferiore al timeout cumulativo delle sue dipendenze per evitare errori a cascata.
  • Tipi di operazioni:le attività che richiedono molto tempo potrebbero richiedere timeout molto più lunghi rispetto al recupero dei dati.
  • Gestione degli errori: i timeout devono attivare la logica di gestione degli errori appropriata (ad es. riprova, piano di riserva, interruzione del circuito).

Per ulteriori informazioni, consulta la sezione Timeout della documentazione di Istio.

Monitoraggio e perfezionamento

Ti consigliamo di iniziare con le impostazioni predefinite per i timeout, il rilevamento degli outlier e i tentativi di nuovo invio, quindi di modificarle gradualmente in base ai requisiti specifici del servizio e ai pattern di traffico osservati. Ad esempio, esamina i dati reali sul tempo di risposta in genere dei tuoi servizi. Modifica quindi i timeout in base alle caratteristiche specifiche di ogni servizio o endpoint.

Telemetria

Utilizza la telemetria per monitorare continuamente il tuo service mesh e modificarne la configurazione al fine di ottimizzare le prestazioni e l'affidabilità.

  • Metriche: utilizza metriche complete, in particolare volumi di richieste, latenza e percentuali di errore. Esegui l'integrazione con Cloud Monitoring per la visualizzazione e la gestione degli avvisi.
  • Tracciamento distribuito:attiva l'integrazione del monitoraggio distribuito con Cloud Trace per ottenere informazioni approfondite sui flussi di richieste nei tuoi servizi.
  • Logging:configura il logging delle richieste per acquisire informazioni dettagliate su richieste e risposte.

Letture aggiuntive