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 |
---|---|
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 PodDisruptionBudget
invoegtoepassing te voorkomen, staat de invoegtoepassing het instellen van de onder de minReplicas
initiële standaardwaarde niet 2
toe.
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}}'
Notitie
Zie de documentatie voor de upgrade van de Istio-invoegtoepassing voor meer informatie over hoe HPA-instellingen worden toegepast op beide revisies tijdens een canary-upgrade .
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
.
Azure Kubernetes Service