Istio आणि Linkerd साठी CPU वापर बेंचमार्क

परिचय

आम्ही मध्ये आहोत Shopify सेवा जाळी म्हणून Istio तैनात करण्यास सुरुवात केली. तत्वतः, एक गोष्ट वगळता सर्व काही ठीक आहे: ते महाग आहे.

В बेंचमार्क प्रकाशित केले Istio साठी ते म्हणते:

Istio 1.1 सह, प्रॉक्सी प्रति सेकंद प्रति 0,6 विनंत्या अंदाजे 1000 vCPUs (व्हर्च्युअल कोर) वापरते.

सर्व्हिस मेशमधील पहिल्या प्रदेशासाठी (कनेक्शनच्या प्रत्येक बाजूला 2 प्रॉक्सी), आमच्याकडे प्रति सेकंद एक दशलक्ष विनंत्या दराने फक्त प्रॉक्सीसाठी 1200 कोर असतील. Google च्या कॉस्ट कॅल्क्युलेटरनुसार, कॉन्फिगरेशनसाठी हे अंदाजे $40/महिना/कोर आहे n1-standard-64, म्हणजे, एकट्या या प्रदेशासाठी प्रति सेकंद 50 दशलक्ष विनंत्यांसाठी दरमहा 1 हजार डॉलर्सपेक्षा जास्त खर्च येईल.

इव्हान सिम (इव्हान सिम) दृष्यदृष्ट्या तुलना सर्व्हिस मेशने गेल्या वर्षी विलंब केला आणि मेमरी आणि प्रोसेसरसाठी तेच वचन दिले, परंतु ते कार्य करत नाही:

वरवर पाहता, values-istio-test.yaml CPU विनंत्या गंभीरपणे वाढवेल. मी माझे गणित बरोबर केले असल्यास, तुम्हाला नियंत्रण पॅनेलसाठी अंदाजे 24 CPU कोर आणि प्रत्येक प्रॉक्सीसाठी 0,5 CPU आवश्यक आहे. माझ्याकडे तेवढे काही नाही. जेव्हा मला अधिक संसाधने वाटप केली जातात तेव्हा मी चाचण्यांची पुनरावृत्ती करेन.

Istio ची कामगिरी दुसर्‍या ओपन सोर्स सर्व्हिस मेशशी किती समान आहे हे मला स्वतःला पहायचे होते: लिंकर्ड.

सेवा जाळी स्थापना

सर्व प्रथम, मी ते एका क्लस्टरमध्ये स्थापित केले सुपरग्लू:

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

मी सुपरग्लू वापरला कारण ते सर्व्हिस मेशचे बूटस्ट्रॅपिंग खूप सोपे करते. मला फार काही करावे लागले नाही. आम्ही उत्पादनात सुपरग्लू वापरत नाही, परंतु अशा कार्यासाठी ते आदर्श आहे. मला प्रत्येक सर्व्हिस मेशसाठी अक्षरशः दोन कमांड्स वापरावे लागले. मी पृथक्करणासाठी दोन क्लस्टर वापरले - प्रत्येकी एक Istio आणि Linkerd साठी.

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

मग 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      |
+---------+------------+---------+---------------------------+

क्रॅश-लूपला काही मिनिटे लागली आणि नंतर नियंत्रण पॅनेल स्थिर झाले.

(टीप: SuperGloo आत्ता फक्त Istio 1.0.x चे समर्थन करते. मी Istio 1.1.3 सह प्रयोगाची पुनरावृत्ती केली, परंतु कोणताही लक्षणीय फरक लक्षात आला नाही.)

Istio स्वयंचलित उपयोजन सेट करत आहे

