हे हाबर! म तपाईंको ध्यानाकर्षणमा लेखको अनुवाद प्रस्तुत गर्दछु "सर्भिस मेस डाटा प्लेन बनाम कन्ट्रोल प्लेन" लेखक म्याट क्लाइन.

यस पटक, मैले सेवा मेष कम्पोनेन्टहरू, डेटा प्लेन र कन्ट्रोल प्लेन दुवैको विवरण "चाहिएको र अनुवाद गरें"। यो विवरण मलाई सबैभन्दा बुझ्ने र चाखलाग्दो लाग्यो, र सबैभन्दा महत्त्वपूर्ण रूपमा "के यो आवश्यक छ?"

पछिल्लो दुई वर्षमा "सेवा जाल" को विचार बढ्दो रूपमा लोकप्रिय भएको छ (मूल लेख अक्टोबर 10, 2017) र अन्तरिक्षमा सहभागीहरूको संख्या बढ्दै गएकोले, मैले समग्रमा अन्योलमा समानुपातिक वृद्धि देखेको छु। विभिन्न समाधानहरू कसरी तुलना र कन्ट्रास्ट गर्ने भन्ने सन्दर्भमा टेक समुदाय।

मैले जुलाईमा लेखेका ट्विटहरूको निम्न शृङ्खलाहरूद्वारा परिस्थितिलाई उत्तम रूपमा संक्षेप गरिएको छ:

सेवा जाल भ्रम #1: Linkerd ~ = Nginx ~ = Haproxy ~ = दूत। तिनीहरू मध्ये कुनै पनि Istio बराबर छैन। Istio एकदम फरक कुरा हो। १/

पहिलो केवल डाटा प्लेनहरू हुन्। आफैंले केही गर्दैनन् । तिनीहरू थप केहिको लागि मूडमा हुनुपर्छ। २/

Istio एक नियन्त्रण विमान को एक उदाहरण हो जसले भागहरु लाई एकसाथ जोड्दछ। यो अर्को तह हो। / अन्त्य

अघिल्लो ट्विटहरूले धेरै फरक परियोजनाहरू (Linkerd, NGINX, HAProxy, Envoy, र Istio) उल्लेख गरेको छ, तर अझ महत्त्वपूर्ण रूपमा डेटा विमान, सेवा जाल, र नियन्त्रण विमानको सामान्य अवधारणाहरू परिचय गराउँछ। यस पोष्टमा, म एक कदम पछि हट्छु र धेरै उच्च स्तरमा "डेटा प्लेन" र "कन्ट्रोल प्लेन" शब्दहरूबाट मैले भनेको के हो भन्ने बारे कुरा गर्नेछु, र त्यसपछि ट्विटहरूमा उल्लेख गरिएका परियोजनाहरूमा सर्तहरू कसरी लागू हुन्छन् भन्ने बारे कुरा गर्नेछु।

सेवा जाल के हो, वास्तवमा?

चित्र 1: सेवा जाल सिंहावलोकन

1 फिगर यसको सबैभन्दा आधारभूत स्तरमा सेवा जालको अवधारणालाई चित्रण गर्दछ। त्यहाँ चार सेवा क्लस्टर (AD) छन्। प्रत्येक सेवा उदाहरण स्थानीय प्रोक्सी सर्भरसँग सम्बन्धित छ। सबै नेटवर्क ट्राफिक (HTTP, REST, gRPC, Redis, आदि) एकल अनुप्रयोग उदाहरणबाट स्थानीय प्रोक्सी मार्फत उपयुक्त बाह्य सेवा क्लस्टरहरूमा पठाइन्छ। यस तरिकाले, एप्लिकेसन इन्स्ट्यान्स सम्पूर्ण नेटवर्कको बारेमा अनजान छ र यसको स्थानीय प्रोक्सीको बारेमा मात्र सचेत छ। प्रभावमा, वितरण प्रणाली नेटवर्क सेवाबाट हटाइयो।

डाटा प्लेन

सेवा जालमा, अनुप्रयोगको लागि स्थानीय रूपमा अवस्थित प्रोक्सी सर्भरले निम्न कार्यहरू गर्दछ:

