🥇इस्तियो के साथ माइक्रोसर्विसेज पर वापस जाएं। भाग 2

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

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

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

इस्तियो के साथ, क्लस्टर में प्रदान करने के लिए नई क्षमताएँ दिखाई देती हैं:

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

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

ए/बी परीक्षण: व्यवहार में गंतव्य नियम

ए/बी परीक्षण का उपयोग उन मामलों में किया जाता है जहां किसी एप्लिकेशन के दो संस्करण होते हैं (आमतौर पर वे दृष्टिगत रूप से भिन्न होते हैं) और हम 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,अनुरोध वर्चुअल सेवा द्वारा रूट किए गए 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 का उपयोग करके हम उन नीतियों को परिभाषित कर सकते हैं जो इस सेवा के उदाहरणों के लिए नियत ट्रैफ़िक पर लागू की जाएंगी:

इस्तियो संसाधनों के साथ यातायात प्रबंधन

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

गंतव्य नियमों के साथ, हम लगातार हैश का उपयोग करने के लिए लोड संतुलन को कॉन्फ़िगर कर सकते हैं और यह सुनिश्चित कर सकते हैं कि एक ही सेवा उदाहरण एक ही उपयोगकर्ता को प्रतिक्रिया देता है। निम्नलिखित कॉन्फ़िगरेशन आपको इसे प्राप्त करने की अनुमति देता है (डेस्टिनेशनरूल-sa-frontend.yaml):

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

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

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

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

$ 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

मिररिंग: व्यवहार में आभासी सेवाएँ

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

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

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

और अब यह सुनिश्चित करने के लिए कमांड चलाएँ कि सभी उदाहरण 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 इंस्टेंसेस पर प्रतिबिंबित किए जाएं:

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

गंतव्य नियमों में उपसमुच्चय को परिभाषित करना

सबसेट (उपसमुच्चय) निम्नलिखित कॉन्फ़िगरेशन द्वारा निर्धारित किए जाते हैं (sa-logic-subsets-destinationrule.yaml):

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) परिभाषित करता है कि यह नियम केवल उन मामलों पर लागू होता है जब मार्ग सेवा की ओर जाता है sa-logic;
शीर्षक (name) सबसेट उदाहरणों को रूट करते समय सबसेट का उपयोग किया जाता है;
लेबल (label) कुंजी-मूल्य जोड़े को परिभाषित करता है जो उदाहरणों को सबसेट का हिस्सा बनने के लिए मेल खाना चाहिए।

निम्न आदेश के साथ कॉन्फ़िगरेशन लागू करें:

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

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

एक उपसमुच्चय पर रूट किया गया v1,
एक उपसमुच्चय पर प्रतिबिम्बित v2.

निम्नलिखित घोषणापत्र आपको अपनी योजनाओं को प्राप्त करने की अनुमति देता है (sa-तर्क-उपसमुच्चय-छाया-बनाम.yaml):

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

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

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

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

मुझे पता है, आप पहले से ही सोच रहे होंगे कि वर्चुअल सेवाएँ सरल हैं। अगले भाग में, हम यह कहकर इसका विस्तार करेंगे कि वे भी वास्तव में महान हैं।

कैनरी रोलआउट्स

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

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

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

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 वजन है (weight), जो उन अनुरोधों का प्रतिशत निर्दिष्ट करता है जो किसी प्राप्तकर्ता या प्राप्तकर्ता के सबसेट को निर्देशित किए जाएंगे।

आइए पिछले वर्चुअलसर्विस कॉन्फ़िगरेशन को अपडेट करें sa-logic निम्नलिखित आदेश के साथ:

$ 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

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

टाइमआउट और पुनः प्रयास

लेकिन बग हमेशा कोड में नहीं रहते। सूची में "वितरित कंप्यूटिंग के बारे में 8 गलत धारणाएँ"पहले स्थान पर यह ग़लत धारणा है कि "नेटवर्क विश्वसनीय है।" हकीकत में नेटवर्क नहीं विश्वसनीय, और इस कारण से हमें टाइमआउट की आवश्यकता है (समयबाह्य) और पुनः प्रयास करता है (पुन: प्रयास).

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

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

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

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

कार्यान्वयन के लिए, हम निम्नलिखित संसाधन परिभाषा का उपयोग करेंगे (sa-तर्क-पुनर्प्रयास-समयबाह्य-बनाम.yaml):

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-logic-buggy और निम्नलिखित कमांड चलाकर वर्चुअल सर्विस:

$ 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 (प्रमाणीकरण और प्राधिकरण);
«कंड्यूट - कुबेरनेट्स के लिए हल्का सर्विस मेश";
«सेवा जाल क्या है और मुझे इसकी आवश्यकता क्यों है [माइक्रोसर्विसेज के साथ क्लाउड एप्लिकेशन के लिए]?'.

स्रोत: www.habr.com

इस्तियो के साथ माइक्रोसर्विसेज पर वापस जाएं। भाग ---- पहला