📒 🧛🏻 👨🏽‍🏫 Istio और Linkerd के लिए सीपीयू खपत बेंचमार्क 👨🏻 🔨 🛃

परिचय

Shopify पर हम एक सेवा जाल के रूप में इस्तियो को तैनात कर रहे थे। सिद्धांत रूप में, सब कुछ सूट करता है, एक चीज को छोड़कर: यह महंगा है ।

Istio के लिए प्रकाशित मानक कहते हैं:

इस्तियो 1.1 के साथ, प्रॉक्सी प्रति सेकंड 1000 अनुरोधों पर लगभग 0.6 vCPU (वर्चुअल कोर) का उपभोग करता है।

सेवा जाल में पहले क्षेत्र के लिए (कनेक्शन के प्रत्येक पक्ष पर 2 परदे के पीछे), हमारे पास प्रति सेकंड एक लाख अनुरोधों की दर से, केवल परदे के लिए 1200 कोर होंगे। Google के लागत कैलकुलेटर के अनुसार, हमें n1-standard-64 कॉन्फ़िगरेशन के लिए लगभग $ 40 / महीना / कोर मिलता है, अर्थात यह क्षेत्र हमें प्रति सेकंड 1 मिलियन अनुरोधों के लिए प्रति माह $ 50,000 से अधिक खर्च करेगा।

इवान सिम ( इवान सिम ) ने स्पष्ट रूप से पिछले साल सेवा जाल देरी की तुलना की और मेमोरी और प्रोसेसर के लिए समान वादा किया, लेकिन असफल रहा:

जाहिर है, मान-istio-test.yaml प्रोसेसर अनुरोधों को गंभीरता से बढ़ाएगा। अगर मैंने सब कुछ सही ढंग से गणना की, तो आपको नियंत्रण कक्ष के लिए लगभग 24 प्रोसेसर कोर और प्रत्येक प्रॉक्सी के लिए 0.5 सीपीयू की आवश्यकता होगी। मेरे पास इतना नहीं है जब मेरे पास अधिक संसाधन आवंटित किए जाएंगे तो मैं परीक्षण दोहराऊंगा।

मैं अपने लिए देखना चाहता था कि कैसे इस्तियो का प्रदर्शन एक अन्य ओपन सोर्स सर्विस मेष के समान है: लिंकरड ।

सेवा जाल स्थापना

सुपरग्लू क्लस्टर में मैंने पहली चीज़ स्थापित की थी :

 $ 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 का उपयोग किया क्योंकि यह सेवा जाल के बूट को बहुत सरल करता है। मेरे पास करने के लिए लगभग कुछ भी नहीं था। उत्पादन में, हम सुपरग्लू का उपयोग नहीं करते हैं, लेकिन यह एक समान कार्य के लिए आदर्श है। मुझे प्रत्येक सेवा जाल में बस कुछ ही आदेश लागू करने थे। मैंने अलगाव के लिए दो समूहों का इस्तेमाल किया - एक इस्तियो और लिंकरड के लिए।

प्रयोग Google कुबेरनेट इंजन पर आयोजित किया गया था। मैंने 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 | +---------+------------+---------+---------------------------+

क्रैश-लूप में कई मिनट लगे, और फिर नियंत्रण कक्ष स्थिर हो गए।

(नोट: सुपरग्लो वर्तमान में केवल Istio 1.0.x का समर्थन करता है। मैंने Istio 1.1.3 के साथ प्रयोग को दोहराया, लेकिन कोई ध्यान देने योग्य अंतर नहीं देखा।)

इस्तियो की स्वचालित तैनाती की स्थापना

इस्तियो में साइडकार एनवॉय को स्थापित करने के लिए, हम साइडकार इंजेक्टर का उपयोग करते हैं - MutatingAdmissionWebhook । हम इस लेख में उसके बारे में बात नहीं करेंगे। मैं केवल यह कह सकता हूं कि यह एक नियंत्रक है जो सभी नए पॉड्स की पहुंच की निगरानी करता है और गतिशील रूप से एक साइडकार और इनटाइकोटेनर जोड़ता है, जो कि iptables कार्यों के लिए जिम्मेदार है।

