उत्पादन में इस्तियो और कुबेरनेट्स। भाग 2. अनुरेखण

पिछले लेख में, हमने सर्विस मेश इस्तियो के बुनियादी घटकों की जांच की, सिस्टम से परिचित हुए और उन मूल सवालों के जवाब दिए जो आमतौर पर इस्तियो के साथ काम की शुरुआत में उठते हैं। इस भाग में, हम देखेंगे कि नेटवर्क पर ट्रेसिंग जानकारी के संग्रह को कैसे व्यवस्थित किया जाए।



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

गलतफहमी नंबर एक: हम नेटवर्क पर यात्राओं पर डेटा मुफ्त में प्राप्त कर सकते हैं

वास्तव में, अपेक्षाकृत मुफ्त, हम केवल तीर द्वारा जुड़े हमारे सिस्टम के नोड्स और सेवाओं के बीच गुजरने वाले डेटा दर (वास्तव में, प्रति यूनिट समय केवल बाइट्स की संख्या) प्राप्त कर सकते हैं। हालांकि, ज्यादातर मामलों में, हमारी सेवाएं कुछ प्रकार के एप्लिकेशन-स्तरीय प्रोटोकॉल का उपयोग करके संवाद करती हैं, जैसे कि HTTP, gRPC, Redis, और इसी तरह। और, निश्चित रूप से, हम इन प्रोटोकॉल के अनुसार जानकारी को ठीक से देखना चाहते हैं, हम अनुरोधों की दर को देखना चाहते हैं, न कि डेटा की दर को। हम अपने प्रोटोकॉल द्वारा अनुरोधों की विलंबता को समझना चाहते हैं। अंत में, हम पूरा रास्ता देखना चाहते हैं कि अनुरोध उपयोगकर्ता से प्रतिक्रिया प्राप्त करने के लिए हमारे सिस्टम में प्रवेश करने से जाता है। यह समस्या इतनी आसानी से हल नहीं होती है।

शुरू करने के लिए, आइए देखें कि कैसे ट्रेसिंग स्पैन भेजना इस्तियो में वास्तुकला के दृष्टिकोण से दिखता है। जैसा कि हम पहले भाग से याद करते हैं, इस्तियो में टेलीमेट्री इकट्ठा करने के लिए एक अलग घटक है, जिसे मिक्सर कहा जाता है। हालाँकि, वर्तमान संस्करण 1.0 में। * भेजा जा रहा है सीधे प्रॉक्सी सर्वर से, अर्थात् प्रॉक्सी प्रॉक्सी से। Envoy प्रॉक्सी बॉक्स के बाहर zipkin प्रोटोकॉल के माध्यम से ट्रेसिंग स्पैन भेजने का समर्थन करता है। अन्य प्रोटोकॉल कनेक्ट किए जा सकते हैं, लेकिन केवल प्लगइन के माध्यम से। इस्तियो के साथ, हम तुरंत इकट्ठे और कॉन्फ़िगर किए गए दूत प्रॉक्सी प्राप्त करते हैं, जो केवल जिपक प्रोटोकॉल का समर्थन करता है। यदि हम, उदाहरण के लिए, जेगर प्रोटोकॉल का उपयोग करना चाहते हैं और यूडीपी के माध्यम से ट्रेसिंग स्पैन भेजना चाहते हैं, तो हमें अपनी आईएसटीओ-प्रॉक्सी छवि को इकट्ठा करने की आवश्यकता होगी। वहाँ istio- प्रॉक्सी के लिए कस्टम प्लगइन्स के लिए समर्थन है, हालांकि यह अभी भी अल्फा संस्करण में है। इसलिए, यदि हम बहुत सारी कस्टम सेटिंग्स के बिना करना चाहते हैं, तो ट्रेसिंग स्पैन को स्टोर करने और प्राप्त करने के लिए उपयोग की जाने वाली तकनीकों की सीमा कम हो जाती है। मुख्य प्रणालियों में से, वास्तव में, अब आप खुद जिपकिन या जैगर का उपयोग कर सकते हैं, लेकिन एक जिपकिन संगत प्रोटोकॉल (जो बहुत कम कुशल है) का उपयोग करके वहां सब कुछ भेजें। ज़िपकिन प्रोटोकॉल में ही HTTP प्रोटोकॉल का उपयोग करके सभी ट्रेसिंग जानकारी कलेक्टरों को भेजना शामिल है, जो काफी महंगा है।

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

