Zestawienie zużycia CPU dla Istio i Linkerd

Wprowadzenie

My w Shopify rozpoczęliśmy wdrażanie Istio jako service mesh. Generalnie wszystko nam odpowiada, z wyjątkiem jednej rzeczy: to kosztuje dużo.

W publikowanych benchmarkach dla Istio mówi się:

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

Dla pierwszego regionu w service mesh (po 2 proxy z każdej strony połączenia) będziemy potrzebować 1200 rdzeni tylko dla proxy, zakładając jeden milion żądań na sekundę. Zgodnie z kalkulatorem kosztów od Google wychodzi około 40$/miesiąc/rdzeń dla konfiguracji n1-standard-64, co oznacza, że ten region będzie nas kosztować ponad 50 tys. dolarów miesięcznie za 1 milion żądań na sekundę.

Ivan Sim (Ivan Sim) wizualnie porównał opóźnienia service mesh w zeszłym roku i obiecał to samo dla pamięci i procesora, ale się nie udało:

Wygląda na to, że values-istio-test.yaml poważnie zwiększy wykorzystanie procesora. Jeśli dobrze to policzyłem, potrzebuję około 24 rdzeni procesora dla panelu sterowania i 0,5 CPU dla każdego proxy. Nie mam tyle. Powtórzę testy, kiedy przydzielą mi więcej zasobów.

Chciałem sam się przekonać, jak wskaźniki Istio mają się do innej service mesh z otwartym kodem: Linkerd.

Instalacja service mesh

Na początku zainstalowałem w klastrze SuperGloo:

$ supergloo init
instalacja supergloo w wersji 0.3.12
używając chart uri https://storage.googleapis.com/supergloo-helm/charts/supergloo-0.3.12.tgz
configmap/sidecar-injection-resources utworzony
serviceaccount/supergloo utworzony
serviceaccount/discovery utworzony
serviceaccount/mesh-discovery utworzony
clusterrole.rbac.authorization.k8s.io/discovery utworzony
clusterrole.rbac.authorization.k8s.io/mesh-discovery utworzony
clusterrolebinding.rbac.authorization.k8s.io/supergloo-role-binding utworzony
clusterrolebinding.rbac.authorization.k8s.io/discovery-role-binding utworzony
clusterrolebinding.rbac.authorization.k8s.io/mesh-discovery-role-binding utworzony
deployment.extensions/supergloo utworzony
deployment.extensions/discovery utworzony
deployment.extensions/mesh-discovery utworzony
instalacja zakończona sukcesem!

Użyłem SuperGloo, ponieważ znacznie ułatwia on wstępne wdrażanie service mesh. Prawie nic nie musiałem robić. W produkcji nie korzystamy z SuperGloo, ale do tego zadania jest idealny. Musiałem wydać dosłownie kilka poleceń dla każdej service mesh. Użyłem dwóch klastrów do izolacji - po jednym dla Istio i Linkerd.

Eksperyment przeprowadzono na Google Kubernetes Engine. Użyłem Kubernetes 1.12.7-gke.7 i puli węzłów n1-standard-4 z automatycznym skalowaniem węzłów (minimum 4, maksimum 16).

Następnie zainstalowałem obie service mesh z linii poleceń.

Na początku 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, a następnie pulpit nawigacyjny stabilizował się.

(Uwaga. SuperGloo obsługuje obecnie tylko Istio 1.0.x. Powtórzyłem eksperyment z Istio 1.1.3, ale nie zauważyłem żadnych znaczących różnic.)

Konfiguracja automatycznego wprowadzania Istio

Aby Istio zainstalowało sidecar Envoy, używamy wstrzykiwacza sidecar — MutatingAdmissionWebhook. Nie będziemy o nim mówić w tym artykule. Powiem tylko, że to kontroler, który monitoruje dostęp do wszystkich nowych podów i dynamicznie dodaje sidecar i initContainer, który odpowiada za zadania iptables.

W Shopify napisaliśmy własny kontroler dostępu do wprowadzenia sidecarów, ale w tym benchmarku wziąłem kontroler, który jest dostarczany z Istio. Domyślny kontroler wprowadza sidecary, gdy w przestrzeni nazw jest etykieta 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

Konfiguracja automatycznego wprowadzania Linkerd

