Istio service mesh bővítmény teljesítménye és skálázása

Az Istio-alapú service mesh bővítmény logikailag egy vezérlősíkra (istiod) és egy adatsíkra van felosztva. Az adatsík a számítási feladatok podjaiban lévő, megbízott oldalkocsi-proxykból áll. Az Istiod felügyeli és konfigurálja ezeket a megbízott proxykat. Ez a cikk az ASM-1-19 verzió vezérlő- és adatsíkjának teljesítményét mutatja be, beleértve az erőforrás-felhasználást, az oldalkocsi-kapacitást és a késési többletterhelést. Emellett javaslatokat is kínál az erőforrások esetleges terhelésének kezelésére a nagy terhelésű időszakokban. Ez a cikk azt is ismerteti, hogyan szabhatja testre a skálázást a vezérlősíkhoz és az átjárókhoz.

Vezérlősík teljesítménye

Az Istiod processzor- és memóriakövetelményei korrelálnak az üzembe helyezés és a konfiguráció változásainak gyakoriságával, valamint a csatlakoztatott proxyk számával. A tesztelt forgatókönyvek a következőek voltak:

• Pod-forgalom: megvizsgálja a pod-forgalom hatását.istiod A változók csökkentése érdekében minden oldalkocsihoz csak egy szolgáltatást használunk.
• Több szolgáltatás: megvizsgálja, hogy több szolgáltatás milyen hatással van a maximális oldalkocsikra Az Istiod képes kezelni (oldalkocsi-kapacitás), ahol minden szolgáltatás oldalkocsikkal rendelkezik N , a teljes maximális érték összegével.

Tesztelési specifikációk

• Egy istiod példány alapértelmezett beállításokkal
• A pod automatikus horizontális skálázása le van tiltva
• Két hálózati beépülő modullal tesztelve: Azure Container Networking Interface (CNI) Overlay és Azure CNI Overlay with Cilium (nagy méretű fürtökhöz ajánlott hálózati beépülő modulok)
• Csomópont termékváltozata: Standard D16 v3 (16 vCPU, 64 GB memória)
• Kubernetes-verzió: 1.28.5
• Istio változat: asm-1-19

Pod-forgalom

A ClusterLoader2 keretrendszer segítségével határozható meg, hogy az Istiod legfeljebb hány oldalkocsit kezelhet oldalkocsi-forgalom esetén. A forgalom százalékát az oldalkocsik százalékos aránya határozza meg, amely a teszt során lefelé/felfelé csúszik. Például a 10 000 oldalkocsi 50%-os lecsúszása azt jelentené, hogy 5000 oldalkocsit lecsúsztak, majd 5000 oldalkocsit felborítottak. A tesztelt adatváltozási százalékokat az üzembe helyezés ()maxUnavailable során jellemző forgalom százalékos arányából határoztuk meg. Az adatváltozási arányt úgy számítottuk ki, hogy az oldalkocsik teljes számát (felfelé és lefelé) határozzuk meg az adatváltozási folyamat befejezéséhez szükséges tényleges idő alatt.

Sidecar kapacitás és istiod CPU és memória

Azure CNI-átfedés

Azure CNI-átfedés a Ciliummal

Több szolgáltatás

A ClusterLoader2 keretrendszer segítségével határozható meg, hogy az oldalkocsik istiod maximális száma 1000 szolgáltatással kezelhető-e. Az eredmények összehasonlíthatók a pod-forgalom forgatókönyvében a 0%-os forgalomtesztel (egy szolgáltatással). Minden szolgáltatásban oldalkocsik voltak N , amelyek hozzájárultak a maximális oldalkocsiszámhoz. Megfigyelték az API Server erőforrás-használatát annak megállapításához, hogy van-e jelentős terhelés a bővítményben.

Oldalkocsi kapacitása

CPU és memória

Adatsík teljesítménye