• सेवा आविष्कार। तपाईको आवेदनको लागि कुन सेवा/अनुप्रयोगहरू उपलब्ध छन्?
• स्वास्थ्य जाँच। के सेवा खोज द्वारा फिर्ता गरिएका सेवा उदाहरणहरू स्वस्थ र नेटवर्क ट्राफिक स्वीकार गर्न तयार छन्? यसले दुवै सक्रिय (जस्तै प्रतिक्रिया/स्वास्थ्य जाँच) र निष्क्रिय (जस्तै, अस्वस्थ सेवा अवस्थाको सङ्केतको रूपमा 3 लगातार 5xx त्रुटिहरू प्रयोग गरेर) स्वास्थ्य जाँचहरू समावेश गर्न सक्छ।
• रूटिङ। REST सेवाबाट "/foo" मा अनुरोध प्राप्त गर्दा, कुन सेवा क्लस्टरमा अनुरोध पठाउनुपर्छ?
• लोड सन्तुलन। रुटिङको क्रममा सेवा क्लस्टर चयन गरिसकेपछि, कुन सेवा उदाहरणमा अनुरोध पठाउनुपर्छ? के टाइमआउट संग? कुन सर्किट ब्रेकिङ सेटिङहरूसँग? यदि अनुरोध असफल भयो भने, यसलाई पुन: प्रयास गर्नुपर्छ?
• प्रमाणीकरण र प्राधिकरण। आगमन अनुरोधहरूको लागि, के कलिङ सेवालाई mTLS वा केही अन्य मेकानिजम प्रयोग गरेर क्रिप्टोग्राफिक रूपमा पहिचान/अधिकृत गर्न सकिन्छ? यदि यो मान्यता प्राप्त/अधिकृत छ भने, के यो सेवामा अनुरोध गरिएको अपरेशन (अन्तबिन्दु) कल गर्न अनुमति छ वा एक अप्रमाणित प्रतिक्रिया फिर्ता गर्नुपर्छ?
• अवलोकन योग्यता। प्रत्येक अनुरोधको लागि विस्तृत तथ्याङ्कहरू, लगहरू/लगहरू, र वितरित ट्रेस डाटा उत्पन्न गरिनुपर्छ ताकि अपरेटरहरूले तिनीहरू उत्पन्न हुँदा वितरित ट्राफिक प्रवाह र डिबगिङ समस्याहरू बुझ्न सक्छन्।

डाटा प्लेन सेवा जालमा सबै अघिल्लो बिन्दुहरूको लागि जिम्मेवार छ। वास्तवमा, सेवाको प्रोक्सी स्थानीय (साइडकार) डाटा प्लेन हो। अर्को शब्दमा, डाटा प्लेन सशर्त प्रसारण, फर्वार्डिङ, र सेवामा पठाइएका प्रत्येक नेटवर्क प्याकेटको निगरानीको लागि जिम्मेवार छ।

नियन्त्रण विमान

स्थानीय प्रोक्सीले डाटा प्लेनमा प्रदान गर्ने नेटवर्क अमूर्तता जादुई (?) हो। यद्यपि, प्रोक्सीले वास्तवमा सेवा B को "/foo" मार्गको बारेमा कसरी थाहा पाउँछ? प्रोक्सी अनुरोधहरूद्वारा भरिएको सेवा खोज डाटा कसरी प्रयोग गर्न सकिन्छ? लोड ब्यालेन्सिङ, टाइमआउट, सर्किट ब्रेकिङ, आदिका लागि प्यारामिटरहरू कसरी कन्फिगर हुन्छन्? नीलो/हरियो विधि वा आकर्षक ट्राफिक ट्रान्जिसन विधि प्रयोग गरेर तपाइँ कसरी एप्लिकेसन डिप्लोय गर्नुहुन्छ? कसले प्रणाली-व्यापी प्रमाणीकरण र प्राधिकरण सेटिङहरू कन्फिगर गर्छ?

माथिका सबै वस्तुहरू सेवा जालको नियन्त्रण विमानको नियन्त्रणमा छन्। नियन्त्रण विमानले पृथक स्टेटलेस प्रोक्सीहरूको सेट लिन्छ र तिनीहरूलाई वितरित प्रणालीमा परिणत गर्दछ.

मलाई लाग्छ धेरै टेक्नोलोजिस्टहरूले डाटा प्लेन र कन्ट्रोल प्लेनका अलग-अलग अवधारणाहरू भ्रमित पार्ने कारण यो हो किनभने धेरैजसो मानिसहरूका लागि डाटा प्लेन परिचित छ जबकि नियन्त्रण प्लेन विदेशी/बुझेको छैन। हामीले लामो समयदेखि भौतिक नेटवर्क राउटर र स्विचहरूसँग काम गरिरहेका छौं। हामी बुझ्दछौं कि प्याकेटहरू/अनुरोधहरू बिन्दु A बाट बिन्दु B मा जान आवश्यक छ र हामी यो गर्न हार्डवेयर र सफ्टवेयर प्रयोग गर्न सक्छौं। सफ्टवेयर प्रोक्सीहरूको नयाँ पुस्ता भनेको हामीले लामो समयदेखि प्रयोग गर्दै आएका उपकरणहरूका फ्यान्सी संस्करणहरू हुन्।

