Test porównawczy zużycia procesora dla Istio i Linkerd

Wprowadzenie

Jesteśmy w Shopify rozpoczęło wdrażanie Istio jako siatki usług. W zasadzie wszystko jest w porządku, z wyjątkiem jednej rzeczy: to jest drogie.

В opublikowanych benchmarków w przypadku Istio jest napisane:

W Istio 1.1 serwer proxy zużywa około 0,6 vCPU (rdzeni wirtualnych) na 1000 żądań na sekundę.

Dla pierwszego regionu w siatce usług (2 serwery proxy po każdej stronie połączenia) będziemy mieli 1200 rdzeni tylko dla serwera proxy, z szybkością miliona żądań na sekundę. Według kalkulatora kosztów Google konfiguracja kosztuje około 40 USD miesięcznie na rdzeń n1-standard-64, czyli sam ten region będzie nas kosztować ponad 50 tysięcy dolarów miesięcznie za 1 milion żądań na sekundę.

Iwan Sim (Iwan Sim) wizualnie porównane Service Mesh opóźniał się w zeszłym roku i obiecał to samo dla pamięci i procesora, ale nie wyszło:

Najwyraźniej wartości-istio-test.yaml poważnie zwiększą żądania procesora. Jeśli dobrze obliczyłem, potrzebujesz około 24 rdzeni procesora na panel sterowania i 0,5 procesora na każdy serwer proxy. Nie mam tyle. Testy powtórzę, gdy przydzielą mi więcej zasobów.

Chciałem na własne oczy przekonać się, jak podobna jest wydajność Istio do innej siatki usług open source: Linkerda.

Montaż siatki serwisowej

Przede wszystkim zainstalowałem go w klastrze SuperGloo:

$ supergloo init
installing supergloo version 0.3.12
using chart uri https://storage.googleapis.com/supergloo-helm/charts/supergloo-0.3.12.tgz
configmap/sidecar-injection-resources created
serviceaccount/supergloo created
serviceaccount/discovery created
serviceaccount/mesh-discovery created
clusterrole.rbac.authorization.k8s.io/discovery created
clusterrole.rbac.authorization.k8s.io/mesh-discovery created
clusterrolebinding.rbac.authorization.k8s.io/supergloo-role-binding created
clusterrolebinding.rbac.authorization.k8s.io/discovery-role-binding created
clusterrolebinding.rbac.authorization.k8s.io/mesh-discovery-role-binding created
deployment.extensions/supergloo created
deployment.extensions/discovery created
deployment.extensions/mesh-discovery created
install successful!

Użyłem SuperGloo, ponieważ znacznie ułatwia ładowanie siatki usług. Nie musiałem wiele robić. Nie używamy SuperGloo w produkcji, ale do takiego zadania jest on idealny. Musiałem użyć dosłownie kilku poleceń dla każdej siatki usług. Do izolacji użyłem dwóch klastrów - po jednym dla Istio i Linkerd.

Eksperyment został przeprowadzony na Google Kubernetes Engine. Korzystałem z Kubernetesa 1.12.7-gke.7 i pulę węzłów n1-standard-4 z automatycznym skalowaniem węzłów (minimum 4, maksymalnie 16).

Następnie zainstalowałem obie siatki usług z wiersza poleceń.

Pierwszy Linkerd:

$ supergloo install linkerd --name linkerd
+---------+--------------+---------+---------------------------+
| INSTALL |     TYPE     | STATUS  |          DETAILS          |
+---------+--------------+---------+---------------------------+
| linkerd | Linkerd Mesh | Pending | enabled: true             |
|         |              |         | version: stable-2.3.0     |
|         |              |         | namespace: linkerd        |
|         |              |         | mtls enabled: true        |
|         |              |         | auto inject enabled: true |
+---------+--------------+---------+---------------------------+

Następnie Istio:

