अहो हाब्र! लेखाचा अनुवाद मी तुमच्या लक्षात आणून देत आहे "सर्व्हिस मेश डेटा प्लेन वि कंट्रोल प्लेन" लेखक मॅट क्लीन.

या वेळी, मला सर्व्हिस मेश घटक, डेटा प्लेन आणि कंट्रोल प्लेन या दोन्हींचे वर्णन “हवं आणि भाषांतरित” केले. हे वर्णन मला सर्वात समजण्याजोगे आणि मनोरंजक वाटले आणि सर्वात महत्त्वाचे म्हणजे "हे अजिबात आवश्यक आहे का?"

"सेवा जाळी" ची कल्पना गेल्या दोन वर्षांत (मूळ लेख ऑक्टोबर 10, 2017) अधिकाधिक लोकप्रिय होत असल्याने आणि स्पेसमधील सहभागींची संख्या वाढल्यामुळे, मी संपूर्ण लोकांमध्ये गोंधळात समान वाढ पाहिली आहे. विविध सोल्यूशन्सची तुलना आणि कॉन्ट्रास्ट कसे करावे यासंबंधी तंत्रज्ञान समुदाय.

मी जुलैमध्ये लिहिलेल्या ट्विटच्या पुढील मालिकेद्वारे परिस्थितीचा सारांश दिला जातो:

सेवा जाळी गोंधळ #1: Linkerd ~ = Nginx ~ = Haproxy ~ = दूत. यापैकी कोणीही इस्टिओच्या बरोबरीचे नाही. Istio काहीतरी पूर्णपणे वेगळे आहे. १/

प्रथम फक्त डेटा प्लेन आहेत. ते स्वतःहून काही करत नाहीत. ते आणखी काहीतरी करण्याच्या मूडमध्ये असले पाहिजेत. २/

Istio हे एक नियंत्रण विमानाचे उदाहरण आहे जे भागांना एकत्र बांधते. हा दुसरा थर आहे. /शेवट

मागील ट्विट्समध्ये अनेक वेगवेगळ्या प्रकल्पांचा उल्लेख आहे (लिंकर्ड, एनजीआयएनएक्स, एचएप्रॉक्सी, दूत आणि इस्टिओ), परंतु त्याहूनही महत्त्वाचे म्हणजे डेटा प्लेन, सर्व्हिस मेश आणि कंट्रोल प्लेनच्या सामान्य संकल्पना सादर करा. या पोस्टमध्ये, मी एक पाऊल मागे घेईन आणि "डेटा प्लेन" आणि "कंट्रोल प्लेन" या शब्दांचा मला काय अर्थ आहे त्याबद्दल उच्च स्तरावर बोलेन आणि नंतर ट्विटमध्ये नमूद केलेल्या प्रकल्पांना अटी कशा लागू होतात याबद्दल बोलेन.

Что такое сервисная сеть (What is a service mesh, really)?

आकृती 1: सेवा जाळी विहंगावलोकन

1 आकृती सेवा जाळीची संकल्पना त्याच्या सर्वात मूलभूत स्तरावर स्पष्ट करते. चार सेवा क्लस्टर (AD) आहेत. प्रत्येक सेवा उदाहरण स्थानिक प्रॉक्सी सर्व्हरशी संबंधित आहे. सर्व नेटवर्क ट्रॅफिक (HTTP, REST, gRPC, Redis, इ.) एकाच ऍप्लिकेशन इंस्टन्समधून स्थानिक प्रॉक्सीद्वारे योग्य बाह्य सेवा क्लस्टर्सकडे पाठवले जाते. अशा प्रकारे, ऍप्लिकेशन इन्स्टन्स संपूर्ण नेटवर्कबद्दल अनभिज्ञ आहे आणि केवळ त्याच्या स्थानिक प्रॉक्सीबद्दल माहिती आहे. प्रभावीपणे, वितरित सिस्टम नेटवर्क सेवेमधून काढले गेले.

