Sdílet prostřednictvím

Výkon a škálování doplňku Istio Service Mesh

  • Článek

Doplněk sítě služeb založený na Istio je logicky rozdělený na řídicí rovinu (istiod) a rovinu dat. Datová rovina se skládá z proxy serverů sajdkáře envoy uvnitř podů úloh. Istiod spravuje a konfiguruje tyto proxy servery envoy. Tento článek představuje výkon řídicí roviny i roviny dat pro revizi asm-1-19, včetně spotřeby prostředků, kapacity sajdkáře a režie latence. Kromě toho nabízí návrhy pro řešení potenciálního zatížení prostředků během období velkého zatížení. Tento článek také popisuje, jak přizpůsobit škálování řídicí roviny a bran.

Výkon řídicí roviny

Požadavky na procesor a paměť společnosti Istiod korelují s rychlostí změn nasazení a konfigurace a počtem připojených proxy serverů. Otestované scénáře:

  • Četnost změn podů: zkoumá dopad změn podů na istiod. Ke snížení proměnných se pro všechny sajdkáře používá pouze jedna služba.
  • Více služeb: zkoumá dopad více služeb na maximální sajdkáře Istiod může spravovat (kapacitu sajdkáře), kde každá služba má N sajdkáře, přičemž celkový maximální součet.

Specifikace testů

  • Jedna istiod instance s výchozím nastavením
  • Horizontální automatické škálování podů zakázáno
  • Testováno se dvěma síťovými moduly plug-in: Překrytí Azure Container Networking Interface (CNI) a Překrytí Azure CNI s Cilium (doporučené síťové moduly plug-in pro velké clustery)
  • Skladová položka uzlu: Standard D16 v3 (16 vCPU, 64 GB paměti)
  • Verze Kubernetes: 1.28.5
  • Revize Istio: asm-1-19

Četnost změn podů

Architektura ClusterLoader2 se použila k určení maximálního počtu sajdkárů Istiod může spravovat, když dojde k četnosti změn sajdkáru. Procento četnosti změn je definováno jako procento četnosti změn sajdkáru v průběhu testu. Například 50% četnost změn pro 10 000 sajdkáře by znamenalo, že 5 000 sajdkáře bylo churno dolů, pak bylo 5 000 sajdkárů vyrušováno. Testované procento četnosti změn bylo určeno z typického procenta četnosti změn během zavádění nasazení (maxUnavailable). Četnost změn se vypočítala určením celkového počtu četnosti změn sajdkár (nahoru a dolů) v průběhu skutečného času potřebného k dokončení procesu četnosti změn.

Kapacita sajdkáře a procesor Istiod a paměť

Překrytí Azure CNI

Četnost změn (%) Četnost změn (sajdkárna/s) Kapacita sajdkáře Paměť Istiod (GB) Procesor Istiod
0 -- 250 000 32.1 15
25 31.2 15000 22.2 15
50 31.2 15000 25.4 15

Překrytí Azure CNI pomocí Cilium

Četnost změn (%) Četnost změn (sajdkárna/s) Kapacita sajdkáře Paměť Istiod (GB) Procesor Istiod
0 -- 30000 41.2 15
25 41.7 250 000 36.1 16
50 37.9 250 000 42.7 16

Více služeb

Architektura ClusterLoader2 se použila k určení maximálního počtu sajdkárů, které lze spravovat s 1 000 službami istiod . Výsledky je možné porovnat s 0% testem četnosti změn (jednou službou) ve scénáři četnosti změn podů. Každá služba měla N sajdkáře přispívající k celkovému maximálnímu počtu sajdkár. Zjistilo se, že využití prostředků serveru ROZHRANÍ API bylo zjištěno, jestli z doplňku nedošlo k významnému stresu.

Kapacita sajdkáře

Azure CNI Overlay Překrytí Azure CNI pomocí Cilium
20 000 20 000

Procesor a paměť

Prostředek Azure CNI Overlay Překrytí Azure CNI pomocí Cilium
Paměť serveru API (GB) 38.9 9.7
Procesor serveru API 6.1 4.7
Paměť Istiod (GB) 40.4 42.6
Procesor Istiod 15 16

Výkon roviny dat