$ supergloo install istio --name istio --installation-namespace istio-system --mtls=true --auto-inject=true
+---------+------------+---------+---------------------------+
| INSTALL |    TYPE    | STATUS  |          DETAILS          |
+---------+------------+---------+---------------------------+
| istio   | Istio Mesh | Pending | enabled: true             |
|         |            |         | version: 1.0.6            |
|         |            |         | namespace: istio-system   |
|         |            |         | mtls enabled: true        |
|         |            |         | auto inject enabled: true |
|         |            |         | grafana enabled: true     |
|         |            |         | prometheus enabled: true  |
|         |            |         | jaeger enabled: true      |
+---------+------------+---------+---------------------------+

Pętla awarii trwała kilka minut, po czym panele sterowania się ustabilizowały.

(Uwaga: SuperGloo na razie obsługuje tylko Istio 1.0.x. Powtórzyłem eksperyment z Istio 1.1.3, ale nie zauważyłem żadnej zauważalnej różnicy.)

Konfigurowanie automatycznego wdrażania Istio

Aby Istio zainstalował wózek boczny Envoy, używamy wtryskiwacza wózka bocznego − MutatingAdmissionWebhook. Nie będziemy o tym rozmawiać w tym artykule. Powiem tylko, że jest to kontroler, który monitoruje dostęp wszystkich nowych podów i dynamicznie dodaje sidecar oraz initContainer, który odpowiada za zadania iptables.

W Shopify napisaliśmy własny kontroler dostępu do implementacji wózków bocznych, ale w tym teście porównawczym użyłem kontrolera dołączonego do Istio. Kontroler domyślnie dodaje przyczepki, gdy w przestrzeni nazw znajduje się skrót istio-injection: enabled:

$ kubectl label namespace irs-client-dev istio-injection=enabled
namespace/irs-client-dev labeled

$ kubectl label namespace irs-server-dev istio-injection=enabled
namespace/irs-server-dev labeled

Konfigurowanie automatycznego wdrożenia Linkerd

Aby skonfigurować osadzanie przyczepki bocznej Linkerd, używamy adnotacji (dodałem je ręcznie za pomocą kubectl edit):

metadata:
  annotations:
    linkerd.io/inject: enabled

$ k edit ns irs-server-dev 
namespace/irs-server-dev edited

$ k get ns irs-server-dev -o yaml
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    linkerd.io/inject: enabled
  name: irs-server-dev
spec:
  finalizers:
  - kubernetes
status:
  phase: Active

Symulator tolerancji błędów Istio

Zbudowaliśmy symulator odporności na błędy o nazwie Istio, aby eksperymentować z ruchem unikalnym dla Shopify. Potrzebowaliśmy narzędzia do utworzenia niestandardowej topologii, która reprezentowałaby określoną część naszego wykresu usług, dynamicznie skonfigurowanego do modelowania określonych obciążeń.

Infrastruktura Shopify jest pod dużym obciążeniem podczas sprzedaży flash. W tym samym czasie Shopify zaleca sprzedawcom częstsze organizowanie takich wyprzedaży. Duzi klienci czasami ostrzegają przed planowaną wyprzedażą błyskawiczną. Inni przeprowadzają je niespodziewanie dla nas o każdej porze dnia i nocy.

Chcieliśmy, aby nasz symulator odporności modelował przepływy pracy odpowiadające topologiom i obciążeniom, które w przeszłości przeciążały infrastrukturę Shopify. Głównym celem stosowania siatki usług jest to, że potrzebujemy niezawodności i odporności na awarie na poziomie sieci i ważne jest dla nas, aby siatka usług skutecznie radziła sobie z obciążeniami, które wcześniej zakłócały usługi.

Sercem symulatora odporności na błędy jest węzeł roboczy, który działa jako węzeł siatki usług. Węzeł roboczy można skonfigurować statycznie podczas uruchamiania lub dynamicznie za pośrednictwem interfejsu API REST. Do tworzenia przepływów pracy w formie testów regresyjnych wykorzystujemy dynamiczną konfigurację węzłów workera.

