Prestazioni e scalabilità del componente aggiuntivo Istio Service Mesh

Il componente aggiuntivo Service Mesh basato su Istio viene suddiviso logicamente in un piano di controllo (istiod) e in un piano dati. Il piano dati è costituito da proxy collaterali Envoy all'interno dei pod del carico di lavoro. Istiod gestisce e configura questi proxy Envoy. Questo articolo presenta le prestazioni sia del piano di controllo sia del piano dati per la revisione asm-1-19, inclusi il consumo di risorse, la capacità dei sidecar e la latenza aggiuntiva. Fornisce inoltre suggerimenti per affrontare potenziali sollecitazioni sulle risorse durante periodi di carico elevato. Questo articolo illustra anche come personalizzare il ridimensionamento per il piano di controllo e i gateway.

Prestazioni del piano di controllo

I requisiti di CPU e memoria di Istiod sono correlati alla frequenza di modifiche a distribuzione e configurazione e al numero di proxy connessi. Gli scenari testati sono:

• Varianza dei pod: esamina l'impatto della varianza dei pod in istiod. Per ridurre le variabili, viene usato un solo servizio per tutti i sidecar.
• Più servizi: analizza l'impatto di più servizi sul numero massimo di sidecar che Istio può gestire (capacità dei sidecar), dove ogni servizio ha N sidecar, per un totale massimo complessivo.

Specifiche di test

• Un'istanza di istiod con le impostazioni predefinite
• Scalabilità automatica orizzontale dei pod disabilitata
• Testato con due plug-in di rete: Overlay CNI (Azure Container Networking Interface) e Overlay CNI di Azure con Cilium (plug-in di rete consigliati per cluster su larga scala)
• SKU del nodo: D16 Standard v3 (16 vCPU, 64 GB di memoria)
• Versione di Kubernetes: 1.28.5
• Revisione Istio: asm-1-19

Tasso di rotazione dei pod

Il framework ClusterLoader2 è stato utilizzato per determinare il numero massimo di sidecar che Istio può gestire quando si verifica una varianza rapida di sidecar. La percentuale di varianza viene definita come la percentuale di sidecar che subiscono variazioni di stato durante il test. Ad esempio, una varianza del 50% per 10.000 sidecar significherebbe che 5.000 sidecar sono stati eliminati e che 5.000 sidecar sono stati aggiunti. Le percentuali di abbandono testate sono state determinate dalla percentuale di abbandono tipica durante la distribuzione (maxUnavailable). Il tasso di abbandono è stato calcolato determinando il numero totale di file collaterali abbandonati (attivi e inattivi) nel tempo effettivo impiegato per completare il processo di abbandono.

Capacità dei sidecar e CPU e memoria di Istio

Overlay CNI di Azure

Overlay di Azure CNI con Cilium

Più servizi

Il framework ClusterLoader2 è stato usato per determinare il numero massimo di sidecar che istiod può gestire con 1.000 servizi. I risultati possono essere confrontati con il test di varianza dello 0% (un servizio) nello scenario di varianza dei pod. Ogni servizio aveva sidecar N che contribuiscono al numero massimo complessivo di sidecar. L'utilizzo delle risorse del server API è stato osservato per determinare se si è verificato uno stress significativo dal componente aggiuntivo.

Capacità del veicolo laterale

CPU e memoria

Prestazioni del piano dei dati

Vari fattori influiscono sulle prestazioni dei sidecar, ad esempio le dimensioni delle richieste, il numero di thread di lavoro proxy e il numero di connessioni client. Qualsiasi richiesta che attraversa la mesh attraversa inoltre il proxy lato client e quindi il proxy lato server. Pertanto, la latenza e il consumo di risorse vengono misurati per determinare le prestazioni del piano dati.

Fortio è stato usato per creare il carico. Il test è stato eseguito con il repository di benchmark Istio modificato per l'uso con il componente aggiuntivo.

