🧑🏼 🙍🏻 👩🏽‍🎓 इस्टियो के साथ वापस माइक्रोसोर्विस के लिए। भाग २ 👶🏽 👃🏾 ↔️

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

हम आपको यह भी याद दिलाते हैं कि लेख istio-mastery रिपॉजिटरी से कॉन्फ़िगरेशन (कुबेरनेट्स और इस्तियो के लिए मैनिफ़ेस्ट्स) का उपयोग करता है।

यातायात प्रबंधन

Istio के साथ, प्रदान करने के लिए क्लस्टर में नई सुविधाएँ दिखाई देती हैं:

गतिशील क्वेरी रूटिंग : कैनरी रोलआउट, ए / बी परीक्षण;
भार संतुलन : हैश के आधार पर सरल और सुसंगत;
गिरावट की रिकवरी : टाइमआउट, रिट्रीट, सर्किट ब्रेकर;
दोष इनपुट : विलंब, अनुरोधों का व्यवधान, आदि।

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

ए / बी टेस्टिंग: डेस्टिनेशनरल्स इन प्रैक्टिस

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

ए / बी परीक्षण प्रदर्शित करने के लिए आवश्यक सीमांत के दूसरे संस्करण को तैनात करने के लिए, निम्नलिखित कमांड चलाएं:

 $ kubectl apply -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml deployment.extensions/sa-frontend-green created

"ग्रीन संस्करण" के लिए परिनियोजन प्रकटन दो स्थानों में भिन्न है:

छवि एक अन्य टैग पर आधारित है - istio-green ,
फली का एक version: green लेबल।

चूंकि दोनों परिनियोजन में app: sa-frontend लेबल, app: sa-frontend sa-external-services वर्चुअल सेवा द्वारा sa-frontend सेवा में रूट किए गए अनुरोधों को इसके सभी उदाहरणों पर पुनर्निर्देशित किया जाएगा और लोड को राउंड-रॉबिन एल्गोरिथ्म का उपयोग करके वितरित किया जाएगा, जो निम्न स्थिति को जन्म देगा:

अनुरोधित फ़ाइलें नहीं मिलीं

इन फ़ाइलों को इस तथ्य के कारण नहीं पाया गया कि उन्हें आवेदन के विभिन्न संस्करणों में अलग-अलग रूप में कहा जाता है। आइए इस बारे में सुनिश्चित करें:

 $ curl --silent http://$EXTERNAL_IP/ | tr '"' '\n' | grep main /static/css/main.c7071b22.css /static/js/main.059f8e9c.js $ curl --silent http://$EXTERNAL_IP/ | tr '"' '\n' | grep main /static/css/main.f87cd8c9.css /static/js/main.f7659dbb.js

इसका मतलब यह है कि index.html , स्थैतिक फ़ाइलों के एक संस्करण का अनुरोध करते हुए, लोड बैलेंसर द्वारा उन पॉड्स में भेजा जा सकता है जिनके पास एक अलग संस्करण है, जहां, स्पष्ट कारणों के लिए, ऐसी फाइलें मौजूद नहीं हैं। इसलिए, एप्लिकेशन को काम करने के लिए, हमें प्रतिबंध लगाने की आवश्यकता है: " एप्लिकेशन का वही संस्करण जिसने index.html दिया था, उसे बाद के अनुरोधों को भी पूरा करना होगा ।"

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

DestinationRules

बाद VirtualService वांछित सेवा के लिए एक अनुरोध भेजा है, DestinationRules का उपयोग कर हम उन नीतियों को निर्धारित कर सकते हैं जो इस सेवा के उदाहरणों के लिए नियत ट्रैफ़िक पर लागू होंगी:

इस्टियो रिसोर्स ट्रैफिक मैनेजमेंट