Oto przykład takiego procesu:

• Uruchamiamy 10 serwerów jako bar usługa, która zwraca odpowiedź 200/OK po 100 ms.
• Uruchamiamy 10 klientów - każdy wysyła do 100 żądań na sekundę bar.
• Co 10 sekund usuwamy 1 serwer i monitorujemy błędy 5xx na kliencie.

Na koniec przepływu pracy sprawdzamy logi i metryki oraz sprawdzamy, czy test przeszedł pomyślnie. W ten sposób dowiadujemy się o wydajności naszej siatki usług i przeprowadzamy test regresji, aby przetestować nasze założenia dotyczące odporności na błędy.

(Uwaga: zastanawiamy się nad udostępnieniem symulatora odporności na błędy Istio na zasadach open source, ale nie jesteśmy jeszcze na to gotowi.)

Symulator odporności na błędy Istio do testów porównawczych siatki usług

Skonfigurowaliśmy kilka węzłów roboczych symulatora:

• irs-client-loadgen: 3 repliki wysyłające 100 żądań na sekundę irs-client.
• irs-client: 3 repliki, które otrzymają żądanie, odczekaj 100 ms i przekaż żądanie do irs-server.
• irs-server: 3 repliki, które powracają 200/OK po 100 ms.

Dzięki tej konfiguracji możemy zmierzyć stabilny przepływ ruchu pomiędzy 9 punktami końcowymi. Wózki boczne w irs-client-loadgen и irs-server odbierać 100 żądań na sekundę i irs-client — 200 (przychodzące i wychodzące).

Śledzimy wykorzystanie zasobów poprzez DataDogponieważ nie mamy gromady Prometeusza.

wyniki

Panele sterowania

Najpierw sprawdziliśmy zużycie procesora.

Panel sterowania Linkerda ~22 milicore

Panel sterowania Istio: ~750 milicore

Panel sterowania Istio zużywa około 35 razy więcej zasobów procesoraniż Linkerd. Oczywiście wszystko jest instalowane domyślnie, a istio-telemetria pochłania tutaj sporo zasobów procesora (można to wyłączyć wyłączając niektóre funkcje). Jeśli usuniemy ten komponent, nadal otrzymamy ponad 100 milirdzeniowych 4 razy więcejniż Linkerd.

Serwer proxy bocznego

Następnie przetestowaliśmy użycie serwera proxy. Powinna istnieć liniowa zależność od liczby żądań, ale w przypadku każdego wózka bocznego występuje pewien narzut, który wpływa na krzywą.

Linkerd: ~100 millicores dla klienta irs, ~50 millicores dla irs-client-loadgen

Wyniki wydają się logiczne, ponieważ klient proxy otrzymuje dwa razy większy ruch niż serwer proxy Loadgen: na każde żądanie wychodzące z Loadgen klient ma jedno przychodzące i jedno wychodzące.

Istio/Envoy: ~155 milicores dla klienta irs, ~75 milicores dla irs-client-loadgen

Podobne wyniki obserwujemy w przypadku wózków bocznych Istio.

Ale ogólnie rzecz biorąc, proxy Istio/Envoy zużywają około 50% więcej zasobów procesoraniż Linkerd.

Ten sam schemat widzimy po stronie serwera:

Linkerd: ~50 millicore dla serwera irs

Istio/Envoy: ~80 milicore dla serwera irs

Po stronie serwera korzysta z wózka bocznego Istio/Envoy około 60% więcej zasobów procesoraniż Linkerd.

wniosek

Serwer proxy Istio Envoy zużywa o 50% więcej procesora niż Linkerd przy naszym symulowanym obciążeniu. Panel sterowania Linkerd zużywa znacznie mniej zasobów niż Istio, szczególnie w przypadku podstawowych komponentów.

Wciąż zastanawiamy się, jak te koszty obniżyć. Jeśli masz pomysły, podziel się nimi!

Źródło: www.habr.com