Istio र Kubernetes उत्पादन मा। भाग २। ट्रेसिङ

विगतमा लेख हामीले सेवा मेष इस्टियोको आधारभूत कम्पोनेन्टहरू हेर्‍यौं, प्रणालीसँग परिचित भयौं र मुख्य प्रश्नहरूको जवाफ दियौं जुन सामान्यतया आइस्टियोसँग काम गर्न सुरु गर्दा उत्पन्न हुन्छ। यस भागमा हामी नेटवर्कमा ट्रेसिङ जानकारीको सङ्कलन कसरी व्यवस्थित गर्ने भनेर हेर्नेछौं।

धेरै विकासकर्ताहरू र प्रणाली प्रशासकहरूको दिमागमा पहिलो कुरा आउँछ जब उनीहरूले सेवा मेष ट्रेसिङ शब्दहरू सुन्छन्। वास्तवमा, हामी प्रत्येक नेटवर्क नोडमा एक विशेष प्रोक्सी सर्भर थप्छौं जसबाट सबै TCP ट्राफिक पास हुन्छ। यो नेटवर्क मा सबै नेटवर्क अन्तरक्रियाहरु बारे जानकारी सजिलै पठाउन सम्भव छ जस्तो देखिन्छ। दुर्भाग्यवश, वास्तवमा त्यहाँ धेरै nuances खातामा लिनु आवश्यक छ। तिनीहरूलाई हेरौं।

गलत धारणा नम्बर एक: हामी नि: शुल्क अनलाइन हाइकिंग डाटा प्राप्त गर्न सक्छौं।

वास्तवमा, अपेक्षाकृत नि: शुल्कको लागि, हामीले हाम्रो प्रणालीको नोडहरू तीरहरू र सेवाहरू बीचमा जाने डेटा दर (वास्तवमा, समयको प्रति एकाइ बाइटहरूको संख्या मात्र) द्वारा जडान गर्न सक्छौं। जे होस्, धेरै जसो अवस्थामा, हाम्रा सेवाहरूले HTTP, gRPC, Redis, र यस्तै अन्य प्रकारका अनुप्रयोग तह प्रोटोकलहरूमा सञ्चार गर्छन्। र, अवश्य पनि, हामी यी प्रोटोकलहरूको लागि विशेष रूपमा ट्रेसिङ जानकारी हेर्न चाहन्छौं; हामी अनुरोध दर हेर्न चाहन्छौं, डाटा दर होइन। हामी हाम्रो प्रोटोकल प्रयोग गरेर अनुरोधहरूको विलम्बता बुझ्न चाहन्छौं। अन्तमा, हामी पूर्ण मार्ग हेर्न चाहन्छौं जुन अनुरोधले हाम्रो प्रणालीमा लग इन गर्नदेखि प्रयोगकर्ताबाट प्रतिक्रिया प्राप्त गर्न लिन्छ। यो समस्या समाधान गर्न अब त्यति सजिलो छैन।

पहिले, Istio मा आर्किटेक्चरल दृष्टिकोणबाट ट्रेसिङ स्प्यान्स पठाउने कस्तो देखिन्छ हेरौं। हामीले पहिलो भागबाट याद गरेझैं, Istio सँग टेलिमेट्री सङ्कलन गर्नको लागि मिक्सर भनिने छुट्टै कम्पोनेन्ट छ। यद्यपि, हालको संस्करण १.०.* मा, सिधै प्रोक्सी सर्भरहरूबाट, अर्थात् दूत प्रोक्सीबाट पठाइन्छ। दूत प्रोक्सीले बक्स बाहिर zipkin प्रोटोकल प्रयोग गरेर ट्रेसिङ स्प्यानहरू पठाउन समर्थन गर्दछ। यो अन्य प्रोटोकल जडान गर्न सम्भव छ, तर केवल एक प्लगइन मार्फत। Istio को साथ हामीले तुरुन्तै एक भेला र कन्फिगर गरिएको दूत प्रोक्सी पाउँछौं, जसले जिपकिन प्रोटोकललाई मात्र समर्थन गर्दछ। यदि हामी प्रयोग गर्न चाहन्छौं, उदाहरणका लागि, Jaeger प्रोटोकल र UDP मार्फत ट्रेसिङ स्प्यानहरू पठाउन, त्यसपछि हामीले हाम्रो आफ्नै istio-proxy छवि निर्माण गर्न आवश्यक हुनेछ। istio-proxy को लागि अनुकूलन प्लगइनहरूको लागि समर्थन छ, तर यो अझै अल्फा संस्करणमा छ। त्यसकारण, यदि हामी अनुकूलन सेटिङहरूको ठूलो संख्या बिना गर्न चाहन्छौं भने, ट्रेसिङ स्प्यानहरू भण्डारण र प्राप्त गर्न प्रयोग गरिने प्रविधिहरूको दायरा घटाइन्छ। मुख्य प्रणालीहरू मध्ये, वास्तवमा, अब तपाईं Zipkin आफै, वा Jaeger प्रयोग गर्न सक्नुहुन्छ, तर zipkin उपयुक्त प्रोटोकल (जुन धेरै कम कुशल छ) प्रयोग गरेर त्यहाँ सबै पठाउनुहोस्। जिपकिन प्रोटोकलले HTTP प्रोटोकल मार्फत सङ्कलनकर्ताहरूलाई सबै ट्रेसिङ जानकारी पठाउने समावेश गर्दछ, जुन धेरै महँगो छ।

