Share via


Prestaties en schaalaanpassing van invoegtoepassingen voor Istio-service

De invoegtoepassing service mesh op basis van Istio wordt logisch gesplitst in een besturingsvlak (istiod) en een gegevensvlak. Het gegevensvlak bestaat uit Envoy-sidecarproxy's binnen workloadpods. Istiod beheert en configureert deze Envoy-proxy's. Dit artikel bevat de prestaties van zowel het besturingsvlak als het gegevensvlak voor revisie asm-1-19, waaronder resourceverbruik, sidecarcapaciteit en latentieoverhead. Daarnaast biedt het suggesties voor het aanpakken van mogelijke belasting van resources tijdens perioden van zware belasting. Dit artikel bevat ook informatie over het aanpassen van schalen voor het besturingsvlak en de gateways.

Prestaties van besturingsvlak

De CPU- en geheugenvereisten van Istiod correleren met de snelheid van implementatie- en configuratiewijzigingen en het aantal verbonden proxy's. De geteste scenario's zijn:

  • Podverloop: onderzoekt de impact van podverloop op istiod. Om variabelen te verminderen, wordt slechts één service gebruikt voor alle sidecars.
  • Meerdere services: onderzoekt de impact van meerdere services op de maximale sidecars die Istiod kan beheren (sidecarcapaciteit), waarbij elke service sidecars heeft N , waardoor het totale maximum wordt opgetellen.

Testspecificaties

  • Eén istiod exemplaar met standaardinstellingen
  • Horizontaal automatisch schalen van pods uitgeschakeld
  • Getest met twee netwerkinvoegtoepassingen: Azure Container Networking Interface (CNI) Overlay en Azure CNI-overlay met Cilium (aanbevolen netwerkinvoegtoepassingen voor grootschalige clusters)
  • Knooppunt-SKU: Standard D16 v3 (16 vCPU, 64 GB geheugen)
  • Kubernetes-versie: 1.28.5
  • Istio revisie: asm-1-19

Podverloop

Het ClusterLoader2-framework is gebruikt om te bepalen hoeveel sidecars Istiod maximaal kan beheren wanneer er sidecarverloop is. Het verlooppercentage wordt gedefinieerd als het percentage sidecars dat tijdens de test omlaag/omhoog is geverloop. 50% verloop voor 10.000 sidecars betekent bijvoorbeeld dat 5.000 zijcars omlaag zijn geverloopd en dat 5.000 zijcars omhoog zijn geverloop. De geteste verlooppercentages zijn bepaald op basis van het typische verlooppercentage tijdens implementatie-implementaties (maxUnavailable). Het verlooppercentage is berekend door het totale aantal sidecars te bepalen dat gedurende de werkelijke tijd die nodig is om het verloopproces te voltooien.

Sidecar-capaciteit en Istiod CPU en geheugen

Azure CNI-overlay

Verloop (%) Verloopsnelheid (sidecars/sec) Sidecar-capaciteit Istiod-geheugen (GB) Istiod CPU
0 -- 25.000 32.1 15
25 31.2 15000 22.2 15
50 31.2 15000 25.4 15

Azure CNI-overlay met Cilium

Verloop (%) Verloopsnelheid (sidecars/sec) Sidecar-capaciteit Istiod-geheugen (GB) Istiod CPU
0 -- 30.000 41.2 15
25 41.7 25.000 36.1 16
50 37.9 25.000 42.7 16

Meerdere services

Het ClusterLoader2-framework is gebruikt om te bepalen hoeveel sidecars istiod maximaal kunnen worden beheerd met 1000 services. De resultaten kunnen worden vergeleken met de 0% verlooptest (één service) in het podverloopscenario. Elke service had N sidecars die bijdragen aan het totale maximumaantal sidecars. Het resourcegebruik van de API Server is waargenomen om te bepalen of er sprake is van aanzienlijke stress van de invoegtoepassing.

Sidecar-capaciteit

Azure CNI-overlay Azure CNI-overlay met Cilium
20000 20000

CPU en geheugen

Bron Azure CNI-overlay Azure CNI-overlay met Cilium
GEHEUGEN VAN API-server (GB) 38.9 9.7
CPU van API-server 6.1 4.7
Istiod-geheugen (GB) 40.4 42.6
Istiod CPU 15 16

Prestaties van gegevensvlak