शॉकराइज़ पर हमने फुटपाथ को लागू करने के लिए हमारे एक्सेस कंट्रोलर को लिखा, लेकिन इस बेंचमार्क में मैंने कंट्रोलर को लिया जो कि इस्तियो के साथ आता है। नियंत्रक istio-injection: enabled होने पर डिफ़ॉल्ट रूप से साइडकार इंजेक्ट करता है: नाम स्थान में 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 sidecar s के कार्यान्वयन को कॉन्फ़िगर करने के लिए, हम एनोटेशन का उपयोग करते हैं (मैंने उन्हें 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

दोष सहिष्णुता सिम्युलेटर इस्तियो

हमने Shopify के लिए अद्वितीय ट्रैफ़िक के साथ प्रयोग करने के लिए Istio गलती सहिष्णुता सिम्युलेटर बनाया। हमें एक मनमाना टोपोलॉजी बनाने के लिए एक उपकरण की आवश्यकता थी जो विशिष्ट कार्यभार का अनुकरण करने के लिए गतिशील ट्यूनिंग के साथ हमारी सेवा के ग्राफ के एक निश्चित हिस्से का प्रतिनिधित्व करेगा।

फ्लैश की बिक्री के दौरान शोपिस इन्फ्रास्ट्रक्चर भारी भार में है। उसी समय, Shopify अनुशंसा करता है कि विक्रेता ऐसी बिक्री का संचालन अधिक बार करते हैं । बड़े ग्राहक कभी-कभी योजनाबद्ध फ्लैश बिक्री की चेतावनी देते हैं। अन्य लोग दिन या रात के किसी भी समय अप्रत्याशित रूप से हमारे लिए खर्च करते हैं।

हम चाहते थे कि हमारी गलती सहिष्णुता सिम्युलेटर में वर्कफ़्लोज़ को मॉडल करने के लिए है जो अतीत में शोपिस इन्फ्रास्ट्रक्चर को अधिभारित करने वाले टोपोलॉजी और वर्कलोड से मेल खाती है। सेवा जाल का उपयोग करने का मुख्य उद्देश्य यह है कि हमें नेटवर्क स्तर पर विश्वसनीयता और दोष सहिष्णुता की आवश्यकता है, और हमारे लिए यह महत्वपूर्ण है कि सेवा जाल प्रभावी रूप से उन भारों से सामना करे जो पहले सेवाओं के संचालन में बाधा डालते थे।

फेलओवर सिम्युलेटर एक कार्य नोड पर आधारित है जो सेवा जाल नोड के रूप में कार्य करता है। कार्य नोड को स्टार्टअप पर या गतिशील रूप से REST API के माध्यम से कॉन्फ़िगर किया जा सकता है। हम प्रतिगमन परीक्षणों के रूप में वर्कफ़्लो बनाने के लिए काम नोड्स के डायनेमिक ट्यूनिंग का उपयोग करते हैं।

ऐसी प्रक्रिया का एक उदाहरण यहां दिया गया है:

हम एक bar सेवा के रूप में 10 सर्वर शुरू करते हैं, जो 100 एमएस के बाद 200/OK प्रतिक्रिया देता है।
हम 10 ग्राहक शुरू करते हैं - प्रत्येक bar लिए प्रति सेकंड 100 अनुरोध भेजता है।
प्रत्येक 10 सेकंड में हम 1 सर्वर निकालते हैं, हम क्लाइंट पर 5xx त्रुटियों की निगरानी करते हैं।

वर्कफ़्लो के अंत में, हम लॉग और मेट्रिक्स का अध्ययन करते हैं और जाँचते हैं कि क्या परीक्षण पास हुआ है। इसी तरह से हम अपने सेवा जाल के प्रदर्शन के बारे में सीखते हैं और दोष सहिष्णुता के बारे में हमारी धारणाओं का परीक्षण करने के लिए एक प्रतिगमन परीक्षण करते हैं।

(नोट: हम Istio गलती सहिष्णुता सिम्युलेटर के लिए स्रोत कोड खोलने पर विचार कर रहे हैं, लेकिन हम अभी तक इसके लिए तैयार नहीं हैं।)

सेवा जाल बेंचमार्क के लिए इस्तियो गलती सहिष्णुता सिम्युलेटर

हम सिम्युलेटर के कई काम करने वाले नोड्स को कॉन्फ़िगर करते हैं:

irs-client-loadgen : 3 प्रतिकृतियां जो irs-client-loadgen irs-client को प्रति सेकंड 100 अनुरोध भेजती हैं।
irs-client : 3 प्रतिकृतियां जो अनुरोध प्राप्त करती हैं वे 100 ms प्रतीक्षा करती हैं और irs-server के अनुरोध को पुनर्निर्देशित करती हैं।
irs-server : 3 प्रतिकृतियां जो 100 एमएस के बाद 200/OK लौटाती हैं।

इस कॉन्फ़िगरेशन के साथ, हम 9 एंडपॉइंट के बीच एक स्थिर यातायात प्रवाह को माप सकते हैं। irs-client-loadgen और irs-client-loadgen irs-server को प्रति सेकंड 100 अनुरोध प्राप्त irs-client-loadgen और irs-client-loadgen irs-client - 200 (इनकमिंग और आउटगोइंग)।

हम डेटाडॉग के माध्यम से संसाधन उपयोग को ट्रैक करते हैं क्योंकि हमारे पास प्रोमेथियस क्लस्टर नहीं है।

परिणाम

नियंत्रण कक्ष

सबसे पहले, हमने सीपीयू की खपत की जांच की।

लिंकरड कंट्रोल पैनल ~ 22M

इस्तियो कंट्रोल पैनल: ~ 750 मिलियन कोर

इस्तियो नियंत्रण कक्ष लिंकरड की तुलना में लगभग 35 गुना अधिक प्रोसेसर संसाधनों का उपयोग करता है। बेशक, सब कुछ डिफ़ॉल्ट रूप से सेट किया गया है, और istio-telemetry प्रोसेसर संसाधनों की बहुत खपत करता है (आप कुछ कार्यों को छोड़कर इसे अक्षम कर सकते हैं)। यदि आप इस घटक को हटाते हैं, तो यह अभी भी 100 से अधिक मल्टीकोर हो जाता है, जो कि लिंकरड से 4 गुना अधिक है।

सिडकर प्रॉक्सी

फिर हमने प्रॉक्सी का उपयोग जांचा। अनुरोधों की संख्या पर एक रेखीय निर्भरता होनी चाहिए, लेकिन प्रत्येक साइडकार के लिए कुछ ओवरहेड्स होते हैं जो वक्र को प्रभावित करते हैं।

लिंकरड: ~ 100Mnuclear for irs-client, ~ 50Mnuclear for irs-client-loadgen

परिणाम तर्कसंगत दिखते हैं, क्योंकि क्लाइंट प्रॉक्सी लोडजेन प्रॉक्सी से दोगुना ट्रैफ़िक प्राप्त करता है: लोडजेन से प्रत्येक आउटगोइंग अनुरोध के लिए, क्लाइंट के पास एक इनकमिंग और एक आउटगोइंग है।

इस्तियो / दूत: ~ १५५ करोड़पति आईआरएस-ग्राहक के लिए, s५ करोड़पति आईआरएस-क्लाइंट-लोडगेन के लिए

हम Istio sidecar के लिए समान परिणाम देखते हैं।

लेकिन कुल मिलाकर, Istio / Envoy परदे के पीछे Linkerd की तुलना में लगभग 50% अधिक प्रोसेसर संसाधनों का उपभोग करता है।

हम सर्वर साइड पर एक ही स्कीम देखते हैं:

Linkerd: irs-server के लिए ~ 50 मल्टीकोर

इस्तियो / दूत: ~ आईआरएस-सर्वर के लिए 80 मल्टीकोर

सर्वर की ओर, इस्तियो / एनवॉय साइडकार लिंकरड की तुलना में लगभग 60% अधिक प्रोसेसर संसाधनों का उपभोग करता है।

निष्कर्ष

Istio Envoy प्रॉक्सी हमारे सिम्युलेटेड वर्कलोड पर Linkerd की तुलना में 50 +% अधिक CPU खर्च करता है। लिंकरड कंट्रोल पैनल विशेष रूप से मुख्य घटकों के लिए, इस्तियो की तुलना में बहुत कम संसाधनों की खपत करता है।

हम अभी भी सोच रहे हैं कि इन लागतों को कैसे कम किया जाए। यदि आपके पास कोई विचार है, तो साझा करें!

Istio और Linkerd के लिए सीपीयू खपत बेंचमार्क