उत्पादनात Istio आणि Kubernetes. भाग 2. ट्रेसिंग

शेवटी लेख आम्ही सर्व्हिस मेश इस्टिओचे मूलभूत घटक पाहिले, सिस्टमशी परिचित झालो आणि इस्टिओसह कार्य करण्यास प्रारंभ करताना सामान्यतः उद्भवणार्‍या मुख्य प्रश्नांची उत्तरे दिली. या भागात आपण नेटवर्कवर ट्रेसिंग माहितीचे संकलन कसे व्यवस्थित करायचे ते पाहू.

सर्व्हिस मेश ट्रेसिंग हे शब्द ऐकल्यावर बर्‍याच विकासक आणि सिस्टम प्रशासकांच्या मनात पहिली गोष्ट येते. खरंच, आम्ही प्रत्येक नेटवर्क नोडमध्ये एक विशेष प्रॉक्सी सर्व्हर जोडतो ज्याद्वारे सर्व TCP रहदारी जाते. असे दिसते की नेटवर्कवरील सर्व नेटवर्क परस्परसंवादांबद्दल माहिती सहजपणे पाठवणे आता शक्य आहे. दुर्दैवाने, प्रत्यक्षात अनेक बारकावे आहेत ज्या विचारात घेणे आवश्यक आहे. त्यांच्याकडे पाहू.

गैरसमज क्रमांक एक: आम्ही ऑनलाइन हायकिंग डेटा विनामूल्य मिळवू शकतो.

किंबहुना, तुलनेने विनामूल्य, आम्ही आमच्या सिस्टमचे नोड्स फक्त बाणांनी आणि सेवा दरम्यान पास होणारा डेटा दर मिळवू शकतो (खरं तर, वेळेच्या प्रति युनिट फक्त बाइट्सची संख्या). तथापि, बर्‍याच प्रकरणांमध्ये, आमच्या सेवा HTTP, gRPC, Redis आणि यासारख्या काही प्रकारच्या ऍप्लिकेशन लेयर प्रोटोकॉलवर संप्रेषण करतात. आणि, अर्थातच, आम्हाला या प्रोटोकॉलसाठी विशेषत: ट्रेसिंग माहिती पहायची आहे; आम्हाला विनंती दर पाहायचा आहे, डेटा दर नाही. आम्‍हाला आमचा प्रोटोकॉल वापरून विनंत्यांची विलंबता समजून घ्यायची आहे. शेवटी, आम्हाला आमच्या सिस्टममध्ये लॉग इन करण्यापासून ते वापरकर्त्याकडून प्रतिसाद मिळण्यापर्यंतचा संपूर्ण मार्ग पाहायचा आहे. ही समस्या सोडवणे आता इतके सोपे राहिलेले नाही.

