இஸ்டியோவுடன் மைக்ரோ சர்வீஸுக்குத் திரும்பு. பகுதி 2

குறிப்பு. மொழிபெயர்: முதல் பகுதி இந்தத் தொடர் இஸ்டியோ திறன்களை அறிமுகப்படுத்துவதற்கும் அவற்றை செயலில் வெளிப்படுத்துவதற்கும் அர்ப்பணிக்கப்பட்டது. இப்போது இந்த சேவை மெஷின் உள்ளமைவு மற்றும் பயன்பாட்டின் மிகவும் சிக்கலான அம்சங்களைப் பற்றி பேசுவோம், குறிப்பாக, நேர்த்தியான ரூட்டிங் மற்றும் நெட்வொர்க் போக்குவரத்து மேலாண்மை பற்றி.

கட்டுரை களஞ்சியத்திலிருந்து உள்ளமைவுகளை (குபெர்னெட்ஸ் மற்றும் இஸ்டியோவிற்கான வெளிப்பாடுகள்) பயன்படுத்துகிறது என்பதையும் நாங்கள் உங்களுக்கு நினைவூட்டுகிறோம். istio-mastery.

போக்குவரத்து மேலாண்மை

இஸ்டியோவுடன், புதிய திறன்களை வழங்குவதற்கு கிளஸ்டரில் தோன்றும்:

• டைனமிக் கோரிக்கை ரூட்டிங்கேனரி ரோல்அவுட்கள், ஏ/பி சோதனை;
• சுமை சமநிலை: எளிய மற்றும் சீரான, ஹாஷ்களின் அடிப்படையில்;
• வீழ்ச்சிக்குப் பிறகு மீட்பு: காலக்கெடு, மறு முயற்சிகள், சர்க்யூட் பிரேக்கர்கள்;
• தவறுகளைச் செருகுதல்: தாமதங்கள், கைவிடப்பட்ட கோரிக்கைகள் போன்றவை.

கட்டுரை தொடரும் போது, ​​தேர்ந்தெடுக்கப்பட்ட பயன்பாட்டை ஒரு உதாரணமாகப் பயன்படுத்தி இந்த திறன்கள் விளக்கப்படும், மேலும் புதிய கருத்துக்கள் அறிமுகப்படுத்தப்படும். அத்தகைய முதல் கருத்து இருக்கும் 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

"பச்சை பதிப்பிற்கான" வரிசைப்படுத்தல் மேனிஃபெஸ்ட் இரண்டு இடங்களில் வேறுபடுகிறது:

1. படம் வேறொரு குறிச்சொல்லை அடிப்படையாகக் கொண்டது - istio-green,
2. காய்களுக்கு ஒரு லேபிள் உள்ளது 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 தலைப்பு. Destination Rules ஐப் பயன்படுத்தி செயல்படுத்தப்பட்டது.

இலக்கு விதிகள்

பிறகு மெய்நிகர் சேவை விரும்பிய சேவைக்கு ஒரு கோரிக்கையை அனுப்பியது, DestinationRules ஐப் பயன்படுத்தி, இந்தச் சேவையின் நிகழ்வுகளுக்கு விதிக்கப்படும் போக்குவரத்திற்குப் பயன்படுத்தப்படும் கொள்கைகளை நாம் வரையறுக்கலாம்:

இஸ்டியோ ஆதாரங்களுடன் போக்குவரத்து மேலாண்மை

கருத்து: நெட்வொர்க் ட்ராஃபிக்கில் இஸ்டியோ ஆதாரங்களின் தாக்கம் எளிதாக புரிந்துகொள்ளும் வகையில் இங்கே கொடுக்கப்பட்டுள்ளது. துல்லியமாகச் சொல்வதானால், CRD இல் உள்ளமைக்கப்பட்ட நுழைவு நுழைவாயிலில் உள்ள தூதர் மூலம் கோரிக்கையை எந்த நிகழ்விற்கு அனுப்புவது என்பது முடிவு செய்யப்படுகிறது.