apiVersion: v1 kind: Service metadata: name: nginx spec: ports: - port: 80 targetPort: 80 name: http selector: app: nginx 

आप कंपाउंड नामों का भी उपयोग कर सकते हैं, जैसे http-मैजिक (Istio http देखता है और इस पोर्ट को http समापन बिंदु के रूप में पहचानता है)। प्रारूप है: प्रोटो-एक्सट्रा।

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

यह समझने के लिए कि क्या प्रोटोकॉल वास्तव में सही ढंग से परिभाषित किया गया है, आपको दूत प्रॉक्सी के साथ किसी भी साइडकार कंटेनर में जाने और स्थान / config_dump के साथ दूत इंटरफ़ेस के व्यवस्थापक पोर्ट के लिए अनुरोध करने की आवश्यकता है। परिणामी कॉन्फ़िगरेशन में, आपको वांछित सेवा फ़ील्ड ऑपरेशन को देखने की आवश्यकता है। यह Istio में एक पहचानकर्ता के रूप में उपयोग किया जाता है जहां अनुरोध चल रहा है। इस्तियो में इस पैरामीटर के मूल्य को अनुकूलित करने के लिए (हम फिर इसे हमारे ट्रेसिंग सिस्टम में देखेंगे), सेवाकारक ध्वज को निर्दिष्ट करने के लिए आवश्यक है। उदाहरण के लिए, इसकी गणना निम्न एपीआई कुबेरनेट से प्राप्त चर से की जा सकती है:

--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')

यह समझने के लिए एक बढ़िया उदाहरण कि दूत में कैसे काम करता है ।

--zipkinAddress tracing-collector.tracing:9411 भेजने के लिए समापन बिंदु को भी दूत प्रॉक्सी के प्रारंभ झंडे में निर्दिष्ट किया जाना चाहिए, उदाहरण के लिए: --zipkinAddress tracing-collector.tracing:9411

गलतफहमी नंबर दो: हम बॉक्स से बाहर सिस्टम के लिए अनुरोधों के पारित होने का पूरा ट्रेल सस्ते में पा सकते हैं

दुर्भाग्य से, ऐसा नहीं है। कार्यान्वयन की जटिलता इस बात पर निर्भर करती है कि आपने पहले से ही सेवाओं की बातचीत को कैसे लागू किया है। ऐसा क्यों?

तथ्य यह है कि एक ही सेवा से आने वाले लोगों के साथ आने वाले अनुरोधों के पत्राचार को समझने के लिए istio -xy के लिए, यह केवल सभी ट्रैफ़िक को बाधित करने के लिए पर्याप्त नहीं है। आपको किसी प्रकार के लिंक पहचानकर्ता की आवश्यकता है। Envoy प्रॉक्सी HTTP विशेष हेडर का उपयोग करता है, जिसके अनुसार envoy समझता है कि कौन सी विशेष सेवा अनुरोध अन्य सेवाओं के लिए विशिष्ट अनुरोध उत्पन्न करता है। ऐसे हेडर की सूची:

• एक्स-अनुरोध आईडी,
• एक्स-बी 3-traceid,
• एक्स-बी 3-spanid,
• एक्स-बी 3-parentspanid,
• एक्स-बी 3 नमूना,
• एक्स-बी 3-झंडे,
• एक्स-OT-अवधि संदर्भ।

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

निष्कर्ष

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

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