Istio සමඟ microservices වෙත ආපසු. 2 කොටස

සටහන. පරිවර්තනය.: පළමු කොටස මෙම මාලාව කැප වූයේ ඉස්තියෝ හැකියාවන් හඳුන්වා දීම සහ ඒවා ක්‍රියාවෙන් ප්‍රදර්ශනය කිරීම සඳහා ය. දැන් අපි මෙම සේවා දැලෙහි වින්‍යාසය සහ භාවිතය පිළිබඳ වඩාත් සංකීර්ණ අංශ ගැන සහ විශේෂයෙන් මනාව සුසර කරන ලද මාර්ගගත කිරීම සහ ජාල ගමනාගමන කළමනාකරණය ගැන කතා කරමු.

ලිපිය ගබඩාවෙන් වින්‍යාසයන් (කුබර්නෙටස් සහ ඉස්ටියෝ සඳහා ප්‍රකාශන) භාවිතා කරන බව අපි ඔබට මතක් කරමු. istio-mastery.

රථවාහන කළමනාකරණය

Istio සමඟින්, සැපයීම සඳහා පොකුරේ නව හැකියාවන් දිස්වේ:

• ගතික ඉල්ලීම් මාර්ගගත කිරීම: canary rollouts, 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

හරිත අනුවාදය සඳහා යෙදවුම් මැනිෆෙස්ටය ස්ථාන දෙකකින් වෙනස් වේ:

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, ස්ථිතික ගොනු වල එක් අනුවාදයක් ඉල්ලා සිටීම, load balancer මගින් වෙනත් අනුවාදයක් ඇති කරල් වෙත යැවිය හැක, එහිදී, පැහැදිලි හේතු නිසා, එවැනි ගොනු නොපවතියි. එබැවින්, යෙදුම ක්‍රියාත්මක වීමට නම්, අපි සීමාවක් සැකසිය යුතුය: "index.html සේවය කළ යෙදුමේ එකම අනුවාදය පසුව ඉල්ලීම් ඉටු කළ යුතුය".

අපි ස්ථාවර හැෂ්-පාදක පැටවුම් සමතුලිතතාවයකින් එහි යන්නෙමු (අස්ථිර හැෂ් පැටවුම් තුලනය). මේ අවස්ථාවේ දී එකම සේවාදායකයාගෙන් ඉල්ලීම් එකම පසුපෙළ අවස්ථාවට යවනු ලැබේ, පූර්ව නිශ්චිත දේපලක් භාවිතා කරනු ලබන - උදාහරණයක් ලෙස, HTTP ශීර්ෂකය. DestinationRules භාවිතයෙන් ක්‍රියාත්මක කර ඇත.

ගමනාන්ත රීති

පසු VirtualService අපේක්ෂිත සේවාව වෙත ඉල්ලීමක් යවා, DestinationRules භාවිතයෙන් අපට මෙම සේවාවේ අවස්ථා සඳහා ගමනාගමනයට අදාළ වන ප්‍රතිපත්ති නිර්වචනය කළ හැක:

Istio සම්පත් සමඟ රථවාහන කළමනාකරණය

අදහස් දැක්වීම්: ජාල ගමනාගමනයට Istio සම්පත් වල බලපෑම පහසුවෙන් තේරුම් ගත හැකි ආකාරයෙන් මෙහි ඉදිරිපත් කර ඇත. නිවැරදිව කිවහොත්, CRD හි වින්‍යාස කර ඇති Ingress Gateway හි ඇති නියෝජිතයා විසින් ඉල්ලීම යැවිය යුත්තේ කුමන අවස්ථාවකද යන්න තීරණය කරනු ලැබේ.

