Wydajność i skalowanie dodatku Istio service mesh

Dodatek sieci usług oparty na Istio jest logicznie podzielony na płaszczyznę sterowania (istiod) i płaszczyznę danych. Płaszczyzna danych składa się z serwerów proxy Envoy sidecar wewnątrz podów obciążeń. Program Istiod zarządza tymi serwerami proxy usługi Envoy i konfiguruje je. W tym artykule przedstawiono wydajność zarówno płaszczyzny sterowania, jak i płaszczyzny danych dla wersji asm-1-19, w tym zużycie zasobów, pojemność sidecara i narzut opóźnienia. Ponadto zawiera sugestie dotyczące potencjalnego obciążenia zasobów w okresach dużego obciążenia. W tym artykule opisano również sposób dostosowywania skalowania dla płaszczyzny sterowania i bram.

Wydajność płaszczyzny sterowania

Wymagania dotyczące procesora CPU i pamięci istiod są skorelowane z częstotliwością wdrażania i zmian konfiguracji oraz liczbą połączonych proxy. Przetestowane scenariusze to:

• Współczynnik zmian zasobników: analizuje wpływ zmian zasobników na istiod. Aby zmniejszyć zmienne, tylko jedna usługa jest używana dla wszystkich przyczepek.
• Wiele usług: sprawdza wpływ wielu usług na maksymalną liczbę sidecarów, którymi Istiod może zarządzać (pojemność sidecarów), gdzie każda usługa ma N sidecarów, co łącznie składa się na całościową maksymalną pojemność.

Specyfikacje testów

• Jedno istiod wystąpienie z ustawieniami domyślnymi
• Automatyczne skalowanie zasobników w poziomie jest wyłączone
• Przetestowano przy użyciu dwóch wtyczek sieciowych: nakładka interfejsu Azure Container Networking Interface (CNI) Overlay i nakładka Azure CNI Overlay z Cilium (zalecane wtyczki sieciowe dla dużych klastrów)
• Jednostka SKU węzła: Standardowa D16 v3 (16 procesorów wirtualnych, 64 GB pamięci)
• Wersja platformy Kubernetes: 1.28.5
• Poprawka Istio: asm-1-19

Zmiana podów

Framework ClusterLoader2 został użyty do określenia maksymalnej liczby sidecarów, którymi Istiod może zarządzać podczas intensywnej zmiany sidecarów. Procent zmian sidecarów jest definiowany jako procent sidecarów obniżonych/podniesionych podczas testu. Na przykład 50% rotacji dla 10 000 przyczepek oznaczałoby, że 5 000 przyczepek zostało wymienionych na nowe, a następnie 5 000 przyczepek wróciło do użytku. Przetestowane wskaźniki churnu zostały określone na podstawie typowego procentu churnu podczas wdrażania (maxUnavailable). Wskaźnik rezygnacji został obliczony przez określenie całkowitej liczby przeprocesowanych przyczepek (w górę i w dół) w rzeczywistym czasie potrzebnym do ukończenia procesu obrotu.

Pojemność sidecara i procesor oraz pamięć Istiod

Nakładka usługi Azure CNI

Nakładka CNI platformy Azure z funkcją Cilium

Wiele usług

Struktura ClusterLoader2 została użyta do określenia maksymalnej liczby przyczepek istiod , którymi można zarządzać za pomocą 1000 usług. Wyniki można porównać z testem 0% churn (jedna usługa) w scenariuszu churn podów. Każda usługa miała N przyczepki przyczyniające się do ogólnej maksymalnej liczby przyczepek. Zaobserwowano zużycie zasobów serwera API, aby określić, czy dodatek spowodował znaczące obciążenie.

Pojemność przyczepki

Procesor i pamięć

Wydajność płaszczyzny danych

Różne czynniki wpływają na wydajność sidecar, takie jak rozmiar żądania, liczba wątków roboczych serwera proxy oraz liczba połączeń z klientem. Ponadto każde żądanie przepływające przez siatkę przechodzi przez serwer proxy po stronie klienta, a następnie serwer proxy po stronie serwera. W związku z tym opóźnienia i zużycie zasobów są mierzone w celu określenia wydajności płaszczyzny danych.

