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 è composto da proxy sidecar 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 che del piano dati per la revisione asm-1-19, tra cui consumo di risorse, capacità sidecar e sovraccarico della latenza. 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:

• Abbandono dei pod: esamina l'impatto dell'abbandono dei pod su istiod. Per ridurre le variabili, viene usato un solo servizio per tutti i sidecar.
• Più servizi: esamina l'impatto di più servizi sul numero massimo di sidecar che Istiod può gestire (capacità sidecar), in cui ogni servizio ha N sidecar, che rappresentano in totale il numero 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

Abbandono dei pod

Il framework ClusterLoader2 è stato usato per determinare il numero massimo di sidecar che Istiod è in grado di gestire quando è presente un abbandono di sidecar. La percentuale di abbandono viene definita come percentuale di sidecar inattivi/attivi durante il test. Ad esempio, un abbandono del 50% per 10.000 sidecar significherebbe che 5.000 sidecar erano inattivo, quindi 5.000 sidecar erano attivi. Le percentuali di abbandono testate sono state determinate dalla percentuale di abbandono tipica durante le implementazioni della distribuzione (maxUnavailable). L'abbandono è stato calcolato determinando il numero totale di sidecar abbandonati (attivi e inattivi) nel tempo effettivo impiegato per completare il processo di abbandono.

Capacità sidecar e CPU e memoria di Istiod

Overlay CNI di Azure

Overlay CNI di Azure 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 abbandono del 0% (un servizio) nello scenario di abbandono dei pod. Ogni servizio aveva N sidecar che contribuiscono al conteggio del 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à sidecar

CPU e memoria

Prestazioni del piano 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 ruoli 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 abilitati
• 26 punti dati raccolti

CPU e memoria

L'utilizzo di memoria e CPU per il proxy client e server per 16 connessioni client e 1.000 query al secondo in tutti gli scenari di plug-in 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 sidecar al percorso dati, mostrando la latenza P90 e P99.

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

Un confronto delle prestazioni della latenza del piano dati tra i componenti aggiuntivi Istio e le versioni del servizio Azure Kubernetes sono disponibili qui.

Sovrimpressione di Azure CNI	Overlay CNI di Azure con Cilium

Scalabilità

Personalizzazione della scalabilità automatica orizzontale dei pod

La scalabilità automatica orizzontale dei pod è abilitata per istiod e i pod gateway in ingresso. 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 di scalabilità automatica orizzontale dei pod di istiod e 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 dei pod 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.
• Aumentare la durata (TTL) se si controllano i domini risolti.
• Limitare l'ambito di ServiceEntry con exportTo.