Aby skonfigurować wprowadzenie sidecarów Linkerd, używamy adnotacji (dodałem je ręcznie przez 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 odporności Istio

Stworzyliśmy symulator odporności Istio, aby eksperymentować z ruchem specyficznym dla Shopify. Potrzebowaliśmy narzędzia, które pozwoliłoby nam tworzyć dowolną topologię, reprezentującą określoną część grafu naszych usług z dynamicznymi ustawieniami do modelowania konkretnych obciążeń roboczych.

Infrastruktura Shopify doświadcza dużych obciążeń podczas flash sale. W tym czasie Shopify zaleca sprzedawcom częstsze organizowanie takich wyprzedaży. Duzi klienci czasami informują o planowanej flash sale. Inni przeprowadzają je niespodziewanie, o każdej porze dnia i nocy.

Chcieliśmy, aby nasz symulator odporności modelował przepływy robocze, które odpowiadają topologiom i obciążeniom, które w przeszłości prowadziły do przeciążenia infrastruktury Shopify. Głównym celem zastosowania service mesh jest zapewnienie niezawodności i odporności na poziomie sieci, a dla nas istotne jest, aby service mesh skutecznie radziła sobie z obciążeniami, które wcześniej zakłócały działanie usług.

Na bazie symulatora odporności znajduje się węzeł roboczy, który działa jako węzeł service mesh. Węzeł roboczy można skonfigurować statycznie przy uruchamianiu lub dynamicznie przez REST API. Używamy dynamicznej konfiguracji węzłów roboczych do tworzenia przepływów roboczych w formie regresywnych testów.

Oto przykład takiego procesu:

• Uruchamiamy 10 serwerów jako bar usługę, która zwraca odpowiedź 200 / OK po 100 ms.
• Uruchamiamy 10 klientów — każdy wysyła 100 zapytań na sekundę do bar.
• Co 10 sekund usuwamy 1 serwer, monitorujemy błędy 5xx po stronie klienta.

Na koniec procesu roboczego analizujemy logi i metryki oraz sprawdzamy, czy test został zaliczony. W ten sposób dowiadujemy się o wydajności naszej service mesh i przeprowadzamy regresyjny test, aby sprawdzić nasze założenia o odporności na awarie.

(Uwaga. Rozważamy otwarcie kodu źródłowego symulatora odporności Istio, ale jeszcze nie jesteśmy na to gotowi.)

Symulator odporności Istio do benchmarking service mesh

Konfigurujemy kilka węzłów roboczych symulatora:

• irs-client-loadgen: 3 repliki, które wysyłają po 100 zapytań na sekundę do irs-client.
• irs-client: 3 repliki, które otrzymują zapytanie, czekają 100 ms i przekierowują zapytanie do irs-server.
• irs-server: 3 repliki, które zwracają 200 / OK po 100 ms.

Z taką konfiguracją możemy zmierzyć stabilny przepływ ruchu między 9 punktami końcowymi. Sidecar-y w irs-client-loadgen i irs-server otrzymują po 100 zapytań na sekundę, a irs-client — 200 (przychodzących i wychodzących).

Monitorujemy użycie zasobów przez DataDog, ponieważ nie mamy klastra Prometheus.

Wyniki

Panele zarządzania

Najpierw zbadaliśmy zużycie CPU.

Panel sterowania Linkerd ~22 miliardy

Panel sterowania Istio: ~750 miliardów

Panel sterowania Istio używa około 35 razy więcej zasobów procesora, niż Linkerd. Oczywiście wszystko jest ustawione domyślnie, a wiele zasobów procesora pochłania istio-telemetry (można to wyłączyć, rezygnując z niektórych funkcji). Nawet jeśli usuniemy ten komponent, i tak otrzymujemy ponad 100 miliardów, czyli 4 razy więcej, niż w przypadku Linkerd.

Proxy sidecar

Następnie sprawdziliśmy użycie proxy. Powinno tu być liniowe zależność od liczby zapytań, ale dla każdego sidecara istnieją pewne koszty ukryte, które wpływają na krzywą.

Linkerd: ~100 miliardów dla irs-client, ~50 miliardów dla irs-client-loadgen

Wyniki wyglądają logicznie, ponieważ proxy client otrzymuje dwa razy więcej ruchu, niż proxy loadgen: na każde wychodzące zapytanie od loadgen przypada jedno przychodzące i jedno wychodzące.

Istio/Envoy: ~155 miliardów dla irs-client, ~75 miliardów dla irs-client-loadgen

Widzimy podobne wyniki dla sidecarów Istio.

Jednak ogólnie proxy Istio/Envoy zużywa około 50% więcej zasobów procesora, niż Linkerd.

Podobny schemat widzimy po stronie serwera:

Linkerd: ~50 miliardów dla irs-server

Istio/Envoy: ~80 miliardów dla irs-server

Po stronie serwera sidecar Istio/Envoy zużywa około 60% więcej zasobów procesora, niż Linkerd.

Podsumowanie

Proxy Istio Envoy zużywa o 50+% więcej CPU, niż Linkerd, w naszej symulowanej obciążeniach pracy. Panel sterowania Linkerd zużywa znacznie mniej zasobów, niż Istio, szczególnie w odniesieniu do głównych komponentów.

Wciąż myślimy, jak zredukować te koszty. Jeśli masz jakieś pomysły, podziel się!

Źródło: habr.com