Specifiche di test

• Testato con due plug-in di rete: Overlay CNI di Azure e Overlay CNI di Azure con Cilium (plug-in di rete consigliati per cluster su larga scala)
• SKU del nodo: D16 Standard v5 (16 vCPU, 64 GB di memoria)
• Versione di Kubernetes: 1.28.5
• Due processi di lavoro proxy
• Payload da 1 KB
• 1.000 query al secondo (QPS) con connessioni client variabili
• Protocollo http/1.1 e TLS (Transport Layer Security) reciproco abilitato
• 26 punti dati raccolti

CPU e memoria

L'utilizzo di memoria e CPU per il proxy del client e del server per 16 connessioni client e 1.000 QPS in tutti gli scenari di plugin di rete è approssimativamente 0,4 vCPU e 72 MB.

Latenza

Il proxy Envoy sidecar raccoglie i dati di telemetria non elaborati dopo aver risposto a un client. Ciò non influisce direttamente sul tempo di elaborazione totale della richiesta. Questo processo ritarda tuttavia l'inizio della gestione della richiesta successiva, contribuendo ai tempi di attesa delle code e influenzando le latenze medie e di coda. A seconda del modello di traffico, la latenza effettiva della coda varia.

I risultati seguenti valutano l'impatto dell'aggiunta di proxy collaterali al percorso dati, mostrando la latenza P90 e P99.

• Percorso del traffico collaterale: client --> client-sidecar --> server-sidecar --> server
• Percorso del traffico di base: client --> server

Un confronto delle prestazioni della latenza del piano di dati tra i componenti aggiuntivi di Istio e le versioni di AKS è disponibile qui.

Sovrimpressione di Azure CNI	Overlay CNI di Azure con Cilium

Scalabilità

Personalizzazione della scalabilità automatica orizzontale dei pod (HPA)

La scalabilità automatica orizzontale dei pod (HPA) è abilitata per le distribuzioni istiod e di gateway in ingresso/in uscita. Le configurazioni predefinite per istiod e i gateway sono:

• Numero minimo di repliche: 2
• Numero massimo di repliche: 5
• Utilizzo della CPU: 80%

Di seguito sono riportate le risorse istiod e HPA del gateway in ingresso:

NAMESPACE           NAME                                         REFERENCE
aks-istio-ingress   aks-istio-ingressgateway-external-asm-1-19   Deployment/aks-istio-ingressgateway-external-asm-1-19

aks-istio-ingress   aks-istio-ingressgateway-internal-asm-1-19   Deployment/aks-istio-ingressgateway-internal-asm-1-19

aks-istio-system    istiod-asm-1-19                              Deployment/istiod-asm-1-19

La configurazione della scalabilità automatica orizzontale (HPA) può essere modificata tramite patch e modifiche dirette. Esempio:

kubectl patch hpa aks-istio-ingressgateway-external-asm-1-19 -n aks-istio-ingress --type merge --patch '{"spec": {"minReplicas": 3, "maxReplicas": 6}}'

Voce del servizio

La definizione di risorsa personalizzata ServiceEntry di Istio consente di aggiungere altri servizi nel registro del servizio interno di Istio. ServiceEntry consente ai servizi già nella mesh di instradare o accedere ai servizi specificati. Tuttavia, la configurazione di più ServiceEntry con il campo resolution impostato su DNS può causare un carico elevato nei server DNS (Domain Name System). I suggerimenti seguenti consentono di ridurre il carico:

• Passare a resolution: NONE per evitare completamente ricerche DNS proxy. Adatto per la maggior parte dei casi d'uso. Tuttavia, quando si utilizza un Istio add-on egress gateway, la risoluzione ServiceEntry deve essere configurata su DNS.
• Aumentare la durata (TTL) se si ha il controllo dei domini da risolvere.
• Limitare l'ambito di ServiceEntry con exportTo.