चित्र २: मानव नियन्त्रण विमान

यद्यपि, हामीले लामो समयदेखि नियन्त्रण विमानहरू प्रयोग गर्दै आएका छौं, यद्यपि अधिकांश नेटवर्क अपरेटरहरूले प्रणालीको यो भागलाई कुनै पनि प्रविधि घटकसँग सम्बद्ध नगर्न सक्छन्। कारण सरल छ:
आज प्रयोगमा रहेका धेरैजसो नियन्त्रण विमानहरू हामी....

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

चित्र 3: उन्नत सेवा जाल नियन्त्रण विमान

मा चित्र। सेवा जालको "विस्तारित" नियन्त्रण विमान देखाउँछ। यो निम्न भागहरु मिलेर बनेको छ:

• मानव: त्यहाँ अझै पनि एक व्यक्ति (आशा कम रिसाउने) छ जसले सम्पूर्ण प्रणालीको बारेमा उच्च स्तरको निर्णय गर्दछ।
• नियन्त्रण विमान UI: एक व्यक्तिले प्रणाली नियन्त्रण गर्न केही प्रकारको प्रयोगकर्ता इन्टरफेससँग अन्तरक्रिया गर्छ। यो वेब पोर्टल, कमाण्ड लाइन एप्लिकेसन (CLI), वा केहि अन्य इन्टरफेस हुन सक्छ। प्रयोगकर्ता इन्टरफेस प्रयोग गरेर, अपरेटरसँग विश्वव्यापी प्रणाली कन्फिगरेसन प्यारामिटरहरूमा पहुँच छ जस्तै:
  • तैनाती नियन्त्रण, नीलो/हरियो र/वा क्रमिक ट्राफिक संक्रमण
  • प्रमाणीकरण र प्राधिकरण विकल्पहरू
  • राउटिङ तालिका विशिष्टताहरू, उदाहरणका लागि जब एप्लिकेसन एले "/foo" को बारेमा जानकारी अनुरोध गर्छ के हुन्छ
  • ब्यालेन्सर सेटिङहरू लोड गर्नुहोस्, जस्तै टाइमआउटहरू, पुन: प्रयासहरू, सर्किट ब्रेकिङ सेटिङहरू, आदि।
• कार्यभार अनुसूचक: सेवाहरू पूर्वाधारमा केही प्रकारको समयतालिका/अर्केस्ट्रेसन प्रणाली मार्फत चलाइन्छ, जस्तै कुबर्नेट्स वा नोमाड। अनुसूचक यसको स्थानीय प्रोक्सी संग सेवा लोड गर्न जिम्मेवार छ।
• सेवा आविष्कार। जब अनुसूचक सुरु हुन्छ र सेवा उदाहरणहरू रोक्छ, यसले सेवा खोज प्रणालीमा स्वास्थ्य स्थिति रिपोर्ट गर्दछ।
• Sidecar प्रोक्सी कन्फिगरेसन API हरू : स्थानीय प्रोक्सीहरूले अपरेटरको हस्तक्षेप बिना अन्ततः सुसंगत मोडेल प्रयोग गरेर विभिन्न प्रणाली कम्पोनेन्टहरूबाट गतिशील रूपमा स्थिति निकाल्छन्। सम्पूर्ण प्रणाली, हाल चलिरहेका सबै सेवा उदाहरणहरू र स्थानीय प्रोक्सी सर्भरहरू मिलेर, अन्ततः एउटै इकोसिस्टममा रूपान्तरण हुन्छ। दूतको सार्वभौमिक डेटा प्लेन एपीआई यो व्यवहारमा कसरी काम गर्दछ भन्ने एउटा उदाहरण हो।

अनिवार्य रूपमा, नियन्त्रण विमानको उद्देश्य भनेको नीति सेट गर्नु हो जुन अन्ततः डाटा प्लेनद्वारा स्वीकार गरिनेछ। अधिक उन्नत नियन्त्रण विमानहरूले अपरेटरबाट केही प्रणालीहरूको थप भागहरू हटाउनेछन् र कम म्यानुअल अपरेशन आवश्यक पर्दछ, यदि तिनीहरूले सही रूपमा काम गर्छन्!...

डाटा प्लेन र नियन्त्रण विमान। डेटा प्लेन बनाम नियन्त्रण प्लेन सारांश