नोट : नेटवर्क ट्रैफ़िक पर Istio संसाधनों का प्रभाव यहाँ सरलीकृत तरीके से प्रस्तुत किया गया है। सटीक होने के लिए, जिस अनुरोध पर अनुरोध भेजने के लिए इंवॉय गेटवे द्वारा सीआरडी में कॉन्फ़िगर किया गया है, उस पर निर्णय।

गंतव्य नियमों का उपयोग करते हुए, हम लोड संतुलन को कॉन्फ़िगर कर सकते हैं ताकि लगातार हैश का उपयोग किया जाए और एक ही सेवा उदाहरण से प्रतिक्रियाओं की गारंटी उसी उपयोगकर्ता को दी जाए। निम्नलिखित कॉन्फ़िगरेशन इसे प्राप्त करने की अनुमति देता है ( गंतव्य-सा-सामने-दृश्य )

 apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: sa-frontend spec: host: sa-frontend trafficPolicy: loadBalancer: consistentHash: httpHeaderName: version # 1

1 - HTTP version हैडर के कंटेंट के आधार पर हैश जनरेट किया जाएगा।

निम्नलिखित कमांड के साथ कॉन्फ़िगरेशन लागू करें:

 $ kubectl apply -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml destinationrule.networking.istio.io/sa-frontend created

अब नीचे दिए गए कमांड को चलाएं और सुनिश्चित करें कि version हेडर निर्दिष्ट करते समय आपको अपनी आवश्यक फाइलें मिलेंगी:

 $ curl --silent -H "version: yogo" http://$EXTERNAL_IP/ | tr '"' '\n' | grep main

नोट : हेडर में विभिन्न मूल्यों को जोड़ने के लिए और सीधे ब्राउज़र में परिणामों का परीक्षण करने के लिए, आप इस एक्सटेंशन का उपयोग Chrome (या फ़ायरफ़ॉक्स के लिए यह लगभग - ट्रांसलेशन।) कर सकते हैं ।

सामान्य तौर पर, गंतव्य संतुलन लोड संतुलन के क्षेत्र में अधिक विकल्प हैं - विवरण के लिए आधिकारिक दस्तावेज की जांच करें।

VirtualService का आगे अध्ययन करने से पहले, हम निम्नलिखित आदेशों को निष्पादित करके ट्रैफ़िक की दिशा में एप्लिकेशन और संबंधित नियम के "हरे संस्करण" को हटा देंगे:

 $ kubectl delete -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml deployment.extensions “sa-frontend-green” deleted $ kubectl delete -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml destinationrule.networking.istio.io “sa-frontend” deleted

मिररिंग: वर्चुअल सर्विसेज इन प्रैक्टिस

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

कार्रवाई में इस परिदृश्य का परीक्षण करने के लिए, निम्नलिखित कमांड चलाकर बग्स ( buggy ) के साथ एसए-लॉजिक का दूसरा उदाहरण बनाएं:

 $ kubectl apply -f resource-manifests/kube/shadowing/sa-logic-service-buggy.yaml deployment.extensions/sa-logic-buggy created

और अब हम यह सुनिश्चित करने के लिए कमांड निष्पादित करते हैं कि app=sa-logic साथ सभी उदाहरण app=sa-logic में संबंधित संस्करणों के साथ लेबल app=sa-logic हैं:

 $ kubectl get pods -l app=sa-logic --show-labels NAME READY LABELS sa-logic-568498cb4d-2sjwj 2/2 app=sa-logic,version=v1 sa-logic-568498cb4d-p4f8c 2/2 app=sa-logic,version=v1 sa-logic-buggy-76dff55847-2fl66 2/2 app=sa-logic,version=v2 sa-logic-buggy-76dff55847-kx8zz 2/2 app=sa-logic,version=v2

sa-logic app=sa-logic लेबल के साथ पॉड्स को लक्षित करती है, इसलिए सभी अनुरोधों को सभी उदाहरणों में वितरित किया जाएगा:

... लेकिन हम चाहते हैं कि संस्करण v1 के साथ उदाहरणों के लिए निर्देशित किया जाए और संस्करण v2 के साथ उदाहरणों को प्रतिबिंबित किया जाए:

हम VirtualService के माध्यम से डेस्टिनेशन नियम के साथ संयोजन में इसे प्राप्त करेंगे, जहां नियम किसी विशेष सबसेट के लिए VirtualService के सबसेट और मार्गों को निर्धारित करेंगे।

डेस्टिनेशन रूल्स में सब्जेक्ट्स को परिभाषित करना

सबस्क्रिप्शन को निम्न कॉन्फ़िगरेशन ( sa- तर्क-उपसमुच्चय-गंतव्य- श्याम) द्वारा परिभाषित किया गया है:

 apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: sa-logic spec: host: sa-logic # 1 subsets: - name: v1 # 2 labels: version: v1 # 3 - name: v2 labels: version: v2

host निर्धारित host है कि यह नियम केवल उन मामलों पर लागू होता है जब मार्ग sa-logic ओर जाता है;
सबसेट के उदाहरणों को रूट करते समय सबसेट का नाम उपयोग किया जाता है;
एक लेबल कुंजी-मूल्य वाले जोड़े को परिभाषित करता है जो एक उपसमुच्चय का हिस्सा बनने के लिए उदाहरणों से मेल खाना चाहिए।

निम्नलिखित कमांड के साथ कॉन्फ़िगरेशन लागू करें:

 $ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-destinationrule.yaml destinationrule.networking.istio.io/sa-logic created

अब जब सबसेट परिभाषित हो जाते हैं, तो आप वर्चुअल-सेवा को स्थानांतरित कर सकते हैं और सा-लॉजिक के अनुरोधों के लिए नियमों को लागू करने के लिए कॉन्फ़िगर कर सकते हैं ताकि:

v1 सबसेट पर रूट किया गया,
v2 सबसेट के लिए दिखाया गया है।

निम्नलिखित प्रकटन आपको अपनी योजना ( सा-लॉजिक-सब्मिट-शैडोइंग-बनाम याम्ल ) प्राप्त करने की अनुमति देता है ।

 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: sa-logic spec: hosts: - sa-logic http: - route: - destination: host: sa-logic subset: v1 mirror: host: sa-logic subset: v2

यहां कोई स्पष्टीकरण की आवश्यकता नहीं है, इसलिए कार्रवाई पर एक नज़र डालें:

 $ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-shadowing-vs.yaml virtualservice.networking.istio.io/sa-logic created

इस आदेश को कॉल करके लोड जोड़ें:

 $ while true; do curl -v http://$EXTERNAL_IP/sentiment \ -H "Content-type: application/json" \ -d '{"sentence": "I love yogobella"}'; \ sleep .8; done

आइए ग्राफ्ना में परिणामों को देखें, जहां हम देख सकते हैं कि अनुरोध के 60% के लिए buggy संस्करण दुर्घटनाग्रस्त हो जाता है, लेकिन इनमें से कोई भी क्रैश अंतिम उपयोगकर्ताओं को प्रभावित नहीं करता है क्योंकि उनके पास एक कार्यशील सेवा है।

सा-लॉजिक सेवा के विभिन्न संस्करणों की प्रतिक्रियाओं की सफलता

यहां हमने पहली बार देखा कि कैसे VirtualService को हमारी सेवाओं के दूतों पर लागू किया जाता है: जब sa-web-app sa-logic लिए अनुरोध करता है, तो यह sidecar Envoy से होकर गुजरता है, जो - VirtualService के माध्यम से - सबसेट v1 और दर्पण के अनुरोध को रूट करने के लिए कॉन्फ़िगर किया गया है sa- sa-logic के v2 के सबसेट के लिए एक अनुरोध।

मुझे पता है: आपके पास पहले से ही सोचने का समय था कि वर्चुअल सर्विसेज सरल हैं। अगले भाग में, हम इस दृष्टिकोण से इस तथ्य का विस्तार करते हैं कि वे वास्तव में शानदार हैं।