प्रथम, इस्टिओमध्ये आर्किटेक्चरल दृष्टिकोनातून पाठवण्याचे ट्रेसिंग स्पॅन कसे दिसते ते पाहू. पहिल्या भागापासून आपल्याला आठवते की, टेलीमेट्री गोळा करण्यासाठी Istio मध्ये मिक्सर नावाचा एक वेगळा घटक आहे. तथापि, वर्तमान आवृत्ती 1.0.* मध्ये, पाठवणे थेट प्रॉक्सी सर्व्हरवरून केले जाते, म्हणजे, दूत प्रॉक्सीकडून. एन्व्हॉय प्रॉक्सी बॉक्सच्या बाहेर झिपकिन प्रोटोकॉल वापरून ट्रेसिंग स्पॅन पाठवण्यास समर्थन देते. इतर प्रोटोकॉल कनेक्ट करणे शक्य आहे, परंतु केवळ प्लगइनद्वारे. Istio सह आम्हाला ताबडतोब एकत्रित आणि कॉन्फिगर केलेली दूत प्रॉक्सी मिळते, जी फक्त झिपकिन प्रोटोकॉलला सपोर्ट करते. जर आम्हाला, उदाहरणार्थ, Jaeger प्रोटोकॉल वापरायचा असेल आणि UDP द्वारे ट्रेसिंग स्पॅन पाठवायचा असेल, तर आम्हाला आमची स्वतःची istio-proxy प्रतिमा तयार करावी लागेल. istio-proxy साठी सानुकूल प्लगइनसाठी समर्थन आहे, परंतु ते अद्याप अल्फा आवृत्तीमध्ये आहे. म्हणून, आम्हाला मोठ्या संख्येने सानुकूल सेटिंग्जशिवाय करायचे असल्यास, ट्रेसिंग स्पॅन्स संचयित करण्यासाठी आणि प्राप्त करण्यासाठी वापरल्या जाणार्‍या तंत्रज्ञानाची श्रेणी कमी केली जाते. मुख्य प्रणालींपैकी, खरं तर, आता तुम्ही स्वतः Zipkin किंवा Jaeger वापरू शकता, परंतु zipkin सुसंगत प्रोटोकॉल (जे खूपच कमी कार्यक्षम आहे) वापरून सर्वकाही तेथे पाठवू शकता. झिपकिन प्रोटोकॉलमध्ये HTTP प्रोटोकॉलद्वारे सर्व ट्रेसिंग माहिती संग्राहकांना पाठवणे समाविष्ट आहे, जे खूप महाग आहे.

मी आधीच म्हटल्याप्रमाणे, आम्हाला ऍप्लिकेशन-स्तरीय प्रोटोकॉल ट्रेस करायचे आहेत. याचा अर्थ असा की प्रत्येक सेवेच्या शेजारी उभ्या असलेल्या प्रॉक्सी सर्व्हरना आता कोणत्या प्रकारचा परस्परसंवाद होत आहे हे समजले पाहिजे. डीफॉल्टनुसार, Istio सर्व पोर्ट्स प्लेन TCP म्हणून कॉन्फिगर करते, याचा अर्थ कोणताही ट्रेस पाठवला जाणार नाही. ट्रेस पाठवण्‍यासाठी, तुम्‍ही, सर्वप्रथम, हा पर्याय मुख्य मेश कॉन्फिगरेशनमध्‍ये सक्षम करणे आवश्‍यक आहे आणि, सर्वात महत्त्वाचे म्हणजे, सेवेत वापरल्या जाणार्‍या प्रोटोकॉलनुसार kubernetes सेवा संस्थांच्या सर्व पोर्ट्सना नाव द्या. म्हणजे, उदाहरणार्थ, यासारखे:

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

तुम्ही http-magic सारखी कंपाऊंड नावे देखील वापरू शकता (Istio http पाहेल आणि त्या पोर्टला http एंडपॉइंट म्हणून ओळखेल). स्वरूप आहे: प्रोटो-अतिरिक्त.

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

प्रोटोकॉल खरोखरच योग्यरित्या परिभाषित केले आहे की नाही हे समजून घेण्यासाठी, तुम्हाला दूत प्रॉक्सीसह साइडकार कंटेनरपैकी कोणत्याहीमध्ये जाणे आवश्यक आहे आणि स्थान /config_dump सह दूत इंटरफेसच्या प्रशासक पोर्टला विनंती करणे आवश्यक आहे. परिणामी कॉन्फिगरेशनमध्ये, आपल्याला इच्छित सेवेचे ऑपरेशन फील्ड पाहण्याची आवश्यकता आहे. विनंती कोठे केली आहे यासाठी आयडेंटिफायर म्हणून ते Istio मध्ये वापरले जाते. Istio मध्ये या पॅरामीटरचे मूल्य सानुकूलित करण्यासाठी (आम्ही ते आमच्या ट्रेसिंग सिस्टममध्ये पाहू), साइडकार कंटेनर लॉन्च करण्याच्या टप्प्यावर सर्व्हिसक्लस्टर ध्वज निर्दिष्ट करणे आवश्यक आहे. उदाहरणार्थ, डाउनवर्ड कुबर्नेट्स API मधून मिळवलेल्या व्हेरिएबल्सवरून याची गणना केली जाऊ शकते:

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