Különböző tényezők befolyásolják az oldalkocsi teljesítményét , például a kérések méretét, a proxymunkaszálak számát és az ügyfélkapcsolatok számát. Ezenkívül a hálón áthaladó kérések bejárják az ügyféloldali proxyt, majd a kiszolgálóoldali proxyt. Ezért a rendszer a késést és az erőforrás-felhasználást méri az adatsík teljesítményének meghatározásához.

Fortio a rendszer a terhelés létrehozásához használta. A tesztet az Istio benchmark-adattárral végezték, amelyet a bővítményhez való használatra módosítottak.

Tesztelési specifikációk

• Két hálózati beépülő modullal tesztelve: Azure CNI Overlay és Azure CNI Overlay with Cilium (nagy méretű fürtökhöz ajánlott hálózati beépülő modulok)
• Csomópont termékváltozata: Standard D16 v5 (16 vCPU, 64 GB memória)
• Kubernetes-verzió: 1.28.5
• Két proxymunkás
• 1 KB hasznos adat
• Másodpercenként 1000 lekérdezés (QPS) különböző ügyfélkapcsolatokon
• http/1.1 protokoll és kölcsönös transport layer security (TLS) engedélyezve
• 26 összegyűjtött adatpont

CPU és memória

Az ügyfél- és kiszolgálóproxy memória- és processzorhasználata 16 ügyfélkapcsolat és 1000 QPS esetén az összes hálózati beépülő modul esetében nagyjából 0,4 vCPU és 72 MB.

Késés

A sidecar envoy proxy nyers telemetriai adatokat gyűjt az ügyfélre való válaszadás után, ami közvetlenül nem befolyásolja a kérés teljes feldolgozási idejét. Ez a folyamat azonban késlelteti a következő kérés kezelésének kezdetét, hozzájárulva a várakozási várakozási időhöz, valamint az átlagos és a farok késésének befolyásolásához. A forgalmi mintától függően a tényleges késés eltérő.

Az alábbi eredmények kiértékelik az oldalkocsi-proxyk adatútvonalhoz való hozzáadásának hatását, ami a P90 és A P99 késését mutatja.

• Oldalkocsi forgalmi útvonala: ügyfél --> ügyféloldali kocsi --> kiszolgálóoldali kocsi --> kiszolgáló
• Alapterv forgalmi útvonala: ügyfél –> kiszolgáló

Az adatsík késési teljesítményének összehasonlítása az Istio bővítmények és az AKS-verziók között itt található.

Azure CNI Overlay	Azure CNI-átfedés a Ciliummal

Méretezés

A pod automatikus horizontális skálázásának testreszabása

A podok automatikus horizontális skálázása (HPA) engedélyezve van a istiod bejövő átjáró podjaihoz. Az átjárók alapértelmezett konfigurációi istiod a következők:

• Minimális replikák: 2
• Maximális replikák: 5
• CPU-kihasználtság: 80%

A bejövő és bejövő átjáró HPA-erőforrásai a istiod következők:

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

A HPA-konfiguráció javításokkal és közvetlen módosításokkal módosítható. Példa:

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

Szolgáltatásbejegyzés

Az Istio ServiceEntry egyéni erőforrásdefiníciója lehetővé teszi más szolgáltatások hozzáadását az Istio belső szolgáltatásregisztrációs adatbázisába. A ServiceEntry lehetővé teszi, hogy a hálóban lévő szolgáltatások irányítják vagy érhessék el a megadott szolgáltatásokat. Azonban több ServiceEntries konfigurációja a resolution DNS-hez beállított mezővel nagy terhelést okozhat a tartománynévrendszer-kiszolgálókon. A következő javaslatok segíthetnek a terhelés csökkentésében:

• Váltson a resolution: NONE proxy DNS-keresések teljes elkerülésére. A legtöbb használati esethez alkalmas.
• A feloldott tartományok szabályozása esetén növelje a TTL-t (élettartam).
• A ServiceEntry hatókörének korlátozása a következővel exportTo: .