डेटा प्लेन

सेवा जाळीमध्ये, अनुप्रयोगासाठी स्थानिक पातळीवर स्थित प्रॉक्सी सर्व्हर खालील कार्ये करतो:

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

सर्व्हिस मेशमधील सर्व मागील पॉइंट्ससाठी डेटा प्लेन जबाबदार आहे. खरं तर, सेवेसाठी प्रॉक्सी लोकल (साइडकार) डेटा प्लेन आहे. दुसऱ्या शब्दांत, डेटा प्लेन सशर्तपणे प्रसारित करण्यासाठी, फॉरवर्ड करण्यासाठी आणि सेवेकडून पाठवलेल्या प्रत्येक नेटवर्क पॅकेटचे निरीक्षण करण्यासाठी जबाबदार आहे.

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

डेटा प्लेनमध्ये स्थानिक प्रॉक्सी प्रदान करते ते नेटवर्क अॅब्स्ट्रॅक्शन जादुई(?) आहे. तथापि, सेवा B च्या "/foo" मार्गाबद्दल प्रॉक्सीला प्रत्यक्षात कसे कळते? प्रॉक्सी विनंत्यांनी भरलेला सेवा शोध डेटा कसा वापरला जाऊ शकतो? लोड बॅलन्सिंग, टाइमआउट, सर्किट ब्रेकिंग इत्यादीसाठी पॅरामीटर्स कसे कॉन्फिगर केले जातात? तुम्ही निळ्या/हिरव्या पद्धतीचा किंवा आकर्षक रहदारी संक्रमण पद्धतीचा वापर करून अनुप्रयोग कसा उपयोजित कराल? सिस्टम-व्यापी प्रमाणीकरण आणि अधिकृतता सेटिंग्ज कोण कॉन्फिगर करते?

वरील सर्व आयटम सर्व्हिस मेशच्या कंट्रोल प्लेनच्या नियंत्रणाखाली आहेत. कंट्रोल प्लेन वेगळ्या स्टेटलेस प्रॉक्सीचा संच घेते आणि त्यांना वितरित प्रणालीमध्ये बदलते.

मला वाटते की अनेक तंत्रज्ञांना डेटा प्लेन आणि कंट्रोल प्लेनच्या वेगळ्या संकल्पना गोंधळात टाकण्याचे कारण आहे कारण बहुतेक लोकांसाठी डेटा प्लेन परिचित आहे तर कंट्रोल प्लेन परदेशी/न समजलेले आहे. आम्ही बर्याच काळापासून भौतिक नेटवर्क राउटर आणि स्विचसह काम करत आहोत. आम्‍ही समजतो की पॅकेट/विनंती बिंदू A पासून बिंदू B पर्यंत जाणे आवश्यक आहे आणि हे करण्यासाठी आम्ही हार्डवेअर आणि सॉफ्टवेअर वापरू शकतो. सॉफ्टवेअर प्रॉक्सीची नवीन पिढी आम्ही बर्याच काळापासून वापरत असलेल्या साधनांच्या फक्त फॅन्सी आवृत्त्या आहेत.

आकृती 2: मानवी नियंत्रण विमान

Однако, мы уже долгое время использовали плоскости управления (control plane), хотя большинство сетевых операторов могут не связывать эту часть системы с каким-либо технологическим компонентом. Причина этого проста:
आज वापरात असलेली बहुतेक नियंत्रण विमाने... आम्ही आहोत.

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

आकृती 3: प्रगत सेवा जाळी नियंत्रण विमान

वर आकृती 3 सर्व्हिस मेशचे “विस्तारित” कंट्रोल प्लेन दाखवते. त्यात खालील भाग असतात:

• मानव: अजूनही एक व्यक्ती (आशेने कमी रागावलेली) आहे जी संपूर्ण व्यवस्थेबाबत उच्च स्तरीय निर्णय घेते.
• प्लेन UI नियंत्रित करा: प्रणाली नियंत्रित करण्यासाठी एखादी व्यक्ती काही प्रकारच्या वापरकर्ता इंटरफेसशी संवाद साधते. हे वेब पोर्टल, कमांड लाइन ऍप्लिकेशन (CLI) किंवा इतर काही इंटरफेस असू शकते. वापरकर्ता इंटरफेस वापरून, ऑपरेटरला ग्लोबल सिस्टम कॉन्फिगरेशन पॅरामीटर्समध्ये प्रवेश असतो जसे की:
  • उपयोजन नियंत्रण, निळा/हिरवा आणि/किंवा हळूहळू रहदारी संक्रमण
  • प्रमाणीकरण आणि अधिकृतता पर्याय
  • राउटिंग टेबल स्पेसिफिकेशन्स, उदाहरणार्थ जेव्हा ऍप्लिकेशन A "/foo" बद्दल माहितीची विनंती करतो तेव्हा काय होते
  • लोड बॅलन्सर सेटिंग्ज, जसे की कालबाह्य, पुन्हा प्रयत्न, सर्किट ब्रेकिंग सेटिंग्ज इ.
• वर्कलोड शेड्यूलर: सेवा काही प्रकारच्या शेड्युलिंग/ऑर्केस्ट्रेशन प्रणालीद्वारे पायाभूत सुविधांवर चालवल्या जातात, जसे की कुबर्नेट्स किंवा नोमॅड. शेड्युलर त्याच्या स्थानिक प्रॉक्सीसह सेवा लोड करण्यासाठी जबाबदार आहे.
• सेवा शोध. जेव्हा शेड्युलर सेवा उदाहरणे सुरू करतो आणि थांबवतो, तेव्हा तो सेवा शोध प्रणालीला आरोग्य स्थितीचा अहवाल देतो.
• साइडकार प्रॉक्सी कॉन्फिगरेशन API : स्थानिक प्रॉक्सी ऑपरेटरच्या हस्तक्षेपाशिवाय अखेरीस सुसंगत मॉडेल वापरून विविध सिस्टम घटकांमधून गतिशीलपणे स्थिती काढतात. सध्या चालू असलेल्या सर्व सेवा उदाहरणे आणि स्थानिक प्रॉक्सी सर्व्हरचा समावेश असलेली संपूर्ण प्रणाली, शेवटी एका इकोसिस्टममध्ये रूपांतरित होते. दूताचे युनिव्हर्सल डेटा प्लेन API हे व्यवहारात कसे कार्य करते याचे एक उदाहरण आहे.

मूलत:, कंट्रोल प्लेनचा उद्देश धोरण सेट करणे आहे जे शेवटी डेटा प्लेनद्वारे स्वीकारले जाईल. अधिक प्रगत नियंत्रण विमाने ऑपरेटरकडून काही प्रणालींचे अधिक भाग काढून टाकतील आणि त्यांना कमी मॅन्युअल ऑपरेशनची आवश्यकता असेल, जर ते योग्यरित्या कार्य करतात!...

डेटा प्लेन आणि कंट्रोल प्लेन. डेटा प्लेन वि. कंट्रोल प्लेन सारांश

• Плоскость данных cервисной сети (Service mesh data plane): सिस्टममधील प्रत्येक पॅकेट/विनंती प्रभावित करते. अनुप्रयोग/सेवा शोध, आरोग्य तपासणी, राउटिंग, लोड बॅलन्सिंग, प्रमाणीकरण/अधिकृतता आणि निरीक्षणासाठी जबाबदार.
• सेवा जाळी नियंत्रण विमान: सेवा नेटवर्कमधील सर्व चालू असलेल्या डेटा प्लेनसाठी धोरण आणि कॉन्फिगरेशन प्रदान करते. सिस्टमवरील कोणत्याही पॅकेजेस/विनंत्यांना स्पर्श करत नाही. कंट्रोल प्लेन सर्व डेटा प्लेनला वितरित सिस्टममध्ये बदलते.