दूतामध्ये ट्रेसिंग कसे कार्य करते हे समजून घेण्यासाठी एक चांगले उदाहरण आहे येथे.

ट्रेसिंग स्पॅन पाठवण्‍यासाठी एंडपॉइंट स्‍वत: दूत प्रॉक्‍सी लॉन्‍च फ्लॅगमध्‍ये देखील नमूद करणे आवश्‍यक आहे, उदाहरणार्थ: --zipkinAddress tracing-collector.tracing:9411

गैरसमज क्रमांक दोन: आम्ही बॉक्सच्या बाहेर सिस्टमद्वारे विनंत्यांचे संपूर्ण ट्रेस स्वस्तपणे मिळवू शकतो

दुर्दैवाने, ते नाही. अंमलबजावणीची जटिलता आपण आधीच सेवांच्या परस्परसंवादाची अंमलबजावणी कशी केली आहे यावर अवलंबून असते. अस का?

वस्तुस्थिती अशी आहे की समान सेवा सोडणार्‍यांसह सेवेला येणार्‍या विनंत्यांचा पत्रव्यवहार समजण्यास istio-proxy सक्षम होण्यासाठी, फक्त सर्व रहदारी रोखणे पुरेसे नाही. तुमच्याकडे काही प्रकारचे संप्रेषण अभिज्ञापक असणे आवश्यक आहे. HTTP दूत प्रॉक्सी विशेष शीर्षलेख वापरते, ज्याद्वारे दूत समजते की सेवेची कोणती विशिष्ट विनंती इतर सेवांसाठी विशिष्ट विनंत्या निर्माण करते. अशा शीर्षलेखांची यादी:

• x-request-id
• x-b3-traceid,
• x-b3-स्पॅनिड,
• x-b3-parentspanid,
• x-b3-नमुना,
• x-b3-ध्वज,
• x-ot-span-संदर्भ.

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

निष्कर्ष

Istio नेटवर्कवर ट्रेसिंग माहिती संकलित करण्यासाठी एक सोयीस्कर साधन प्रदान करते, परंतु तुम्ही हे समजून घेतले पाहिजे की अंमलबजावणीसाठी तुम्हाला तुमची प्रणाली अनुकूल करावी लागेल आणि Istio अंमलबजावणीची वैशिष्ट्ये विचारात घ्यावी लागतील. परिणामी, दोन मुख्य मुद्द्यांचे निराकरण करणे आवश्यक आहे: ऍप्लिकेशन लेव्हल प्रोटोकॉल (ज्याला दूत प्रॉक्सीद्वारे समर्थित केले जाणे आवश्यक आहे) परिभाषित करणे आणि सेवेच्या विनंत्यांमधून (शीर्षलेख वापरुन) सेवेशी विनंत्या कनेक्शनबद्दल माहिती फॉरवर्ड करणे सेट करणे. , HTTP प्रोटोकॉलच्या बाबतीत). जेव्हा या समस्यांचे निराकरण केले जाते, तेव्हा आमच्याकडे एक शक्तिशाली साधन आहे जे आम्हाला नेटवर्कवरून पारदर्शकपणे माहिती संकलित करण्यास अनुमती देते, अगदी भिन्न भाषांमध्ये आणि फ्रेमवर्कमध्ये लिहिलेल्या अतिशय विषम प्रणालींमध्ये देखील.

सर्व्हिस मेश बद्दलच्या पुढील लेखात, आम्ही Istio मधील सर्वात मोठ्या समस्यांपैकी एक पाहू - प्रत्येक साइडकार प्रॉक्सी कंटेनरद्वारे मोठ्या प्रमाणात RAM चा वापर आणि आपण त्यास कसे सामोरे जाऊ शकता यावर चर्चा करू.

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