Istio सर्किट ब्रेकर: दोषपूर्ण कन्टेनर असक्षम गर्दै

बिदाहरू सकिएका छन् र हामी Istio सेवा जाल श्रृंखलामा हाम्रो दोस्रो पोस्टको साथ फर्केका छौं।

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

यो कसरी आदर्श रूपमा काम गर्नुपर्छ

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

हामी सम्झन्छौं कि माइक्रो सेवाहरू साना र अल्पकालिक हुन्छन्। Ephemerality, जसको अर्थ यहाँ देखिने र गायब हुने सहजता हो, प्रायः कम आँकलन गरिन्छ। पोडमा माइक्रोसर्भिसको अर्को उदाहरणको जन्म र मृत्यु धेरै अपेक्षित चीजहरू हुन्, OpenShift र Kubernetes ले यसलाई राम्रोसँग ह्यान्डल गर्छ, र सबै कुरा राम्रो काम गर्दछ - तर फेरि सिद्धान्तमा।

यो साँच्चै कसरी काम गर्दछ

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

Istio मा पूल इजेक्शन के हो

र यहाँ Istio यसको सर्किट ब्रेकर सुरक्षा मेसिनहरूको साथ उद्धारमा आउँछ, जसले अस्थायी रूपमा राउटिंग र लोड ब्यालेन्सिङ रिसोर्स पूलबाट त्रुटिपूर्ण कन्टेनरहरू हटाउँछ, पूल इजेक्शन प्रक्रिया लागू गर्दछ।

आउटलियर पत्ता लगाउने रणनीति प्रयोग गरेर, Istio ले रेखा बाहिर भएका पोड कर्भहरू पत्ता लगाउँदछ र तिनीहरूलाई पूर्वनिर्धारित समयको लागि स्रोत पूलबाट हटाउँछ, जसलाई निद्रा विन्डो भनिन्छ।

OpenShift प्लेटफर्ममा Kubernetes मा यसले कसरी काम गर्छ भनेर देखाउन, भण्डारको उदाहरणबाट सामान्यतया काम गर्ने माइक्रोसर्भिसेसहरूको स्क्रिनसटको साथ सुरु गरौं। Red Hat विकासकर्ता डेमो। यहाँ हामीसँग दुईवटा पोडहरू छन्, v1 र v2, प्रत्येकमा एउटा कन्टेनर चलिरहेको छ। जब Istio राउटिंग नियमहरू प्रयोग गरिँदैन, Kubernetes पूर्वनिर्धारित समान सन्तुलित राउन्ड-रोबिन रूटिङमा:

दुर्घटनाको लागि तयारी गर्दै

पूल इजेक्शन गर्नु अघि, तपाईंले Istio रूटिङ नियम सिर्जना गर्न आवश्यक छ। मानौं हामी ५०/५० अनुपातमा पोडहरू बीच अनुरोधहरू वितरण गर्न चाहन्छौं। थप रूपमा, हामी v50 कन्टेनरहरूको संख्या एकबाट दुईमा बढाउनेछौं, जस्तै:

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

अब हामीले रुटिङ नियम सेट गर्छौं ताकि ट्राफिक पोडहरू बीच 50/50 अनुपातमा वितरण गरिन्छ।

यहाँ यो नियमको परिणाम कस्तो देखिन्छ:

तपाईंले यो स्क्रिन 50/50 होइन, तर 14:9 हो, तर समयसँगै स्थितिमा सुधार आउनेछ भन्ने तथ्यमा त्रुटि फेला पार्न सक्नुहुन्छ।

गडबडी गर्दै

अब दुई v2 कन्टेनरहरू मध्ये एउटा असक्षम गरौं ताकि हामीसँग एउटा स्वस्थ v1 कन्टेनर, एउटा स्वस्थ v2 कन्टेनर र एउटा त्रुटिपूर्ण v2 कन्टेनर छ:

त्रुटि फिक्स गर्दै

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

तपाईंले देख्न सक्नुहुने रूपमा, असफल v2 कन्टेनर अब रुटिङ अनुरोधहरूको लागि प्रयोग गरिँदैन किनभने यो पूलबाट हटाइएको छ। तर १५ सेकेन्ड पछि यो स्वतः पोखरीमा फर्किनेछ। वास्तवमा, हामीले भर्खरै पोल इजेक्शनले कसरी काम गर्छ भनेर देखायौं।

वास्तुकला निर्माण सुरु गरौं

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

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

यसबाहेक, दोस्रो अवस्थामा त्यहाँ थप समस्याहरू छन्, किनकि एउटा कन्टेनरको ब्रेकले यसलाई पहुँच गर्ने सेवाहरूमा ढिलाइको कास्केड मात्र बनाउँदैन र नतिजाको रूपमा, समग्र रूपमा प्रणालीको कार्यसम्पादन घटाउँछ, तर दोहोर्याइएको पनि उत्पन्न गर्दछ। पहिले नै ढिलो चलिरहेको सेवाको लागि अनुरोध गर्दछ, जसले स्थितिलाई मात्र बढाउँछ।

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

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

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

अभ्यासमा सर्किट ब्रेकर

उदाहरणका लागि, हामी OpenShift मा हाम्रो सिफारिस माइक्रोसर्भिसको दुई संस्करणहरू चलाउनेछौं। संस्करण 1 ले राम्रो काम गर्नेछ, तर v2 मा हामी सर्भरमा ढिलो सिमुलेट गर्न ढिलाइमा निर्माण गर्नेछौं। परिणामहरू हेर्न, उपकरण प्रयोग गर्नुहोस् घेराबन्दी:

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

सबै काम लाग्छ, तर कुन मूल्यमा? पहिलो नजरमा, हामीसँग 100% उपलब्धता छ, तर नजिकबाट हेर्नुहोस् - अधिकतम लेनदेन अवधि 12 सेकेन्ड जति छ। यो स्पष्ट रूपमा एक अवरोध हो र विस्तार गर्न आवश्यक छ।

यो गर्नको लागि, हामी ढिलो कन्टेनरहरूमा कलहरू हटाउन Istio प्रयोग गर्नेछौं। यो सर्किट ब्रेकर प्रयोग गरेर सम्बन्धित कन्फिगरेसन जस्तो देखिन्छ:

httpMaxRequestsPerConnection प्यारामिटरको साथको अन्तिम रेखाले अवस्थित एकको अतिरिक्त अर्को - दोस्रो - जडान सिर्जना गर्ने प्रयास गर्दा जडान विच्छेद हुनुपर्छ भन्ने संकेत गर्दछ। हाम्रो कन्टेनरले ढिलो सेवाको नक्कल गर्ने भएकोले, त्यस्ता अवस्थाहरू आवधिक रूपमा देखा पर्नेछ, र त्यसपछि Istio ले 503 त्रुटि फिर्ता गर्नेछ, तर यो के हो घेराबन्दीले देखाउनेछ:

ठीक छ, हामीसँग सर्किट ब्रेकर छ, अब के छ?

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

नोट गर्नुहोस् कि 503 त्रुटिमा प्रतिक्रिया दिने अनुप्रयोगको क्षमता अझै पनि स्रोत कोड स्तरमा सेट गरिएको छ। परिस्थितिमा निर्भर गर्दै सर्किट ब्रेकर प्रयोग गर्नका लागि धेरै रणनीतिहरू छन्।

अर्को पोस्टमा: हामी ट्रेसिङ र निगरानीको बारेमा कुरा गर्नेछौं जुन पहिले नै निर्मित वा सजिलैसँग Istio मा थपिएको छ, साथै प्रणालीमा जानाजानी त्रुटिहरू कसरी परिचय गर्ने भनेर।

स्रोत: www.habr.com