🥇 Istio सह मायक्रो सर्व्हिसेसवर परत या. भाग २

नोंद. अनुवाद: पहिला भाग ही मालिका Istio क्षमतांचा परिचय करून देण्यासाठी आणि कृतीत त्यांचे प्रदर्शन करण्यासाठी समर्पित होती. आता आम्ही या सेवा जाळीच्या कॉन्फिगरेशन आणि वापराच्या अधिक जटिल पैलूंबद्दल आणि विशेषतः बारीक ट्यून केलेल्या राउटिंग आणि नेटवर्क रहदारी व्यवस्थापनाबद्दल बोलू.

आम्ही तुम्हाला आठवण करून देतो की लेख रेपॉजिटरीमधील कॉन्फिगरेशन (कुबर्नेट्स आणि इस्टिओसाठी मॅनिफेस्ट) वापरतो. istio-mastery.

वाहतूक व्यवस्थापन

Istio सह, प्रदान करण्यासाठी क्लस्टरमध्ये नवीन क्षमता दिसून येतात:

डायनॅमिक विनंती राउटिंग: कॅनरी रोलआउट्स, A/B चाचणी;
लोड बॅलन्सिंग: साधे आणि सुसंगत, हॅशवर आधारित;
फॉल्स नंतर पुनर्प्राप्ती: कालबाह्य, पुन्हा प्रयत्न, सर्किट ब्रेकर;
दोष घालणे: विलंब, सोडलेल्या विनंत्या इ.

लेख पुढे चालू असताना, निवडलेल्या ऍप्लिकेशनचा वापर करून या क्षमतांचे उदाहरण म्हणून स्पष्ट केले जाईल आणि मार्गात नवीन संकल्पना सादर केल्या जातील. अशी पहिली संकल्पना असेल DestinationRules (म्हणजे रहदारी/विनंत्या प्राप्तकर्त्यांबद्दलचे नियम - अंदाजे भाषांतर.), ज्याच्या मदतीने आम्ही A/B चाचणी सक्रिय करतो.

A/B चाचणी: सराव मध्ये गंतव्य नियम

A/B चाचणी अशा प्रकरणांमध्ये वापरली जाते जिथे अनुप्रयोगाच्या दोन आवृत्त्या आहेत (सहसा त्या दृष्यदृष्ट्या भिन्न असतात) आणि आम्हाला 100% खात्री नाही की कोणता वापरकर्ता अनुभव सुधारेल. म्हणून, आम्ही दोन्ही आवृत्त्या एकाच वेळी चालवतो आणि मेट्रिक्स गोळा करतो.

फ्रंटएंडची दुसरी आवृत्ती उपयोजित करण्यासाठी, A/B चाचणीचे प्रदर्शन करण्यासाठी आवश्यक, खालील आदेश चालवा:

$ 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 वापरून आम्ही धोरणे परिभाषित करू शकतो जी या सेवेच्या उदाहरणांसाठी नियत रहदारीवर लागू केली जातील:

Istio संसाधनांसह रहदारी व्यवस्थापन

शेरा: नेटवर्क रहदारीवर Istio संसाधनांचा प्रभाव समजण्यास सोप्या पद्धतीने येथे सादर केला आहे. तंतोतंत सांगायचे तर, विनंती कोणत्या उदाहरणावर पाठवायची हा निर्णय सीआरडीमध्ये कॉन्फिगर केलेल्या इंग्रेस गेटवेमधील दूताने घेतला आहे.