Obciążenie zostało utworzone przy użyciu Fortio. Test został przeprowadzony za pomocą repozytorium testów porównawczych Istio, które zostało zmodyfikowane do użycia z dodatkiem.

Specyfikacje testów

• Przetestowano przy użyciu dwóch wtyczek sieciowych: nakładki CNI platformy Azure i nakładki usługi Azure CNI z funkcją Cilium (zalecane wtyczki sieciowe dla klastrów na dużą skalę)
• Jednostka SKU węzła: Standardowa D16 v5 (16 procesorów wirtualnych, 64 GB pamięci)
• Wersja platformy Kubernetes: 1.28.5
• Dwaj pracownicy proxy
• Ładunek 1 KB
• 1000 zapytań na sekundę (QPS) w różnych połączeniach klientów
• http/1.1 protokół oraz włączono wzajemny protokół TLS (Transport Layer Security)
• Zebrane 26 punktów danych

Procesor i pamięć

Użycie pamięci i procesora CPU zarówno dla klienta, jak i serwera proxy przy 16 połączeniach klienckich i 1000 żądań na sekundę (QPS) we wszystkich scenariuszach wtyczek sieciowych wynosi około 0,4 vCPU i 72 MB.

Opóźnienie

Serwer proxy usługi Envoy przyczepki zbiera nieprzetworzone dane telemetryczne po odpowiedzi na klienta, co nie ma bezpośredniego wpływu na całkowity czas przetwarzania żądania. Jednak ten proces opóźnia rozpoczęcie obsługi następnego żądania, przyczyniając się do czasu oczekiwania w kolejce i wpływając na średnie i końcowe opóźnienia. W zależności od wzorca ruchu rzeczywiste opóźnienie ogona różni się.

Poniższe wyniki oceniają wpływ dodawania serwerów proxy przyczepki do ścieżki danych, pokazując opóźnienie P90 i P99.

• Ścieżka ruchu przyczepki: klient -> client-sidecar --> server-sidecar --> server
• Ścieżka bazowa ruchu: klient —> serwer

Porównanie wydajności opóźnienia płaszczyzny danych w dodatku Istio i wersjach usługi AKS można znaleźć tutaj.

Nakładka Azure CNI	Nakładka usługi Azure CNI z Cilium

Skalowanie

Dostosowywanie automatycznego poziomego skalowania poda

Skalowanie automatyczne zasobników w poziomie (HPA) jest włączone dla wdrożeń bram wejścia/wyjścia. Domyślne konfiguracje dla istiod i bram są następujące:

• Minimalna liczba replik: 2
• Maksymalna liczba replik: 5
• Wykorzystanie procesora CPU: 80%

Poniżej przedstawiono zasoby HPA bramy wejściowej i wejścia: istiod

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

Konfigurację HPA można modyfikować za pomocą poprawek i bezpośrednich edycji. Przykład:

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

Wprowadzenie usługi

Definicja niestandardowego zasobu Istio ServiceEntry umożliwia dodawanie innych usług do wewnętrznego rejestru usług Istio. ServiceEntry umożliwia usługom już w sieci kierowanie lub uzyskiwanie dostępu do określonych usług. Jednak konfiguracja wielu obiektów ServiceEntries z polem ustawionym resolution na dns może spowodować duże obciążenie serwerów systemu nazw domen (DNS). Następujące sugestie mogą pomóc zmniejszyć obciążenie:

• Przełącz się na resolution: NONE, aby całkowicie uniknąć wyszukiwania DNS przy użyciu proxy. Nadaje się do większości przypadków użycia. Jednak w przypadku korzystania z bramy ruchu wychodzącego dodatku Istio rozwiązanie ServiceEntry musi mieć wartość DNS.
• Zwiększ TTL (czas życia), jeśli kontrolujesz rozpoznawane domeny.
• Ogranicz zakres ServiceEntry za pomocą polecenia exportTo.