Verschillende factoren zijn van invloed op sidecarprestaties , zoals de aanvraaggrootte, het aantal proxywerkrolthreads en het aantal clientverbindingen. Bovendien doorloopt elke aanvraag die via de mesh stroomt de proxy aan de clientzijde en vervolgens de proxy aan de serverzijde. Daarom worden latentie en resourceverbruik gemeten om de prestaties van het gegevensvlak te bepalen.

Fortio is gebruikt om de belasting te maken. De test is uitgevoerd met de Istio-benchmarkopslagplaats die is gewijzigd voor gebruik met de invoegtoepassing.

Testspecificaties

  • Getest met twee netwerkinvoegtoepassingen: Azure CNI Overlay en Azure CNI-overlay met Cilium (aanbevolen netwerkinvoegtoepassingen voor grootschalige clusters)
  • Knooppunt-SKU: Standard D16 v5 (16 vCPU, 64 GB geheugen)
  • Kubernetes-versie: 1.28.5
  • Twee proxymedewerkers
  • Nettolading van 1 kB
  • 1000 query's per seconde (QPS) bij verschillende clientverbindingen
  • http/1.1 protocol en wederzijdse TLS (Transport Layer Security) ingeschakeld
  • 26 verzamelde gegevenspunten

CPU en geheugen

Het geheugen- en CPU-gebruik voor zowel de client- als serverproxy voor 16 clientverbindingen en 1000 QPS in alle scenario's met netwerkinvoegtoepassingen is ongeveer 0,4 vCPU en 72 MB.

Latentie

De Sidecar Envoy-proxy verzamelt onbewerkte telemetriegegevens na het reageren op een client, wat niet rechtstreeks van invloed is op de totale verwerkingstijd van de aanvraag. Dit proces vertraagt echter het begin van de verwerking van de volgende aanvraag, wat bijdraagt aan wachttijden in de wachtrij en het beïnvloeden van gemiddelde en staartlatenties. Afhankelijk van het verkeerspatroon varieert de werkelijke tail-latentie.

De volgende resultaten evalueren de impact van het toevoegen van sidecarproxy's aan het gegevenspad, waarbij de latentie P90 en P99 worden weergegeven.

  • Sidecar-verkeerspad: client-sidecar> --> server-sidecar --> server
  • Basislijnverkeerspad: client --> server

Hier vindt u een vergelijking van de prestaties van gegevensvlaklatentie in istio-invoegtoepassing en AKS-versies.

Azure CNI-overlay Azure CNI-overlay met Cilium
Diagram waarmee de P99-latentie voor Azure CNI-overlay wordt vergeleken. Diagram waarmee de P99-latentie voor Azure CNI-overlay wordt vergeleken met Cilium.
Diagram waarmee de P90-latentie voor Azure CNI-overlay wordt vergeleken. Diagram waarmee de P90-latentie voor Azure CNI-overlay wordt vergeleken met Cilium.

Schalen

Aanpassing van automatische schaalaanpassing van horizontale pods

Horizontaal schalen van pods (HPA) is ingeschakeld voor de istiod gatewaypods en gatewaypods voor inkomend verkeer. De standaardconfiguraties voor istiod en de gateways zijn:

  • Minimale replica's: 2
  • Maximum aantal replica's: 5
  • CPU-gebruik: 80%

Notitie

Om conflicten met de PodDisruptionBudgetinvoegtoepassing te voorkomen, staat de invoegtoepassing het instellen van de onder de minReplicas initiële standaardwaarde niet 2toe.

Hier volgen de istiod HPA-resources voor de gateway en inkomend verkeer:

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

De HPA-configuratie kan worden gewijzigd via patches en directe bewerkingen. Voorbeeld:

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

Servicevermelding

Met de aangepaste resourcedefinitie van Istio serviceEntry kunnen andere services worden toegevoegd aan het interne serviceregister van Istio. Met Een ServiceEntry kunnen services die al in de mesh aanwezig zijn, de opgegeven services routeren of openen. De configuratie van meerdere ServiceEntries met het resolution veld dat is ingesteld op DNS kan echter een zware belasting veroorzaken op DNS-servers (Domain Name System). Met de volgende suggesties kunt u de belasting verminderen:

  • Schakel over om resolution: NONE dns-zoekacties voor proxy's volledig te voorkomen. Geschikt voor de meeste gebruiksvoorbeelden.
  • Verhoog TTL (Time To Live) als u bepaalt dat de domeinen worden omgezet.
  • Beperk het bereik ServiceEntry met exportTo.