वर्तमान प्रकल्प लँडस्केप

Разобравшись с объяснением выше, давайте посмотрим на текущее состояние проекта «сервисной сети (service mesh)».

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

वरील प्रत्येक उपायाच्या सखोल विश्लेषणात जाण्याऐवजी, मी काही मुद्दे थोडक्यात संबोधित करेन ज्यांचा मला विश्वास आहे की सध्या इकोसिस्टममध्ये गोंधळ निर्माण होत आहे.

Linkerd हे 2016 च्या सुरुवातीस सर्व्हिस मेशसाठी पहिल्या डेटा प्लेन प्रॉक्सी सर्व्हरपैकी एक होते आणि त्यांनी सर्व्हिस मेश डिझाइन मॉडेलकडे जागरूकता आणि लक्ष वाढवण्याचे उत्कृष्ट काम केले आहे. त्यानंतर सुमारे 6 महिन्यांनंतर, दूत लिंकर्डमध्ये सामील झाला (जरी तो 2015 च्या उत्तरार्धापासून लिफ्टमध्ये होता). Linkerd आणि Envoy हे दोन प्रकल्प आहेत ज्यांचा उल्लेख सर्व्हिस मेशवर चर्चा करताना केला जातो.

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

नेल्सन आणि स्मार्टस्टॅक कंट्रोल प्लेन आणि डेटा प्लेनचे वेगळेपणा स्पष्ट करण्यात मदत करतात. नेल्सन एन्वॉयचा प्रॉक्सी म्हणून वापर करतो आणि हॅशीकॉर्प स्टॅकवर आधारित सर्व्हिस मेशसाठी एक विश्वासार्ह कंट्रोल प्लेन तयार करतो, उदा. भटक्या इ. SmartStack कदाचित सेवा मेशच्या नवीन लाटेपैकी पहिले होते. SmartStack HAProxy किंवा NGINX च्या आसपास कंट्रोल प्लेन बनवते, जे डेटा प्लेनमधील सर्व्हिस मेशमधून कंट्रोल प्लेन डीकपल करण्याची क्षमता दाखवते.

सर्व्हिस मेशसह मायक्रोसर्व्हिस आर्किटेक्चर अधिकाधिक लक्ष वेधून घेत आहे (योग्यच!), आणि अधिकाधिक प्रकल्प आणि विक्रेते या दिशेने कार्य करण्यास सुरवात करत आहेत. पुढील काही वर्षांमध्ये आपण डेटा प्लेन आणि कंट्रोल प्लेन या दोन्हीमध्ये खूप नावीन्यपूर्ण काम पाहणार आहोत, तसेच विविध घटकांचे पुढील मिश्रण पाहणार आहोत. शेवटी, मायक्रोसर्व्हिस आर्किटेक्चर ऑपरेटरसाठी अधिक पारदर्शक आणि जादुई (?) बनले पाहिजे.
आशेने कमी आणि कमी चिडचिड.

महत्वाचे मुद्दे

• सर्व्हिस मेशमध्ये दोन भिन्न भाग असतात: डेटा प्लेन आणि कंट्रोल प्लेन. दोन्ही घटक आवश्यक आहेत आणि त्यांच्याशिवाय सिस्टम कार्य करणार नाही.
• Все знакомы с плоскостью управления (control plane), и на данный момент плоскостью управления (control plane) можете быть вы!
• सर्व डेटा प्लेन वैशिष्ट्ये, कार्यप्रदर्शन, कॉन्फिगरेबिलिटी आणि विस्तारक्षमता यावर एकमेकांशी स्पर्धा करतात.
• सर्व नियंत्रण विमाने वैशिष्ट्ये, कॉन्फिगरेबिलिटी, एक्स्टेंसिबिलिटी आणि वापरणी सुलभता यामध्ये एकमेकांशी स्पर्धा करतात.
• Одна плоскость управления (control plane) может содержать правильные абстракции и API, чтобы можно было использовать несколько плоскостей данных (data plane).

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