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

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

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

ग़लतफ़हमी नंबर एक: हम ऑनलाइन हाइकिंग डेटा मुफ़्त में प्राप्त कर सकते हैं।

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

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

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

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

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

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

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

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

यह समझने के लिए एक अच्छा उदाहरण है कि दूत में ट्रेसिंग कैसे काम करती है यहां.

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

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

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

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

एक्स-अनुरोध-आईडी,
x-b3-ट्रेसिड,
x-b3-स्पैनिड,
x-b3-parentspanid,
x-b3-नमूना,
x-b3-झंडे,
एक्स-ओटी-स्पैन-संदर्भ।

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

निष्कर्ष

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

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

स्रोत: www.habr.com

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

ग़लतफ़हमी नंबर एक: हम ऑनलाइन हाइकिंग डेटा मुफ़्त में प्राप्त कर सकते हैं।

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

निष्कर्ष

एक टिप्पणी जोड़ें उत्तर रद्द