CPU მოხმარების საორიენტაციო მაჩვენებელი Istio-სთვის და Linkerd-ისთვის

შესავალი

ჩვენ ვართ შემოსული Shopify დაიწყო ისტიოს, როგორც სერვისის ქსელის დანერგვა. პრინციპში, ყველაფერი კარგადაა, გარდა ერთისა: ეს ძვირია.

В გამოქვეყნებული ეტალონები ისტიოსთვის ნათქვამია:

Istio 1.1-ით, პროქსი მოიხმარს დაახლოებით 0,6 vCPU-ს (ვირტუალურ ბირთვს) 1000 მოთხოვნაზე წამში.

სერვისის ქსელის პირველი რეგიონისთვის (კავშირის თითოეულ მხარეს 2 პროქსი), გვექნება 1200 ბირთვი მხოლოდ პროქსისთვის, წამში ერთი მილიონი მოთხოვნის სიჩქარით. Google-ის ხარჯების კალკულატორის მიხედვით, კონფიგურაციისთვის ის დაახლოებით 40$/თვეში/ძირში გამოდის. n1-standard-64, ანუ მარტო ეს რეგიონი წამში 50 მილიონი მოთხოვნით თვეში 1 ათას დოლარზე მეტი დაგვიჯდება.

ივან სიმ (ივან სიმ) ვიზუალურად შედარება სერვისის ბადე შარშან შეფერხდა და იგივე დაპირდა მეხსიერების და პროცესორისთვის, მაგრამ არ გამოვიდა:

როგორც ჩანს, values-istio-test.yaml სერიოზულად გაზრდის CPU-ს მოთხოვნებს. თუ სწორად გავაკეთე მათემატიკა, გჭირდებათ დაახლოებით 24 CPU ბირთვი მართვის პანელისთვის და 0,5 CPU თითოეული პროქსისთვის. ამდენი არ მაქვს. გავიმეორებ ტესტებს, როცა მეტი რესურსი გამომიყოფს.

მინდოდა მენახა, რამდენად ჰგავს Istio-ს შესრულება სხვა ღია კოდის სერვისის ქსელს: ლინკერდი.

სერვისის ბადის მონტაჟი

პირველ რიგში დავაინსტალირე კლასტერში 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!

მე გამოვიყენე SuperGloo, რადგან ეს აადვილებს სერვისის ქსელის ჩატვირთვას. ბევრის გაკეთება არ მომიწია. ჩვენ არ ვიყენებთ SuperGloo-ს წარმოებაში, მაგრამ იდეალურია ასეთი ამოცანისთვის. მე მომიწია სიტყვასიტყვით რამდენიმე ბრძანების გამოყენება თითოეული სერვისის ქსელისთვის. იზოლაციისთვის გამოვიყენე ორი კლასტერი - თითო ისტიოსთვის და ლინკერდისთვის.

ექსპერიმენტი ჩატარდა Google Kubernetes Engine-ზე. მე გამოვიყენე Kubernetes 1.12.7-gke.7 და კვანძების აუზი n1-standard-4 კვანძის ავტომატური მასშტაბით (მინიმუმ 4, მაქსიმუმ 16).

შემდეგ დავაყენე ორივე სერვისის ქსელი ბრძანების ხაზიდან.

პირველი ლინკერდი:

$ 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 |
+---------+--------------+---------+---------------------------+

შემდეგ ისტიო:

$ 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      |
+---------+------------+---------+---------------------------+

Crash-loop-ს რამდენიმე წუთი დასჭირდა, შემდეგ კი მართვის პანელები დასტაბილურდა.

(შენიშვნა: SuperGloo მხარს უჭერს მხოლოდ Istio 1.0.x-ს. მე გავიმეორე ექსპერიმენტი Istio 1.1.3-ით, მაგრამ შესამჩნევი განსხვავება ვერ შევამჩნიე.)

Istio Automatic Deployment-ის დაყენება

იმისათვის, რომ Istio-მ დააინსტალიროს გვერდითი კარის Envoy, ჩვენ ვიყენებთ გვერდითი კარის ინჟექტორს − MutatingAdmissionWebhook. ამ სტატიაში ამაზე არ ვისაუბრებთ. ნება მომეცით უბრალოდ ვთქვა, რომ ეს არის კონტროლერი, რომელიც აკონტროლებს ყველა ახალ პოდზე წვდომას და დინამიურად ამატებს sidecar-ს და initContainer-ს, რომელიც პასუხისმგებელია ამოცანებზე. iptables.