Různé faktory ovlivňují výkon sajdkáře, jako je velikost požadavku, počet pracovních vláken proxy serveru a počet klientských připojení. Kromě toho všechny požadavky procházející sítí prochází proxy serverem na straně klienta a pak proxy serverem na straně serveru. Proto se latence a spotřeba prostředků měří za účelem určení výkonu roviny dat.

Fortio byla použita k vytvoření zatížení. Test byl proveden s úložištěm srovnávacích testů Istio, které bylo upraveno pro použití s doplňkem.

Specifikace testů

  • Testováno se dvěma síťovými moduly plug-in: Azure CNI Overlay a Azure CNI Overlay with Cilium (doporučené síťové moduly plug-in pro rozsáhlé clustery)
  • Skladová položka uzlu: Standard D16 v5 (16 vCPU, 64 GB paměti)
  • Verze Kubernetes: 1.28.5
  • Dva pracovní procesy proxy serveru
  • Datová část 1 kB
  • 1 000 dotazů za sekundu (QPS) v různých klientských připojeních
  • http/1.1 protokoly a vzájemné povolení protokolu TLS (Transport Layer Security)
  • 26 shromážděných datových bodů

Procesor a paměť

Využití paměti a procesoru pro klientskou i serverovou proxy server pro 16 klientských připojení a 1 000 QPS ve všech scénářích síťového plug-inu je přibližně 0,4 vCPU a 72 MB.

Latence

Proxy sajdkárna Envoy shromažďuje nezpracovaná telemetrická data po reakci na klienta, která přímo neovlivňuje celkovou dobu zpracování požadavku. Tento proces ale zpožďuje zahájení zpracování dalšího požadavku, což přispívá k době čekání ve frontě a ovlivňuje průměrné a koncové latence. V závislosti na vzoru provozu se skutečná koncová latence liší.

Následující výsledky vyhodnocují dopad přidávání proxy sajdkár do cesty k datům, ukazující latenci P90 a P99.

  • Cesta provozu sajdkáře: klient –-> client-sidecar --> server-sidecar --> server
  • Směrná cesta provozu: klient –> server

Tady najdete porovnání výkonu latence roviny dat napříč doplňky Istio a verzemi AKS.

Azure CNI Overlay Překrytí Azure CNI pomocí Cilium
Diagram, který porovnává latenci P99 pro překrytí Azure CNI Diagram, který porovnává latenci P99 pro překrytí Azure CNI s Cilium
Diagram, který porovnává latenci P90 pro překrytí Azure CNI Diagram, který porovnává latenci P90 pro překrytí Azure CNI s Cilium

Škálování

Přizpůsobení automatického škálování horizontálního podu

Horizontální automatické škálování podů (HPA) je pro pody brány a příchozího přenosu dat povolené istiod . Výchozí konfigurace pro istiod brány jsou:

  • Minimální repliky: 2
  • Maximální počet replik: 5
  • Využití procesoru: 80 %

Poznámka:

Chcete-li zabránit konfliktům s doplňkem PodDisruptionBudget, doplněk nepovoluje nastavení minReplicas pod počáteční výchozí hodnotou 2.

Tady jsou istiod prostředky HPA brány příchozího přenosu dat:

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

Konfiguraci HPA je možné upravit prostřednictvím oprav a přímých úprav. Příklad:

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

Poznámka:

Podrobnosti o způsobu použití nastavení HPA v obou revizích během kanárového upgradu najdete v dokumentaci k upgradu doplňku Istio.

Položka služby

Vlastní definice prostředku Istio ServiceEntry umožňuje do interního registru služeb Istio přidávat další služby. ServiceEntry umožňuje službám, které jsou již v síti, směrovat nebo přistupovat ke zadaným službám. Konfigurace více serviceEntries s polem resolution nastaveným na DNS však může způsobit velké zatížení serverů DNS (Domain Name System). Následující návrhy vám můžou pomoct snížit zatížení:

  • Přepněte, abyste resolution: NONE se vyhnuli úplně vyhledávání DNS proxy serveru. Vhodné pro většinu případů použití.
  • Pokud řídíte překládat domény, zvyšte hodnotu TTL (Time To Live).
  • Omezte rozsah ServiceEntry na exportTo.