ගමනාන්ත රීති සමඟින්, අපට ස්ථාවර හැෂ් භාවිතා කිරීමට සහ එම සේවා අවස්ථාව එකම පරිශීලකයාට ප්‍රතිචාර දක්වන බව සහතික කිරීමට පැටවුම් තුලනය වින්‍යාසගත කළ හැක. පහත වින්‍යාසය ඔබට මෙය සාක්ෂාත් කර ගැනීමට ඉඩ සලසයි (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 වෙත (හෝ මේ සමඟ Firefox සඳහා - දළ වශයෙන්. පරිවර්තනය.).

සාමාන්‍යයෙන්, 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-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

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

දැන් උප කුලක නිර්වචනය කර ඇති බැවින්, අපට sa-logic සඳහා වන ඉල්ලීම් සඳහා නීති යෙදීමට VirtualService වින්‍යාසගත කළ හැක.

1. උප කුලකයකට යොමු කර ඇත v1,
2. උප කුලකයකට දර්පණය කරන ලදී 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

අපි Grafana හි ප්‍රතිඵල දෙස බලමු, එහිදී ඔබට දෝෂ සහිත අනුවාදය බව දැකගත හැක (buggy) ඉල්ලීම් වලින් ~60% අසාර්ථක වීමට හේතු වේ, නමුත් ධාවනය වන සේවාවක් මඟින් ප්‍රතිචාර දක්වන බැවින් මෙම අසාර්ථක වීම් කිසිවක් අවසාන පරිශීලකයින්ට බලපාන්නේ නැත.

sa-logic සේවාවේ විවිධ අනුවාදවල සාර්ථක ප්‍රතිචාර

මෙහිදී අපි මුලින්ම දුටුවේ අපගේ සේවාවන්හි නියෝජිතයින්ට VirtualService යෙදෙන ආකාරය: කවදාද යන්නයි sa-web-app වෙත ඉල්ලීමක් කරයි sa-logic, එය සයිඩ්කාර් එන්වෝයි හරහා ගමන් කරයි, එය - VirtualService හරහා - ඉල්ලීම v1 උපකුලයට යොමු කිරීමට සහ සේවාවේ v2 උපකුලයට ඉල්ලීම පිළිබිඹු කිරීමට වින්‍යාස කර ඇත. sa-logic.

මම දන්නවා, ඔබ දැනටමත් සිතනවා ඇති අතථ්‍ය සේවා සරලයි කියලා. මීළඟ කොටසේදී, ඔවුන් ද ඇත්තෙන්ම විශිෂ්ට බව පවසමින් අපි එය පුළුල් කරන්නෙමු.

කැනරි රෝල්අවුට්

Canary Deployment යනු කුඩා පරිශීලකයින් සංඛ්‍යාවක් වෙත යෙදුමක නව අනුවාදයක් ලබා දීමේ ක්‍රියාවලියයි. නිකුතුවේ කිසිදු ගැටළුවක් නොමැති බවට වග බලා ගැනීමට එය භාවිතා කරන අතර ඉන් පසුව පමණක්, එහි (නිකුතුවේ) ගුණාත්මකභාවය පිළිබඳව දැනටමත් විශ්වාසයෙන්, වෙනත් පරිශීලකයින්ට එය බෙදාහරින්න.оවිශාල ප්රේක්ෂකයින්.

කැනරි රෝල්අවුට් ප්‍රදර්ශනය කිරීම සඳහා, අපි උප කුලකයක් සමඟ දිගටම වැඩ කරන්නෙමු 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

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

Circuit Breaker සහ Bulkhead Patterns

අපි කතා කරන්නේ ඔබට ස්වයං-ප්‍රකෘතිමත් වීමට ඉඩ සලසන ක්ෂුද්‍ර සේවා ගෘහ නිර්මාණ ශිල්පයේ වැදගත් රටා දෙකක් ගැන ය. (ස්වයං-සුව කිරීම) සේවාවන්.

පරිපථ බිඳිනය ("පරිපථ බිඳිනය") සෞඛ්‍යයට අහිතකර යැයි සලකන සේවාවක නිදසුනකට එන ඉල්ලීම් අවසන් කිරීමට සහ සේවාදායක ඉල්ලීම් එම සේවාවේ සෞඛ්‍ය සම්පන්න අවස්ථාවන් වෙත හරවා යවන අතර එය ප්‍රතිසාධන කිරීමට භාවිතා කරයි (එය සාර්ථක ප්‍රතිචාර ප්‍රතිශතය වැඩි කරයි). (සටහන: රටාව පිළිබඳ වඩාත් සවිස්තරාත්මක විස්තරයක් සොයා ගත හැක, උදාහරණයක් ලෙස, මෙහි.)

තොග හිස ("කොටස") සමස්ත පද්ධතියටම බලපාන සේවා අසාර්ථකත්වය හුදකලා කරයි. උදාහරණයක් ලෙස, සේවාව B බිඳී ඇති අතර වෙනත් සේවාවක් (සේවා B හි සේවාදායකයා) සේවා B වෙත ඉල්ලීමක් කරයි, එමඟින් එහි නූල් සංචිතය අවසන් වී වෙනත් ඉල්ලීම් සඳහා සේවා සැපයීමට නොහැකි වේ (ඒවා B සේවාවෙන් නොවේ නම්). (සටහන: රටාව පිළිබඳ වඩාත් සවිස්තරාත්මක විස්තරයක් සොයා ගත හැක, උදාහරණයක් ලෙස, මෙහි.)

මෙම රටා පහසුවෙන් සොයා ගත හැකි බැවින් ඒවා ක්‍රියාත්මක කිරීමේ විස්තර මම මග හරිමි නිල ලියකියවිලි, සහ මට ඇත්ත වශයෙන්ම සත්‍යාපනය සහ අවසරය පෙන්වීමට අවශ්‍යයි, එය ලිපියේ ඊළඟ කොටසේ සාකච්ඡා කෙරේ.

පරිවර්තකගෙන් PS

අපගේ බ්ලොග් අඩවියේ ද කියවන්න:

• "ඉස්ටියෝ සමඟ ක්ෂුද්‍ර සේවා වෙත ආපසු": 1 කොටස (ප්‍රධාන අංගයන් හැඳින්වීම), 3 කොටස (සත්‍යාපනය සහ අවසරය);
• «Conduit - Kubernetes සඳහා සැහැල්ලු සේවා දැලක්»;
• «සේවා දැලක් යනු කුමක්ද සහ මට එය [ක්ෂුද්‍ර සේවා සහිත වලාකුළු යෙදුමක් සඳහා] අවශ්‍ය වන්නේ ඇයි?".

මූලාශ්රය: www.habr.com