ჩვენ Shopify-ში დავწერეთ ჩვენი საკუთარი წვდომის კონტროლერი გვერდითი კარების განსახორციელებლად, მაგრამ ამ ნიშნისთვის მე გამოვიყენე კონტროლერი, რომელიც მოყვება Istio-ს. კონტროლერი ნაგულისხმევად აყენებს გვერდითა კარებს, როდესაც სახელთა სივრცეში არის მალსახმობი 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

Linkerd-ის ავტომატური განლაგების დაყენება

Linkerd sidecar embedding-ის დასაყენებლად, ჩვენ ვიყენებთ ანოტაციებს (მე დავამატე ხელით 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

Istio შეცდომის ტოლერანტობის სიმულატორი

ჩვენ შევქმენით ხარვეზების შემწყნარებლობის სიმულატორი სახელწოდებით Istio, რათა ექსპერიმენტი ჩაატაროთ Shopify-სთვის უნიკალური ტრაფიკით. ჩვენ გვჭირდებოდა ინსტრუმენტი, რათა შეგვექმნა მორგებული ტოპოლოგია, რომელიც წარმოადგენდა ჩვენი სერვისის გრაფიკის კონკრეტულ ნაწილს, დინამიურად კონფიგურირებული კონკრეტული სამუშაო დატვირთვის მოდელირებისთვის.

Shopify-ის ინფრასტრუქტურა დიდი დატვირთვის ქვეშ იმყოფება ფლეშ გაყიდვების დროს. ამავე დროს, Shopify გამყიდველებს ურჩევს ასეთი გაყიდვების უფრო ხშირად ჩატარებას. მსხვილი მომხმარებლები ზოგჯერ აფრთხილებენ დაგეგმილი ფლეშ გაყიდვის შესახებ. სხვები მათ მოულოდნელად ატარებენ ჩვენთვის დღის ან ღამის ნებისმიერ დროს.

ჩვენ გვინდოდა, რომ ჩვენს გამძლეობის სიმულატორს შეექმნა სამუშაო ნაკადების მოდელირება, რომელიც ემთხვევა ტოპოლოგიებსა და დატვირთვებს, რომლებიც წარსულში აჭარბებდა Shopify-ის ინფრასტრუქტურას. სერვისის ქსელის გამოყენების მთავარი მიზანი არის ის, რომ ჩვენ გვჭირდება საიმედოობა და შეცდომების ტოლერანტობა ქსელის დონეზე და ჩვენთვის მნიშვნელოვანია, რომ სერვისის ბადე ეფექტურად გაუმკლავდეს დატვირთვას, რომელიც ადრე არღვევდა სერვისებს.

ხარვეზების ტოლერანტობის სიმულატორის გულში არის მუშა კვანძი, რომელიც მოქმედებს როგორც სერვისული ქსელის კვანძი. მუშა კვანძის კონფიგურაცია შესაძლებელია სტატიკურად გაშვებისას ან დინამიურად REST API-ის მეშვეობით. ჩვენ ვიყენებთ მუშათა კვანძების დინამიურ კონფიგურაციას სამუშაო ნაკადების შესაქმნელად რეგრესიული ტესტების სახით.

აქ არის ასეთი პროცესის მაგალითი:

• ჩვენ გავუშვით 10 სერვერი, როგორც bar სერვისი, რომელიც აბრუნებს პასუხს 200/OK 100 ms-ის შემდეგ.
• ჩვენ გავუშვით 10 კლიენტი - თითოეული აგზავნის 100 მოთხოვნას წამში bar.
• ყოველ 10 წამში ჩვენ ვშლით 1 სერვერის და მონიტორინგის შეცდომებს 5xx კლიენტზე.

სამუშაო პროცესის დასასრულს, ჩვენ განვიხილავთ ჟურნალებს და მეტრიკას და ვამოწმებთ, ჩააბარა თუ არა ტესტი. ამ გზით ჩვენ ვსწავლობთ ჩვენი სერვისული ქსელის მუშაობის შესახებ და ვაწარმოებთ რეგრესიის ტესტს, რათა შევამოწმოთ ჩვენი ვარაუდები შეცდომების ტოლერანტობის შესახებ.

(შენიშვნა: ჩვენ ვფიქრობთ Istio ხარვეზების ტოლერანტობის სიმულატორის ღია წყაროს მიღებაზე, მაგრამ ჯერ არ ვართ მზად ამისათვის.)

Istio ხარვეზების ტოლერანტობის სიმულატორი მომსახურების ქსელის საორიენტაციო ნიშნისთვის

ჩვენ დავაყენეთ სიმულატორის რამდენიმე სამუშაო კვანძი:

• irs-client-loadgen: 3 რეპლიკა, რომელიც აგზავნის 100 მოთხოვნას წამში irs-client.
• irs-client: 3 რეპლიკა, რომლებიც იღებენ მოთხოვნას, დაელოდეთ 100 ms და გაგზავნეთ მოთხოვნა irs-server.
• irs-server: 3 ასლი, რომელიც ბრუნდება 200/OK 100 ms-ის შემდეგ.

ამ კონფიგურაციით ჩვენ შეგვიძლია გავზომოთ სტაბილური მოძრაობის ნაკადი 9 ბოლო წერტილს შორის. გვერდითი მანქანები irs-client-loadgen и irs-server მიიღეთ 100 მოთხოვნა წამში და irs-client — 200 (შემავალი და გამავალი).

ჩვენ თვალყურს ვადევნებთ რესურსების გამოყენებას მონაცემთა ძაღლირადგან ჩვენ არ გვაქვს პრომეთეს მტევანი.

დასკვნები

საკონტროლო პანელები

პირველ რიგში, ჩვენ განვიხილეთ პროცესორის მოხმარება.

Linkerd მართვის პანელი ~22 მილიკორი

Istio მართვის პანელი: ~750 მილიკორი

Istio მართვის პანელი იყენებს დაახლოებით 35-ჯერ მეტი CPU რესურსივიდრე ლინკერდი. რა თქმა უნდა, ყველაფერი ნაგულისხმევად არის დაინსტალირებული და istio-telemetry აქ მოიხმარს პროცესორის უამრავ რესურსს (ის შეიძლება გამორთოთ ზოგიერთი ფუნქციის გამორთვით). თუ ამ კომპონენტს ამოვიღებთ, მაინც მივიღებთ 100 მილიკორზე მეტს, ანუ 4-ჯერ მეტივიდრე ლინკერდი.

Sidecar პროქსი

შემდეგ ჩვენ გამოვცადეთ პროქსის გამოყენება. უნდა არსებობდეს ხაზოვანი კავშირი მოთხოვნების რაოდენობასთან, მაგრამ თითოეული გვერდითი კარისთვის არის გარკვეული ზედნადები, რომელიც გავლენას ახდენს მრუდზე.

ლინკერდი: ~100 მილიკორი irs-client-ისთვის, ~50 მილიკორი irs-client-loadgen-ისთვის

შედეგები ლოგიკურად გამოიყურება, რადგან კლიენტის პროქსი იღებს ორჯერ მეტ ტრაფიკს, ვიდრე loadgen პროქსი: loadgen-ის ყოველ გამავალ მოთხოვნაზე კლიენტს აქვს ერთი შემომავალი და ერთი გამავალი.

Istio/Envoy: ~ 155 მილიკორი irs-client-ისთვის, ~75 millicore for irs-client-loadgen

ჩვენ ვხედავთ მსგავს შედეგებს Istio sidecars-ისთვის.

მაგრამ ზოგადად, ისტიო/ელჩის მარიონეტები მოიხმარენ დაახლოებით 50% მეტი CPU რესურსივიდრე ლინკერდი.

ჩვენ ვხედავთ იგივე სქემას სერვერის მხარეს:

ლინკერდი: ~50 მილიკორი irs-სერვერისთვის

Istio/Envoy: ~80 მილიკორი irs-სერვერისთვის

სერვერის მხარეს, sidecar Istio/Envoy მოიხმარს დაახლოებით 60% მეტი CPU რესურსივიდრე ლინკერდი.

დასკვნა

Istio Envoy პროქსი მოიხმარს 50+% მეტ CPU-ს, ვიდრე Linkerd-ს ჩვენი სიმულირებული დატვირთვის დროს. Linkerd პანელი მოიხმარს გაცილებით ნაკლებ რესურსს, ვიდრე ისტიო, განსაკუთრებით ძირითადი კომპონენტებისთვის.

ჩვენ ჯერ კიდევ ვფიქრობთ, როგორ შევამციროთ ეს ხარჯები. თუ თქვენ გაქვთ იდეები, გთხოვთ გააზიაროთ!

წყარო: www.habr.com