कैनरी रोल

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

कैनरी रोलआउट प्रदर्शित करने के लिए, हम sa-logic में buggy सबसेट के साथ काम करना जारी रखेंगे।

चलो उस पर समय बर्बाद न करें और तुरंत 20% उपयोगकर्ताओं को बग के साथ संस्करण में भेजें (यह हमारे कैनरी रोलआउट का प्रतिनिधित्व करेगा), और शेष 80% सामान्य सेवा के लिए। ऐसा करने के लिए, निम्नलिखित VirtualService ( sa- तर्क-उपसमुच्चय-कैनरी-डिसमिल ) लागू करें:

 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: sa-logic spec: hosts: - sa-logic http: - route: - destination: host: sa-logic subset: v1 weight: 80 # 1 - destination: host: sa-logic subset: v2 weight: 20 # 1

1 वजन है, जो अनुरोधों का प्रतिशत निर्धारित करता है जो प्राप्तकर्ता को भेजा जाएगा या प्राप्तकर्ता का सबसेट।

निम्न आदेश के sa-logic sa- sa-logic लिए पिछले VirtualService कॉन्फ़िगरेशन अद्यतन करें:

 $ kubectl apply -f resource-manifests/istio/canary/sa-logic-subsets-canary-vs.yaml virtualservice.networking.istio.io/sa-logic configured

... और तुरंत अनुरोधों के उस हिस्से को देखें:

 $ while true; do \ curl -i http://$EXTERNAL_IP/sentiment \ -H "Content-type: application/json" \ -d '{"sentence": "I love yogobella"}' \ --silent -w "Time: %{time_total}s \t Status: %{http_code}\n" \ -o /dev/null; sleep .1; done Time: 0.153075s Status: 200 Time: 0.137581s Status: 200 Time: 0.139345s Status: 200 Time: 30.291806s Status: 500

VirtualServices कैनरी रोलआउट को सक्रिय करता है: इस मामले में, हमने समस्याओं के संभावित परिणामों को उपयोगकर्ता आधार के 20% तक सीमित कर दिया। वाह! अब, प्रत्येक मामले में, जब हम अपने कोड के बारे में सुनिश्चित नहीं होते हैं (दूसरे शब्दों में, हमेशा ...), हम मिररिंग और कैनिंग रोलआउट का उपयोग कर सकते हैं।

समय और रिट्रीट

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

प्रदर्शन के लिए, हम sa-logic ( buggy ) के sa-logic ही संस्करण का उपयोग करना जारी रखेंगे, और हम यादृच्छिक विफलताओं के साथ नेटवर्क अविश्वसनीयता का अनुकरण करेंगे।

आइए बग्स के साथ हमारी सेवा में एक प्रतिक्रिया के लिए 1/3 मौका है जो बहुत लंबा है, आंतरिक सर्वर त्रुटि के साथ पूरा करने के लिए 1/3, और एक सफल पृष्ठ वापसी के लिए 1/3।

ऐसी समस्याओं के परिणामों को कम करने और उपयोगकर्ताओं के लिए जीवन को बेहतर बनाने के लिए, हम कर सकते हैं:

यदि सेवा 8 सेकंड से अधिक समय तक प्रतिक्रिया करती है, तो एक टाइमआउट जोड़ें;
अनुरोध विफल होने पर पुनः प्रयास करें।

कार्यान्वयन के लिए, हम निम्नलिखित संसाधन परिभाषा ( सा-लॉजिक-रिट्रीज़-टाइमआउट-डिसमिल ) का उपयोग करेंगे:

 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: sa-logic spec: hosts: - sa-logic http: - route: - destination: host: sa-logic subset: v1 weight: 50 - destination: host: sa-logic subset: v2 weight: 50 timeout: 8s # 1 retries: attempts: 3 # 2 perTryTimeout: 3s # 3

