कुबेरनेट्स और इस्तियो के साथ माइक्रोसोर्स्ट मैनेजमेंट

Microservices के फायदे और नुकसान के बारे में एक छोटी कहानी, सेवा जाल अवधारणा और Google उपकरण जो आपको नीतियों, एक्सेस और प्रमाणपत्रों की अंतहीन सेटिंग्स के साथ अपने सिर को बंद किए बिना microservice एप्लिकेशन चलाने की अनुमति देते हैं और कोड में नहीं बल्कि त्रुटियों को छिपाते हुए त्रुटियां ढूंढते हैं।



यह लेख हमारे पिछले साल के DevOops 2017 सम्मेलन में क्रेग बॉक्स की रिपोर्ट पर आधारित है। रिपोर्ट के वीडियो और अनुवाद में कटौती की जा रही है।


क्रेग बॉक्स (क्रेग बॉक्स, ट्विटर ) - माइक्रोसॉफ़्ट और कुबेरनेट्स और इस्तियो टूल के प्रभारी Google के DevRel। उनकी वर्तमान कहानी इन प्लेटफार्मों पर microservices के प्रबंधन के बारे में है।

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



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

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

हमें यह सुनिश्चित करना चाहिए कि सेवाओं के बीच यातायात तुच्छ हमलों से सुरक्षित है। म्यूचुअल टीएलएस प्रमाणीकरण की आवश्यकता होती है, लेकिन हर एप्लिकेशन में उपयुक्त मॉड्यूल को एम्बेड किए बिना जो हम लिखते हैं। यह नियंत्रित करने में सक्षम होना महत्वपूर्ण है कि हमारे एप्लिकेशन न केवल कनेक्शन स्तर पर, बल्कि उच्च स्तर पर भी घेरे हुए हैं।

सेवा मेष एक परत है जो हमें एक माइक्रो-सेवा वातावरण में उपरोक्त समस्याओं को हल करने की अनुमति देती है।

मोनोलिथ और माइक्रोसर्विसेज: पेशेवरों और विपक्ष

लेकिन पहले हम खुद से पूछते हैं, हमें इन समस्याओं को क्यों हल करना चाहिए? हमने पहले सॉफ्टवेयर डेवलपमेंट कैसे किया? हमारे पास एक एप्लिकेशन था जो कुछ इस तरह दिखता था - एक मोनोलिथ की तरह।



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



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

परिणाम क्या है?



हमने वास्तव में बहुत अच्छा दिखने के लिए विशाल ऐप की दुनिया को छोड़ दिया। हमने विकास को गति दी, आंतरिक विधियों का उपयोग करना बंद कर दिया, सेवाओं का निर्माण किया और अब हम उन्हें स्वतंत्र रूप से स्केल कर सकते हैं, बाकी सब को समेकित किए बिना सेवा को बड़ा बना सकते हैं। लेकिन जो बदलाव हमने खोया है उसकी कीमत क्या है?



हमारे पास अनुप्रयोगों के अंदर विश्वसनीय कॉल थीं क्योंकि आपने बस एक फ़ंक्शन या मॉड्यूल कहा था। हमने एक अविश्वसनीय दूरस्थ प्रक्रिया कॉल के साथ मॉड्यूल के अंदर विश्वसनीय कॉल को बदल दिया। लेकिन दूसरी तरफ सेवा हमेशा उपलब्ध नहीं होती है।

हम एक ही मशीन के अंदर एक ही प्रक्रिया का उपयोग कर, सुरक्षित थे। अब हम उन सेवाओं से जुड़ रहे हैं जो अलग-अलग मशीनों पर और एक अविश्वसनीय नेटवर्क पर हो सकती हैं।

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

क्या किया जा सकता है?

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

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

Istio

इस्तियो की बात करो।



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



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



इस स्थिति का चित्र के रूप में प्रतिनिधित्व किया जा सकता है। एक उदाहरण पर विचार करें जब हमारे पास एक तंत्र है जो कुछ छवि प्रसंस्करण करता है। बाईं ओर का उपयोगकर्ता ट्रैफ़िक है, जिसमें से हमारे पास माइक्रोसेवा आता है।