डेस्टिनेशन नियमांसह, आम्ही सातत्यपूर्ण हॅश वापरण्यासाठी लोड बॅलन्सिंग कॉन्फिगर करू शकतो आणि समान सेवा उदाहरण समान वापरकर्त्याला प्रतिसाद देतो याची खात्री करू शकतो. खालील कॉन्फिगरेशन तुम्हाला हे साध्य करण्यास अनुमती देते (destinationrule-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

शेरा: हेडरमध्ये भिन्न मूल्ये जोडण्यासाठी आणि ब्राउझरमध्ये थेट परिणामांची चाचणी घेण्यासाठी, तुम्ही वापरू शकता हा विस्तार Chrome ला (किंवा ह्या बरोबर फायरफॉक्ससाठी - अंदाजे. अनुवाद.).

सर्वसाधारणपणे, 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

मिररिंग: सराव मध्ये आभासी सेवा

छाया ("संरक्षण") किंवा मिररिंग ("मिरिंग") शेवटच्या वापरकर्त्यांना प्रभावित न करता उत्पादनातील बदलाची चाचणी करू इच्छित असलेल्या प्रकरणांमध्ये वापरली जाते: हे करण्यासाठी, आम्ही इच्छित बदल केलेल्या दुसर्‍या उदाहरणासाठी (“मिरर”) विनंत्या डुप्लिकेट करतो आणि त्याचे परिणाम पाहतो. सोप्या भाषेत सांगायचे तर, जेव्हा तुमचा सहकारी सर्वात गंभीर समस्या निवडतो आणि घाणीच्या एवढ्या मोठ्या ढिगाऱ्याच्या रूपात खेचण्याची विनंती करतो तेव्हा कोणीही त्याचे पुनरावलोकन करू शकत नाही.

या परिस्थितीची कृतीत चाचणी घेण्यासाठी, बग्ससह एसए-लॉजिकचे दुसरे उदाहरण तयार करूया (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 घटनांमध्ये मिरर कराव्यात अशी आमची इच्छा आहे:

आम्ही DestinationRule च्या संयोजनात VirtualService द्वारे हे साध्य करू, जिथे नियम व्हर्च्युअल सर्व्हिसचे उपसमूह आणि मार्ग एका विशिष्ट उपसंचासाठी निर्धारित करतील.

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

उपसंच (उपसंच) खालील कॉन्फिगरेशनद्वारे निर्धारित केले जातात (sa-logic-subset-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-logic-subset-shadowing-vs.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).

sa-logic सेवेच्या विविध आवृत्त्यांचे यशस्वी प्रतिसाद

आमच्या सेवांच्या दूतांना VirtualService कशी लागू केली जाते हे आम्ही प्रथम पाहिले: कधी sa-web-app ला विनंती करतो sa-logic, हे साइडकार एन्वॉयमधून जाते, जे - VirtualService द्वारे - विनंतीला v1 उपसमूहावर जाण्यासाठी आणि विनंतीला सेवेच्या v2 उपसंचासाठी मिरर करण्यासाठी कॉन्फिगर केले जाते. sa-logic.

मला माहीत आहे, तुम्हाला आधीपासून वाटेल की आभासी सेवा सोपी आहे. पुढील विभागात, आम्ही ते खरोखर उत्कृष्ट असल्याचे सांगून त्याचा विस्तार करू.

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

कॅनरी डिप्लॉयमेंट ही अनुप्रयोगाची नवीन आवृत्ती थोड्या संख्येने वापरकर्त्यांसाठी आणण्याची प्रक्रिया आहे. रिलीझमध्ये कोणतीही अडचण येत नाही याची खात्री करण्यासाठी याचा वापर केला जातो आणि त्यानंतरच, त्याच्या (रिलीझच्या) गुणवत्तेवर आधीच विश्वास ठेवून, ते इतर वापरकर्त्यांना वितरित करा.оमोठे प्रेक्षक.

कॅनरी रोलआउट्स प्रदर्शित करण्यासाठी, आम्ही उपसमूहांसह कार्य करणे सुरू ठेवू buggy у sa-logic.

चला क्षुल्लक गोष्टींवर वेळ वाया घालवू नका आणि 20% वापरकर्त्यांना बगसह आवृत्तीवर त्वरित पाठवू (हे आमच्या कॅनरी रोलआउटचे प्रतिनिधित्व करेल), आणि उर्वरित 80% सामान्य सेवेसाठी. हे करण्यासाठी, खालील VirtualService वापरा (sa-logic-subset-canary-vs.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), जे प्राप्तकर्त्याकडे किंवा प्राप्तकर्त्याच्या उपसंचाकडे निर्देशित केलेल्या विनंत्यांची टक्केवारी निर्दिष्ट करते.

साठी मागील VirtualService कॉन्फिगरेशन अपडेट करूया 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-logic-retry-timeouts-vs.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 आणि खालील आदेश चालवून 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

सर्किट ब्रेकर आणि बल्कहेड नमुने

आम्ही मायक्रोसर्व्हिस आर्किटेक्चरमधील दोन महत्त्वाच्या नमुन्यांबद्दल बोलत आहोत जे तुम्हाला स्वत: ची पुनर्प्राप्ती प्राप्त करण्यास अनुमती देतात (स्व-उपचार) सेवा.

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

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

मी या नमुन्यांचे अंमलबजावणी तपशील वगळेन कारण ते शोधणे सोपे आहे अधिकृत दस्तऐवजीकरण, आणि मला खरोखर प्रमाणीकरण आणि अधिकृतता देखील दाखवायची आहे, ज्याची लेखाच्या पुढील भागात चर्चा केली जाईल.

अनुवादकाकडून पुनश्च

आमच्या ब्लॉगवर देखील वाचा:

"इस्टिओसह मायक्रो सर्व्हिसेसकडे परत जा": भाग १ (मुख्य वैशिष्ट्यांचा परिचय), भाग 3 (प्रमाणीकरण आणि अधिकृतता);
«कंड्युट - कुबर्नेट्ससाठी हलकी सेवा जाळी";
«सर्व्हिस मेश म्हणजे काय आणि मला [मायक्रोसर्व्हिसेससह क्लाउड ऍप्लिकेशनसाठी] याची आवश्यकता का आहे?».

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

Istio सह microservices वर परत. भाग 2