Istio सर्किट ब्रेकर: सदोष कंटेनर अक्षम करणे

सुट्ट्या संपल्या आहेत आणि आम्ही Istio Service Mesh मालिकेतील आमच्या दुसऱ्या पोस्टसह परत आलो आहोत.

आजचा विषय आहे सर्किट ब्रेकर, ज्याचा रशियन इलेक्ट्रिकल इंजिनीअरिंगमध्ये अनुवादित अर्थ आहे “सर्किट ब्रेकर”, सामान्य भाषेत – “सर्किट ब्रेकर”. केवळ Istio मध्ये हे मशीन शॉर्टेड किंवा ओव्हरलोड सर्किट डिस्कनेक्ट करत नाही, परंतु दोषपूर्ण कंटेनर.

हे आदर्शपणे कसे कार्य करावे

जेव्हा मायक्रोसर्व्हिसेस Kubernetes द्वारे व्यवस्थापित केल्या जातात, उदाहरणार्थ OpenShift प्लॅटफॉर्ममध्ये, ते लोडवर अवलंबून आपोआप वर आणि खाली स्केल करतात. मायक्रोसर्व्हिसेस पॉड्समध्ये चालत असल्यामुळे, एका एंडपॉईंटवर कंटेनराइज्ड मायक्रोसर्व्हिसची अनेक उदाहरणे असू शकतात आणि कुबर्नेट्स विनंत्यांना रूट करेल आणि त्यांच्या दरम्यान शिल्लक लोड करेल. आणि - आदर्शपणे - हे सर्व उत्तम प्रकारे कार्य केले पाहिजे.

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

ते खरोखर कसे कार्य करते

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

Istio मध्ये पूल इजेक्शन म्हणजे काय

आणि इथे Istio त्याच्या सर्किट ब्रेकर प्रोटेक्शन मशिन्ससह बचावासाठी येतो, जे पूल इजेक्शन प्रक्रियेची अंमलबजावणी करून रूटिंग आणि लोड बॅलेंसिंग रिसोर्स पूलमधून दोषपूर्ण कंटेनर तात्पुरते काढून टाकतात.

आउटलियर डिटेक्शन स्ट्रॅटेजी वापरून, Istio वक्र पॉड्स शोधते जे रेषेच्या बाहेर आहेत आणि त्यांना ठराविक वेळेसाठी रिसोर्स पूलमधून काढून टाकते, ज्याला स्लीप विंडो म्हणतात.

हे ओपनशिफ्ट प्लॅटफॉर्मवर कुबर्नेट्समध्ये कसे कार्य करते हे दाखवण्यासाठी, रेपॉजिटरीमधील उदाहरणावरून सामान्यपणे कार्यरत मायक्रोसर्व्हिसेसच्या स्क्रीनशॉटसह प्रारंभ करूया. रेड हॅट डेव्हलपर डेमो. येथे आपल्याकडे दोन पॉड्स आहेत, v1 आणि v2, प्रत्येकी एक कंटेनर चालवतो. जेव्हा Istio राउटिंग नियम वापरले जात नाहीत, तेव्हा Kubernetes समान रीतीने संतुलित राउंड-रॉबिन राउटिंगसाठी डीफॉल्ट करते:

अपघातासाठी तयार होत आहे

पूल इजेक्शन करण्यापूर्वी, तुम्हाला Istio राउटिंग नियम तयार करणे आवश्यक आहे. समजा आम्हाला 50/50 च्या प्रमाणात पॉड्समध्ये विनंत्या वितरित करायच्या आहेत. याव्यतिरिक्त, आम्ही v2 कंटेनरची संख्या एक वरून दोन पर्यंत वाढवू, जसे की:

oc scale deployment recommendation-v2 --replicas=2 -n tutorial

आता आम्ही एक राउटिंग नियम सेट करतो जेणेकरून रहदारी पॉड्समध्ये 50/50 च्या प्रमाणात वितरीत केली जाईल.

या नियमाचा परिणाम कसा दिसतो ते येथे आहे:

ही स्क्रीन 50/50 नसून 14:9 आहे, परंतु कालांतराने परिस्थिती सुधारेल या वस्तुस्थितीत तुम्हाला दोष सापडेल.

चूक करणे

आता दोन v2 कंटेनर्सपैकी एक अक्षम करू या जेणेकरून आमच्याकडे एक निरोगी v1 कंटेनर, एक निरोगी v2 कंटेनर आणि एक दोषपूर्ण v2 कंटेनर असेल:

त्रुटी निश्चित करणे

तर, आमच्याकडे सदोष कंटेनर आहे, आणि पूल इजेक्शनची वेळ आली आहे. अगदी सोप्या कॉन्फिगरेशनचा वापर करून, आम्ही हा अयशस्वी कंटेनर कोणत्याही रूटिंग स्कीममधून 15 सेकंदांसाठी वगळू या आशेने की तो निरोगी स्थितीत परत येईल (एकतर रीस्टार्ट करा किंवा कार्यप्रदर्शन पुनर्संचयित करा). हे कॉन्फिगरेशन असे दिसते आणि त्याच्या कार्याचे परिणाम:

तुम्ही बघू शकता, अयशस्वी v2 कंटेनर यापुढे राउटिंग विनंतीसाठी वापरला जाणार नाही कारण तो पूलमधून काढला गेला आहे. परंतु 15 सेकंदांनंतर ते स्वयंचलितपणे पूलमध्ये परत येईल. वास्तविक, आम्ही नुकतेच पूल इजेक्शन कसे कार्य करते ते दाखवले.

चला आर्किटेक्चर तयार करण्यास प्रारंभ करूया

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

Istio, जसे आम्ही वर लिहिले आहे, सर्किट ब्रेकर्सची संकल्पना लागू करते, ज्याने स्वतःला भौतिक जगात चांगले सिद्ध केले आहे. आणि ज्याप्रमाणे इलेक्ट्रिकल सर्किट ब्रेकर सर्किटचा एक समस्या विभाग बंद करतो, त्याचप्रमाणे Istio चे सॉफ्टवेअर सर्किट ब्रेकर जेव्हा एंडपॉईंटमध्ये काहीतरी चुकीचे असते तेव्हा विनंत्यांचा प्रवाह आणि समस्या कंटेनर दरम्यान कनेक्शन उघडतो, उदाहरणार्थ, सर्व्हर क्रॅश झाला किंवा सुरू झाला. धीमा

शिवाय, दुसर्‍या प्रकरणात फक्त आणखी समस्या आहेत, कारण एका कंटेनरच्या ब्रेकमुळे केवळ त्यामध्ये प्रवेश करणार्‍या सेवांमध्ये विलंब होत नाही आणि परिणामी, संपूर्णपणे सिस्टमची कार्यक्षमता कमी होते, परंतु पुनरावृत्ती देखील होते. आधीच मंद गतीने चालणाऱ्या सेवेला विनंती, जी परिस्थिती आणखी वाढवते.

सिद्धांतानुसार सर्किट ब्रेकर

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

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

सराव मध्ये सर्किट ब्रेकर

उदाहरणार्थ, आम्ही आमच्या शिफारस मायक्रोसर्व्हिसच्या दोन आवृत्त्या OpenShift वर चालवू. आवृत्ती 1 चांगले कार्य करेल, परंतु v2 मध्ये आम्ही सर्व्हरवरील मंदीचे अनुकरण करण्यासाठी विलंबाने तयार करू. परिणाम पाहण्यासाठी, साधन वापरा वेढा:

siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io

सर्व काही कार्य करते असे दिसते, परंतु कोणत्या किंमतीवर? पहिल्या दृष्टीक्षेपात, आमच्याकडे 100% उपलब्धता आहे, परंतु जवळून पहा - जास्तीत जास्त व्यवहार कालावधी 12 सेकंद इतका आहे. हे स्पष्टपणे एक अडथळा आहे आणि त्याचा विस्तार करणे आवश्यक आहे.

हे करण्यासाठी, धीमे कंटेनरवरील कॉल्स दूर करण्यासाठी आम्ही Istio वापरू. सर्किट ब्रेकर वापरून संबंधित कॉन्फिगरेशन असे दिसते:

httpMaxRequestsPerConnection पॅरामीटर असलेली शेवटची ओळ सूचित करते की विद्यमान कनेक्शन व्यतिरिक्त दुसरे - दुसरे - कनेक्शन तयार करण्याचा प्रयत्न करताना सोबतचे कनेक्शन डिस्कनेक्ट केले जावे. आमचा कंटेनर धीमे सेवेचे अनुकरण करत असल्याने, अशा परिस्थिती अधूनमधून उद्भवतील, आणि नंतर Istio 503 त्रुटी परत करेल, परंतु हेच सीज दर्शवेल:

ठीक आहे, आमच्याकडे सर्किट ब्रेकर आहे, पुढे काय?

म्हणून, आम्ही सेवांच्या स्त्रोत कोडला अजिबात स्पर्श न करता स्वयंचलित शटडाउन लागू केले. वर वर्णन केलेल्या सर्किट ब्रेकर आणि पूल इजेक्शन प्रक्रियेचा वापर करून, आम्ही रिसोर्स पूलमधून ब्रेक कंटेनर्स ते सामान्य होईपर्यंत काढून टाकू शकतो आणि निर्दिष्ट वारंवारतेवर त्यांची स्थिती तपासू शकतो - आमच्या उदाहरणात, हे दोन मिनिटे (स्लीपविंडो पॅरामीटर) आहे.

लक्षात ठेवा की ५०३ त्रुटीला प्रतिसाद देण्याची अनुप्रयोगाची क्षमता अद्याप स्त्रोत कोड स्तरावर सेट केलेली आहे. परिस्थितीनुसार सर्किट ब्रेकर वापरण्यासाठी अनेक धोरणे आहेत.

पुढील पोस्टमध्ये: आम्ही Istio मध्ये आधीच अंगभूत किंवा सहजपणे जोडलेल्या ट्रेसिंग आणि मॉनिटरिंगबद्दल तसेच सिस्टममध्ये जाणूनबुजून त्रुटी कशी आणायची याबद्दल बोलू.

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