उपयोगकर्ता से भुगतान स्वीकार करने के लिए, हमारे पास एक अलग भुगतान माइक्रोसर्विस है जो एक बाहरी एपीआई को कॉल करता है जो क्लस्टर के बाहर स्थित है।

उपयोगकर्ता लॉगिन को संसाधित करने के लिए, हम एक प्रमाणीकरण microservice प्रदान करते हैं, और यह क्लाउड SQL डेटाबेस में हमारे क्लस्टर के बाहर फिर से संग्रहीत होता है ।

इस्तियो क्या करता है? इस्तियो कुबेरनेट्स में सुधार करता है। आप इसे Kubernetes में एक अल्फ़ा फंक्शन का उपयोग करके इंस्टॉल करते हैं, जिसे Initializer कहा जाता है। जब आप सॉफ़्टवेयर को तैनात करते हैं, तो कुबेरनेट्स इसे नोटिस करेंगे और पूछेंगे कि क्या हम प्रत्येक कुबेरनेट्स के अंदर एक और कंटेनर बदलना और जोड़ना चाहते हैं। यह कंटेनर पथ और रूटिंग को संभालेगा, सभी एप्लिकेशन परिवर्तनों से अवगत रहें।

यह कैसे सर्किट इस्तियो के साथ दिखता है।



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

सभी ट्रैफ़िक अब बाहरी मशीनों पर प्रॉक्सी सर्वर के माध्यम से जाएंगे, और सीधे सेवाओं पर नहीं। कुबेरनेट्स एक ही आईपी पते पर सब कुछ करता है। हम ऐसे ट्रैफ़िक को रोक पाएंगे जो आगे या अंत की सेवाओं तक जाएगा।

Istio का उपयोग करने वाले बाहरी प्रॉक्सी को Envoy कहा जाता है।



एनवॉय वास्तव में इस्टियो से अधिक पुराना है, इसे Lyft में विकसित किया गया था। एक वर्ष से अधिक समय से उत्पादन में काम कर रहा है, माइक्रोसेवा के पूरे बुनियादी ढांचे को लॉन्च कर रहा है। हमने समुदाय के सहयोग से इस्तियो परियोजना के लिए दूत चुना। इस प्रकार, Google, IBM और LYFT तीन कंपनियां हैं जो अभी भी इस पर काम कर रही हैं।

Envoy C ++ 11. में लिखा गया है, यह एक ओपन सोर्स प्रोजेक्ट बनने से पहले 18 महीनों से अधिक समय से उत्पादन में है। जब आप इसे अपनी सेवाओं से जोड़ते हैं तो यह बहुत अधिक संसाधन नहीं लेगा।

यहाँ कुछ चीजें हैं जो दूत कर सकता है। यह HTTP के लिए एक प्रॉक्सी सर्वर का निर्माण है, जिसमें HTTP / 2 और इसके आधार पर प्रोटोकॉल शामिल हैं, जैसे gRPC। यह बाइनरी स्तर पर अन्य प्रोटोकॉल के लिए भी अग्रेषित कर सकता है। दूत आपके बुनियादी ढांचे के क्षेत्र को नियंत्रित करता है ताकि आप अपने हिस्से को स्वायत्त बना सकें। यह रिट्रीट और प्रतीक्षा के साथ बड़ी संख्या में नेटवर्क कनेक्शन को संभाल सकता है। आप कॉल को रोकने से पहले सर्वर से कनेक्ट करने के लिए कुछ निश्चित प्रयासों को सेट कर सकते हैं और अपने सर्वर को जानकारी संचारित कर सकते हैं कि सेवा जवाब नहीं दे रही है।

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

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



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