Istio ला साइडकार दूत स्थापित करण्यासाठी, आम्ही साइडकार इंजेक्टर - वापरतो MutatingAdmissionWebhook. आम्ही या लेखात याबद्दल बोलणार नाही. मी फक्त असे म्हणू इच्छितो की हा एक नियंत्रक आहे जो सर्व नवीन पॉड्सच्या प्रवेशावर लक्ष ठेवतो आणि गतिमानपणे साइडकार आणि 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 साइडकार एम्बेडिंग सेट करण्यासाठी, आम्ही भाष्ये वापरतो (मी त्याद्वारे व्यक्तिचलितपणे जोडले 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 फॉल्ट टॉलरन्स सिम्युलेटर

Shopify साठी अनन्य ट्रॅफिकचा प्रयोग करण्यासाठी आम्ही Istio नावाचे फॉल्ट टॉलरन्स सिम्युलेटर तयार केले आहे. आम्हाला एक सानुकूल टोपोलॉजी तयार करण्यासाठी एका साधनाची आवश्यकता आहे जी आमच्या सेवा आलेखाच्या विशिष्ट भागाचे प्रतिनिधित्व करेल, विशिष्ट वर्कलोड मॉडेल करण्यासाठी डायनॅमिकरित्या कॉन्फिगर केले जाईल.

फ्लॅश विक्री दरम्यान 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 प्रतिकृती ज्यांना विनंती प्राप्त होते, 100ms प्रतीक्षा करा आणि विनंती पाठवा irs-server.
• irs-server: 3 प्रतिकृती ज्या परत करतात 200/OK 100 ms नंतर

या कॉन्फिगरेशनसह, आम्ही 9 अंत्यबिंदूंमधील स्थिर रहदारी प्रवाह मोजू शकतो. मध्ये साइडकार irs-client-loadgen и irs-server प्रति सेकंद 100 विनंत्या प्राप्त करा, आणि irs-client - 200 (इनकमिंग आणि आउटगोइंग).

आम्ही माध्यमातून संसाधन वापर ट्रॅक डेटाडॉगकारण आमच्याकडे प्रोमिथियस क्लस्टर नाही.

निकाल

नियंत्रण पॅनेल

प्रथम, आम्ही CPU वापर तपासला.

लिंकर्ड कंट्रोल पॅनल ~22 मिलीकोर

Istio नियंत्रण पॅनेल: ~750 मिलीकोर

Istio नियंत्रण पॅनेल अंदाजे वापरते 35 पट अधिक CPU संसाधनेLinkerd पेक्षा. अर्थात, सर्वकाही डीफॉल्टनुसार स्थापित केले आहे, आणि istio-telemetry येथे भरपूर प्रोसेसर संसाधने वापरतात (काही फंक्शन्स अक्षम करून ते अक्षम केले जाऊ शकते). आम्ही हा घटक काढून टाकल्यास, आम्हाला अजूनही 100 पेक्षा जास्त मिलिकोअर मिळतील, म्हणजेच 4 पट जास्तLinkerd पेक्षा.

साइडकार प्रॉक्सी

त्यानंतर आम्ही प्रॉक्सीच्या वापराची चाचणी घेतली. विनंत्यांच्या संख्येशी एक रेषीय संबंध असावा, परंतु प्रत्येक साइडकारसाठी काही ओव्हरहेड आहे जे वक्र प्रभावित करते.

लिंकर्ड: आयआरएस-क्लायंटसाठी ~100 मिलिकोअर, आयआरएस-क्लायंट-लोडजनसाठी ~50 मिलिकोअर

परिणाम तार्किक दिसतात, कारण क्लायंट प्रॉक्सीला लोडजन प्रॉक्सीपेक्षा दुप्पट ट्रॅफिक मिळते: लोडजनच्या प्रत्येक आउटगोइंग विनंतीसाठी, क्लायंटकडे एक इनकमिंग आणि एक आउटगोइंग असते.

Istio/दूत: irs-क्लायंटसाठी ~155 मिलिकोअर, ~75 मिलिकोअर irs-क्लायंट-लोडजनसाठी

आम्हाला Istio sidecars साठी समान परिणाम दिसत आहेत.

परंतु सर्वसाधारणपणे, Istio/Envoy प्रॉक्सी वापरतात अंदाजे 50% अधिक CPU संसाधनेLinkerd पेक्षा.

आम्ही सर्व्हरच्या बाजूला समान योजना पाहतो:

लिंकर्ड: irs-सर्व्हरसाठी ~50 मिलीकोर

Istio/दूत: irs-सर्व्हरसाठी ~80 मिलीकोअर

सर्व्हरच्या बाजूने, साइडकार Istio/Envoy वापरतात अंदाजे 60% अधिक CPU संसाधनेLinkerd पेक्षा.

निष्कर्ष

Istio Envoy प्रॉक्सी आमच्या सिम्युलेटेड वर्कलोडवर Linkerd पेक्षा 50+% अधिक CPU वापरते. Linkerd नियंत्रण पॅनेल Istio पेक्षा खूपच कमी संसाधने वापरते, विशेषत: मुख्य घटकांसाठी.

हे खर्च कसे कमी करता येतील यावर आम्ही अजूनही विचार करत आहोत. आपल्याकडे कल्पना असल्यास, कृपया सामायिक करा!

स्त्रोत: www.habr.com