मैले पहिले नै भनें, हामी अनुप्रयोग-स्तर प्रोटोकलहरू ट्रेस गर्न चाहन्छौं। यसको मतलब प्रत्येक सेवाको छेउमा उभिने प्रोक्सी सर्भरहरूले अहिले कस्तो प्रकारको अन्तरक्रिया भइरहेको छ भन्ने कुरा बुझ्नुपर्छ। पूर्वनिर्धारित रूपमा, Istio ले सबै पोर्टहरूलाई सादा TCP हुन कन्फिगर गर्दछ, जसको मतलब कुनै ट्रेसहरू पठाइने छैन। ट्रेसहरू पठाउनको लागि, तपाईंले पहिले, मुख्य जाल कन्फिगरेसनमा यो विकल्प सक्षम गर्नुपर्छ र, के धेरै महत्त्वपूर्ण छ, सेवामा प्रयोग हुने प्रोटोकल अनुसार कुबर्नेट्स सेवा संस्थाहरूको सबै पोर्टहरू नाम दिनुहोस्। त्यो हो, उदाहरण को लागी, यो जस्तै:

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 मा यो प्यारामिटरको मान अनुकूलन गर्न (हामी यसलाई हाम्रो ट्रेसिङ प्रणालीमा देख्नेछौं), साइडकार कन्टेनर सुरू गर्ने चरणमा सेवा क्लस्टर झण्डा निर्दिष्ट गर्न आवश्यक छ। उदाहरण को लागी, यो निम्न kubernetes 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-अनुरोध-आईडी,
• x-b3-traceid,
• x-b3-स्प्यानिड,
• x-b3-parentspanid,
• x-b3-नमूना,
• x-b3-झण्डा,
• x-ot-span-context।

यदि तपाइँसँग एकल बिन्दु छ भने, उदाहरणका लागि, आधारभूत ग्राहक, जसमा तपाइँ यस्तो तर्क थप्न सक्नुहुन्छ, त्यसपछि सबै कुरा ठीक छ, तपाइँले यो पुस्तकालय सबै ग्राहकहरूको लागि अद्यावधिक हुनको लागि कुर्नु पर्छ। तर यदि तपाईंसँग धेरै विषम प्रणाली छ र नेटवर्कमा सेवाबाट सेवामा सर्ने कुनै एकीकरण छैन भने, यो सम्भवतः ठूलो समस्या हुनेछ। यस्तो तर्क थपे बिना, सबै ट्रेसिङ जानकारी "एकल-स्तर" मात्र हुनेछ। त्यो हो, हामीले सबै अन्तर-सेवा अन्तरक्रियाहरू प्राप्त गर्नेछौं, तर तिनीहरू नेटवर्क मार्फत एकल चेनहरूमा टाँसिने छैनन्।

निष्कर्षमा

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

सेवा जालको बारेमा अर्को लेखमा, हामी Istio का सबैभन्दा ठूलो समस्याहरू मध्ये एउटा हेर्नेछौं - प्रत्येक साइडकार प्रोक्सी कन्टेनरद्वारा RAM को ठूलो खपत र तपाइँ यसलाई कसरी व्यवहार गर्न सक्नुहुन्छ भनेर छलफल गर्नेछौं।

स्रोत: www.habr.com