• सेवा जाल डाटा विमान: प्रणालीमा भएका प्रत्येक प्याकेट/अनुरोधलाई असर गर्छ। आवेदन / सेवा खोज, स्वास्थ्य जाँच, मार्ग, लोड सन्तुलन, प्रमाणीकरण / प्राधिकरण र अवलोकनको लागि जिम्मेवार।
• सेवा जाल नियन्त्रण विमान: सेवा नेटवर्क भित्र सबै चलिरहेको डाटा प्लेनहरूको लागि नीति र कन्फिगरेसन प्रदान गर्दछ। प्रणालीमा कुनै पनि प्याकेज/अनुरोधहरू छुँदैन। नियन्त्रण विमानले सबै डाटा प्लेनहरूलाई वितरित प्रणालीमा परिणत गर्दछ।

हालको परियोजना परिदृश्य

माथिको व्याख्या बुझिसकेपछि, सेवा जाल परियोजनाको हालको अवस्था हेरौं।

• डाटा प्लेनहरू: Linkerd, NGINX, HAProxy, राजदूत, Traefik
• नियन्त्रण विमानहरू: Istio, नेल्सन, SmartStack

माथिका प्रत्येक समाधानको गहिरो विश्लेषणमा जानुको सट्टा, म संक्षेपमा केही बिन्दुहरूलाई सम्बोधन गर्नेछु जुन मलाई विश्वास छ कि अहिले इकोसिस्टममा धेरै भ्रम पैदा भइरहेको छ।

Linkerd 2016 को प्रारम्भमा सेवा जालको लागि पहिलो डेटा प्लेन प्रोक्सी सर्भरहरू मध्ये एक थियो र सेवा जाल डिजाइन मोडेलमा जागरूकता र ध्यान बढाउने उत्कृष्ट काम गरेको छ। त्यसको करिब ६ महिनापछि, दूत लिंकर्डमा सामेल भए (यद्यपि उनी २०१५ को अन्त्यदेखि लिफ्टसँग थिए)। Linkerd र Envoy दुई परियोजनाहरू हुन् जुन प्रायः सेवा जालहरू छलफल गर्दा उल्लेख गरिन्छ।

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

नेल्सन र SmartStack ले नियन्त्रण प्लेन र डाटा प्लेनको पृथकीकरणलाई थप चित्रण गर्न मद्दत गर्दछ। नेल्सनले दूतलाई आफ्नो प्रोक्सीको रूपमा प्रयोग गर्दछ र HashiCorp स्ट्याकमा आधारित सेवा जालको लागि भरपर्दो नियन्त्रण विमान निर्माण गर्दछ, अर्थात्। घुमन्ते आदि। SmartStack सायद सेवा जालहरूको नयाँ लहरको पहिलो थियो। SmartStack ले HAProxy वा NGINX वरिपरि एउटा नियन्त्रण प्लेन बनाउँछ, डेटा प्लेनबाट सेवा जालबाट नियन्त्रण प्लेन डिकपल गर्ने क्षमता प्रदर्शन गर्दै।

सेवा जालको साथ माइक्रोसर्भिस आर्किटेक्चरले अधिक र अधिक ध्यान प्राप्त गरिरहेको छ (सही!), र अधिक र अधिक परियोजनाहरू र विक्रेताहरूले यस दिशामा काम गर्न थालेका छन्। आउँदो केही वर्षहरूमा हामी डेटा प्लेन र कन्ट्रोल प्लेन दुवैमा धेरै नवीनताहरू देख्नेछौं, साथै विभिन्न कम्पोनेन्टहरूको थप मिश्रण। अन्ततः, माइक्रोसर्भिस आर्किटेक्चर अपरेटरको लागि थप पारदर्शी र जादुई (?) हुनुपर्छ।
आशा छ कम र कम रिस उठ्छ।

मुख्य टेकवेहरू

• सेवा जालमा दुई फरक भागहरू हुन्छन्: डाटा प्लेन र कन्ट्रोल प्लेन। दुवै घटक आवश्यक छ, र तिनीहरू बिना प्रणाली काम गर्दैन।
• सबैजना नियन्त्रण विमानसँग परिचित छन्, र यस बिन्दुमा, नियन्त्रण विमान तपाईं हुन सक्छ!
• सबै डेटा प्लेनहरू सुविधाहरू, कार्यसम्पादन, कन्फिगरेबिलिटी, र एक्स्टेन्सिबिलिटीमा एकअर्कासँग प्रतिस्पर्धा गर्छन्।
• सबै नियन्त्रण विमानहरू सुविधाहरू, कन्फिगरेबिलिटी, एक्स्टेन्सिबिलिटी, र प्रयोगको सहजतामा एकअर्कासँग प्रतिस्पर्धा गर्छन्।
• एक नियन्त्रण प्लेनले सही एब्स्ट्र्याक्सन र एपीआईहरू समावेश गर्न सक्छ ताकि धेरै डेटा प्लेनहरू प्रयोग गर्न सकिन्छ।

स्रोत: www.habr.com