இலக்கு விதிகள் மூலம், நிலையான ஹாஷ்களைப் பயன்படுத்துவதற்கு ஏற்ற சமநிலையை உள்ளமைக்கலாம் மற்றும் அதே சேவை நிகழ்வு அதே பயனருக்கு பதிலளிக்கும் என்பதை உறுதிசெய்யலாம். பின்வரும் உள்ளமைவு இதை அடைய உங்களை அனுமதிக்கிறது (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 சுமை சமநிலையில் அதிக திறன்களைக் கொண்டுள்ளது - விவரங்களுக்குச் சரிபார்க்கவும் அதிகாரப்பூர்வ ஆவணங்கள்.

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

பிரதிபலிப்பு: நடைமுறையில் உள்ள மெய்நிகர் சேவைகள்

நிழல் ("கவசம்") அல்லது பிரதிபலிப்பு ("பிரதிபலிப்பு") இறுதிப் பயனர்களைப் பாதிக்காமல் உற்பத்தியில் மாற்றத்தைச் சோதிக்க விரும்பும் சந்தர்ப்பங்களில் பயன்படுத்தப்படுகிறது: இதைச் செய்ய, விரும்பிய மாற்றங்கள் செய்யப்பட்ட இரண்டாவது நிகழ்விற்கு ("கண்ணாடி") கோரிக்கைகளை நகலெடுத்து, அதன் விளைவுகளைப் பார்க்கிறோம். எளிமையாகச் சொன்னால், உங்கள் சக ஊழியர் மிக முக்கியமான சிக்கலைத் தேர்ந்தெடுத்து, யாராலும் உண்மையில் மறுபரிசீலனை செய்ய முடியாத அளவுக்கு ஒரு பெரிய அழுக்கு வடிவில் இழுக்கும் கோரிக்கையை முன்வைக்கிறார்.

இந்த காட்சியை செயலில் சோதிக்க, பிழைகளுடன் SA-Logic இன் இரண்டாவது நிகழ்வை உருவாக்குவோம் (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 மூலம் இதை அடைவோம், அங்கு விதிகள் VirtualService இன் துணைக்குழுக்கள் மற்றும் வழிகளை ஒரு குறிப்பிட்ட துணைக்குழுவிற்கு தீர்மானிக்கும்.

இலக்கு விதிகளில் துணைக்குழுக்களை வரையறுத்தல்

துணைக்குழுக்கள் (துணைக்குழுக்கள்) பின்வரும் கட்டமைப்பு மூலம் தீர்மானிக்கப்படுகிறது (sa-logic-subets-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

1. தொகுப்பாளர் (host) இந்த விதி சேவையை நோக்கி செல்லும் சந்தர்ப்பங்களில் மட்டுமே பொருந்தும் என்று வரையறுக்கிறது sa-logic;
2. தலைப்புகள் (name) துணைக்குழு நிகழ்வுகளுக்கு ரூட்டிங் செய்யும் போது துணைக்குழுக்கள் பயன்படுத்தப்படுகின்றன;
3. லேபிள் (label) துணைக்குழுவின் ஒரு பகுதியாக மாறுவதற்கு நிகழ்வுகள் பொருந்த வேண்டிய முக்கிய மதிப்பு ஜோடிகளை வரையறுக்கிறது.

பின்வரும் கட்டளையுடன் கட்டமைப்பைப் பயன்படுத்தவும்:

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

இப்போது துணைக்குழுக்கள் வரையறுக்கப்பட்டுவிட்டதால், சா-லாஜிக்கிற்கான கோரிக்கைகளுக்கு விதிகளைப் பயன்படுத்துவதற்கு VirtualServiceஐ நாம் நகர்த்தி கட்டமைக்கலாம்:

1. துணைக்குழுவிற்கு அனுப்பப்பட்டது v1,
2. துணைக்குழுவில் பிரதிபலிக்கப்பட்டது v2.

உங்கள் திட்டங்களை அடைய பின்வரும் அறிக்கை உங்களை அனுமதிக்கிறது (sa-logic-subets-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) கோரிக்கைகளில் ~60% தோல்வியில் விளைகிறது, ஆனால் இந்த தோல்விகள் எதுவும் இறுதிப் பயனர்களைப் பாதிக்காது, ஏனெனில் அவை இயங்கும் சேவையால் பதிலளிக்கப்படுகின்றன.

sa-logic சேவையின் வெவ்வேறு பதிப்புகளின் வெற்றிகரமான பதில்கள்

எங்கள் சேவைகளின் தூதர்களுக்கு VirtualService எவ்வாறு பயன்படுத்தப்படுகிறது என்பதை முதலில் இங்கு பார்த்தோம்: எப்போது sa-web-app ஒரு கோரிக்கையை வைக்கிறது sa-logic, இது சைட்கார் என்வாய் வழியாக செல்கிறது, இது - VirtualService வழியாக - கோரிக்கையை v1 துணைக்குழுவிற்கு அனுப்பவும், சேவையின் v2 துணைக்குழுவிற்கு கோரிக்கையை பிரதிபலிக்கவும் கட்டமைக்கப்பட்டுள்ளது. sa-logic.

எனக்கு தெரியும், மெய்நிகர் சேவைகள் எளிமையானவை என்று நீங்கள் ஏற்கனவே நினைக்கலாம். அடுத்த பகுதியில், அவர்கள் உண்மையிலேயே சிறந்தவர்கள் என்று கூறி அதை விரிவுபடுத்துவோம்.

கேனரி ரோல்அவுட்கள்

கேனரி வரிசைப்படுத்தல் என்பது ஒரு சிறிய எண்ணிக்கையிலான பயனர்களுக்கு ஒரு பயன்பாட்டின் புதிய பதிப்பை வெளியிடும் செயல்முறையாகும். வெளியீட்டில் எந்த பிரச்சனையும் இல்லை என்பதை உறுதிப்படுத்த இது பயன்படுகிறது, அதன் பிறகுதான், அதன் (வெளியீட்டு) தரத்தில் ஏற்கனவே நம்பிக்கை வைத்து, மற்ற பயனர்களுக்கு விநியோகிக்கவும்.оஅதிக பார்வையாளர்கள்.

கேனரி ரோல்அவுட்களை நிரூபிக்க, நாங்கள் துணைக்குழுவுடன் தொடர்ந்து பணியாற்றுவோம் buggy у sa-logic.

அற்ப விஷயங்களில் நேரத்தை வீணடிக்க வேண்டாம், உடனடியாக 20% பயனர்களை பிழைகள் உள்ள பதிப்பிற்கு அனுப்புவோம் (இது எங்கள் கேனரி வெளியீட்டைக் குறிக்கும்), மீதமுள்ள 80% சாதாரண சேவைக்கு. இதைச் செய்ய, பின்வரும் மெய்நிகர் சேவையைப் பயன்படுத்தவும் (sa-logic-subsets-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

VirtualServices canary rollouts ஐ செயல்படுத்துகிறது: இந்த விஷயத்தில், சிக்கல்களின் சாத்தியமான தாக்கத்தை பயனர் தளத்தில் 20% ஆகக் குறைத்துள்ளோம். அற்புதம்! இப்போது, ​​​​ஒவ்வொரு சந்தர்ப்பத்திலும், எங்கள் குறியீட்டை (வேறுவிதமாகக் கூறினால் - எப்போதும்...), நாம் பிரதிபலிப்பு மற்றும் கேனரி ரோல்அவுட்களைப் பயன்படுத்தலாம்.

காலக்கெடு மற்றும் மறு முயற்சிகள்

ஆனால் பிழைகள் எப்போதும் குறியீட்டில் முடிவடைவதில்லை. பட்டியலில் இருந்து "8 விநியோகிக்கப்பட்ட கணினி பற்றிய தவறான கருத்துக்கள்"முதலில் "நெட்வொர்க் நம்பகமானது" என்ற தவறான நம்பிக்கை உள்ளது. உண்மையில் நெட்வொர்க் இல்லை நம்பகமானது, இந்த காரணத்திற்காக எங்களுக்கு காலக்கெடு தேவை (நேரமுடிவுகள்) மற்றும் மீண்டும் முயற்சிக்கிறது (மீண்டும் முயற்சி).

ஆர்ப்பாட்டத்திற்கு நாங்கள் அதே பிரச்சனை பதிப்பை தொடர்ந்து பயன்படுத்துவோம் sa-logic (buggy), மற்றும் சீரற்ற தோல்விகளுடன் பிணையத்தின் நம்பகத்தன்மையை உருவகப்படுத்துவோம்.

பிழைகள் உள்ள எங்கள் சேவையானது பதிலளிப்பதற்கு அதிக நேரம் எடுக்கும் 1/3 வாய்ப்பு, உள் சேவையகப் பிழையுடன் முடிவதற்கான 1/3 வாய்ப்பு மற்றும் பக்கத்தை வெற்றிகரமாகத் திரும்பப் பெற 1/3 வாய்ப்பு.

இதுபோன்ற சிக்கல்களின் தாக்கத்தைத் தணிக்கவும், பயனர்களின் வாழ்க்கையை மேம்படுத்தவும், நாம்:

1. சேவை பதிலளிக்க 8 வினாடிகளுக்கு மேல் எடுத்தால், காலக்கெடுவைச் சேர்க்கவும்,
2. கோரிக்கை தோல்வியடைந்தால் மீண்டும் முயற்சிக்கவும்.

செயல்படுத்த, பின்வரும் ஆதார வரையறையைப் பயன்படுத்துவோம் (sa-logic-retriries-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

1. கோரிக்கைக்கான காலக்கெடு 8 வினாடிகளாக அமைக்கப்பட்டுள்ளது;
2. கோரிக்கைகள் 3 முறை மீண்டும் முயற்சிக்கப்படுகின்றன;
3. மறுமொழி நேரம் 3 வினாடிகளுக்கு மேல் இருந்தால் ஒவ்வொரு முயற்சியும் தோல்வியுற்றதாகக் கருதப்படுகிறது.

பயனர் 8 வினாடிகளுக்கு மேல் காத்திருக்க வேண்டியதில்லை என்பதால் இது ஒரு தேர்வுமுறையாகும், மேலும் தோல்விகள் ஏற்பட்டால் பதிலைப் பெற மூன்று புதிய முயற்சிகளைச் செய்வோம், வெற்றிகரமான பதிலுக்கான வாய்ப்பை அதிகரிக்கும்.

பின்வரும் கட்டளையுடன் புதுப்பிக்கப்பட்ட கட்டமைப்பைப் பயன்படுத்தவும்:

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

மேலும் வெற்றிகரமான பதில்களின் எண்ணிக்கை மேலே அதிகரித்துள்ளதா என்பதை Grafana வரைபடங்களில் பார்க்கவும்:

காலக்கெடு மற்றும் மறுமுயற்சிகளைச் சேர்த்த பிறகு வெற்றிகரமான பதில் புள்ளிவிவரங்களில் மேம்பாடுகள்

அடுத்த பகுதிக்குச் செல்வதற்கு முன் (அல்லது மாறாக, கட்டுரையின் அடுத்த பகுதிக்கு, ஏனெனில் இதில் நடைமுறை சோதனைகள் எதுவும் இருக்காது - தோராயமாக. மொழிபெயர்ப்பு.), அழி 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 இன் கிளையன்ட்) சர்வீஸ் பிக்கு ஒரு கோரிக்கையை முன்வைக்கிறது, இதனால் அதன் த்ரெட் பூல் தீர்ந்துவிடும் மற்றும் பிற கோரிக்கைகளுக்கு சேவை செய்ய முடியாது (அவை சேவை பி யில் இருந்து இல்லாவிட்டாலும் கூட). (குறிப்பு: வடிவத்தின் விரிவான விளக்கத்தைக் காணலாம், எடுத்துக்காட்டாக, இங்கே.)

இந்த வடிவங்களின் செயலாக்க விவரங்களை நான் தவிர்க்கிறேன், ஏனெனில் அவை கண்டுபிடிக்க எளிதானது அதிகாரப்பூர்வ ஆவணங்கள், மேலும் நான் அங்கீகாரம் மற்றும் அங்கீகாரத்தைக் காட்ட விரும்புகிறேன், இது கட்டுரையின் அடுத்த பகுதியில் விவாதிக்கப்படும்.

மொழிபெயர்ப்பாளரிடமிருந்து பி.எஸ்

எங்கள் வலைப்பதிவிலும் படிக்கவும்:

• "இஸ்டியோவுடன் மைக்ரோ சர்வீஸுக்குத் திரும்பு": பகுதி 1 (முக்கிய அம்சங்களுக்கான அறிமுகம்), பகுதி 3 (அங்கீகாரம் மற்றும் அங்கீகாரம்);
• «கான்ட்யூட் - குபெர்னெட்ஸிற்கான இலகுரக சேவை மெஷ்";
• «சர்வீஸ் மெஷ் என்றால் என்ன, அது எனக்கு ஏன் தேவை [மைக்ரோ சர்வீஸ்கள் கொண்ட கிளவுட் பயன்பாட்டிற்கு]?".

ஆதாரம்: www.habr.com