अनुरोध का समयबाह्य 8 सेकंड के लिए सेट है;
बार-बार अनुरोध के प्रयास 3 बार किए जाते हैं;
और प्रत्येक प्रयास को असफल माना जाता है यदि प्रतिक्रिया समय 3 सेकंड से अधिक हो।

इसलिए हमने अनुकूलन प्राप्त कर लिया है, क्योंकि उपयोगकर्ता को 8 सेकंड से अधिक इंतजार नहीं करना पड़ता है और हम विफलताओं के मामले में जवाब पाने के लिए तीन नए प्रयास करेंगे, जिससे एक सफल प्रतिक्रिया की संभावना बढ़ जाएगी।

निम्नलिखित कमांड के साथ अद्यतन कॉन्फ़िगरेशन लागू करें:

 $ kubectl apply -f resource-manifests/istio/retries/sa-logic-retries-timeouts-vs.yaml virtualservice.networking.istio.io/sa-logic configured

और ग्राफाना के ग्राफ में देखें कि सफल उत्तरों की संख्या खत्म हो गई है:

टाइमआउट और रिट्रीट जोड़ने के बाद सफल प्रतिक्रियाओं के आंकड़ों में सुधार

अगले भाग (या बल्कि, लेख के अगले भाग पर आगे बढ़ने से पहले , क्योंकि इस आदेश में लगभग कोई प्रयोग नहीं होगा - लगभग। अनुवाद।) , निम्न आदेशों को चलाकर sa- sa-logic-buggy और VirtualService को हटा दें:

 $ kubectl delete deployment sa-logic-buggy deployment.extensions “sa-logic-buggy” deleted $ kubectl delete virtualservice sa-logic virtualservice.networking.istio.io “sa-logic” deleted

सर्किट ब्रेकर और बल्कहेड पैटर्न

हम दो महत्वपूर्ण पैटर्न के बारे में बात कर रहे हैं, जो कि आप सेल्फ-हीलिंग सेवाओं को प्राप्त कर सकते हैं।

सर्किट ब्रेकर ("सर्किट ब्रेकर") का उपयोग किसी ऐसी सेवा के उदाहरण के लिए आने वाले अनुरोधों को रोकने के लिए किया जाता है जिसे अस्वस्थ माना जाता है और इसे पुनर्स्थापित किया जाता है जबकि ग्राहक अनुरोधों को इस सेवा के स्वस्थ उदाहरणों (जो सफल प्रतिक्रियाओं का प्रतिशत बढ़ाता है) पर पुनर्निर्देशित किया जाता है। (नोट: पैटर्न का अधिक विस्तृत विवरण पाया जा सकता है, उदाहरण के लिए, यहाँ ।)

बल्कहेड ("विभाजन") पूरे सिस्टम की हार से सेवा विफलताओं को अलग करता है। उदाहरण के लिए, सेवा बी टूट गया है, और एक अन्य सेवा (सेवा बी का ग्राहक) सेवा बी से एक अनुरोध करता है, जिसके परिणामस्वरूप यह अपने थ्रेड पूल का उपयोग करेगा और अन्य अनुरोधों की सेवा करने में सक्षम नहीं होगा (भले ही वे सेवा बी से संबंधित न हों)। (नोट: पैटर्न का अधिक विस्तृत विवरण पाया जा सकता है, उदाहरण के लिए, यहाँ ।)

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

अनुवादक से पी.एस.

हमारे ब्लॉग में भी पढ़ें:

"इस्टियो के साथ माइक्रोस्क्राइबर पर वापस": भाग 1 (मुख्य विशेषताओं के साथ परिचितता) , भाग 3 (प्रमाणीकरण और प्राधिकरण) ;
" नाली - कुबेरनेट्स के लिए एक हल्का सेवा जाल ";
“ एक सेवा जाल क्या है और मुझे इसकी आवश्यकता क्यों है [microservices के साथ क्लाउड अनुप्रयोग के लिए]? "।

इस्टियो के साथ वापस माइक्रोसोर्विस के लिए। भाग २