मिक्सर प्रक्रिया यह सुनिश्चित करने के लिए अनुरोध करती है कि आप सुरक्षा नीति का अनुपालन करते हैं, और फिर टेलीमेट्री सूचना प्रसारित करता है। एप्लिकेशन में कोई भी बदलाव किए बिना, हम वह सब कुछ देख सकते हैं जो हमारे क्लस्टर के अंदर होता है।

इस्तियो के फायदे

तो, आइए हम इस्तियो से प्राप्त होने वाली पांच चीजों के बारे में अधिक विस्तार से बात करेंगे। सबसे पहले, यातायात प्रबंधन पर विचार करें । हम इंफ्रास्ट्रक्चर स्केलिंग से ट्रैफिक कंट्रोल को अलग कर सकते हैं, इसलिए पहले हम आवेदन के 20 उदाहरणों की तरह कुछ कर सकते थे और उनमें से 19 पुराने संस्करण पर होंगे, और एक नए पर, यानी 5% ट्रैफिक नए संस्करण पर होगा। इस्तियो के साथ, हम किसी भी संख्या में ऐसे उदाहरणों को तैनात कर सकते हैं जिनकी हमें आवश्यकता है, और साथ ही यह इंगित करता है कि नए संस्करणों में कितने प्रतिशत ट्रैफ़िक भेजा जाना चाहिए। जुदाई का एक सरल नियम।

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



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

दूसरा फायदा पारदर्शिता का है । जब आप क्लस्टर के अंदर का दृश्य देखते हैं, तो आप समझ सकते हैं कि यह कैसे बनाया जाता है। हमें विकास प्रक्रिया में मैट्रिक्स के लिए उपकरण बनाने की आवश्यकता नहीं है। हर घटक में मेट्रिक्स पहले से हैं।

कुछ का मानना ​​है कि निगरानी के लिए लॉग रिकॉर्ड रखना काफी पर्याप्त है। लेकिन वास्तव में, हम सभी को संकेतक के ऐसे सार्वभौमिक सेट की आवश्यकता होती है जिसे किसी भी निगरानी सेवा को खिलाया जा सकता है।



इस प्रकार से प्रोमेथियस सेवा का उपयोग करके बनाया गया इस्तियो टूलबार दिखता है। इसे क्लस्टर के अंदर तैनात करना याद रखें।

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



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



आवेदन स्तर पर, ट्रेस बनाने के बारे में चिंता करने की बहुत कम आवश्यकता है। एनवॉय खुद ही मिक्सर को सभी आवश्यक जानकारी देता है, जो इसे ट्रेस को भेजता है, उदाहरण के लिए, जिपकिन के लिए, Google या किसी अन्य उपयोगकर्ता एप्लिकेशन से स्टैकड्राइवर ट्रेस ।

चलो गलती सहिष्णुता और दक्षता के बारे में बात करते हैं।


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



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

आइए अब देखें कि दक्षता के साथ क्या है। कुबेरनेट्स बैलेंसर स्वयं केवल चौथी परत के स्तर पर कार्य करता है। हमने दूसरी परत से सातवें तक लोड संतुलन के लिए एक इनपुट कंस्ट्रक्टर का आविष्कार किया। इस्तियो को नेटवर्क सेवाओं की पहुंच के साथ नेटवर्क लेयर के लिए एक बैलेंसर के रूप में लागू किया गया है।

हम TLS-offloading करते हैं, इसलिए हम Envoy में आधुनिक अच्छी तरह से डोप किए गए SSL का उपयोग करते हैं, इसलिए आपको कमजोरियों के बारे में चिंता करने की ज़रूरत नहीं है।

इस्तियो का एक और फायदा सुरक्षा है ।



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

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

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

, , , , ICL . , , , , . , Mixer , . .



, Istio? . . , . , .

Istio

Istio kubernetes, , , 1.7 . - kubernetes. Google Container Engine Alpha clusters. , .

Istio — github. 0.2. 0.1 kubernetes. 0.2 kubernetes. , . Envoy , . Istio , Cloud Foundry .

. Google Container Engine 1.8 -, Istio — .

, 14 DevOops 2018 (): , .