Istio ဖြင့် microservices သို့ ပြန်သွားရန်။ အပိုင်း 2

မှတ်ချက်။ ဘာသာပြန်: ပထမဦးဆုံးအစိတျအပိုငျး ဤစီးရီးသည် Istio စွမ်းရည်များကို မိတ်ဆက်ပြီး ၎င်းတို့ကို လက်တွေ့သရုပ်ပြရန် ရည်ရွယ်ထားသည်။ ယခုကျွန်ုပ်တို့သည် ဤဝန်ဆောင်မှု mesh ၏ဖွဲ့စည်းပုံနှင့်အသုံးပြုမှု၏ပိုမိုရှုပ်ထွေးသောရှုထောင့်များအကြောင်းနှင့် အထူးသဖြင့်၊ သေချာစွာပြင်ဆင်ထားသောလမ်းကြောင်းနှင့်ကွန်ရက်လမ်းကြောင်းစီမံခန့်ခွဲမှုအကြောင်းပြောပါမည်။

ဆောင်းပါးသည် repository မှ configurations ( Kubernetes နှင့် Istio အတွက် manifests များ) ကို အသုံးပြုကြောင်း သင့်အား ကျွန်ုပ်တို့ သတိပေးပါသည်။ istio-ကျွမ်းကျင်မှု.

လမ်းစည်းကမ်း စီမံခန့်ခွဲမှု

Istio ဖြင့်၊ ပံ့ပိုးပေးရန်အတွက် အစုအဝေးတွင် စွမ်းရည်အသစ်များပေါ်လာသည်-

• ဒိုင်းနမစ် တောင်းဆိုမှုလမ်းကြောင်း: Canary ဖြန့်ချိမှုများ၊ A/B စမ်းသပ်ခြင်း၊
• Load ချိန်ခွင်လျှာ: hashes ကိုအခြေခံ၍ ရိုးရှင်းပြီး ကိုက်ညီသော၊
• ပြုတ်ကျပြီးနောက် ပြန်လည်ထူထောင်ရေးအချိန်ကုန်ခြင်း၊ ထပ်စမ်းခြင်း၊ circuit breakers;
• အမှားအယွင်းများကို ထည့်သွင်းခြင်း။- နှောင့်နှေးမှု၊ ကျဆင်းသွားသော တောင်းဆိုမှုများ၊ စသည်တို့။

ဆောင်းပါးတွင် ဆက်လက်ဖော်ပြထားသည်နှင့်အမျှ ဤစွမ်းရည်များကို ရွေးချယ်ထားသော အက်ပ်လီကေးရှင်းကို အသုံးပြု၍ နမူနာအဖြစ် သရုပ်ဖော်မည်ဖြစ်ပြီး လမ်းတစ်လျှောက်တွင် သဘောတရားအသစ်များကို မိတ်ဆက်ပါမည်။ ပထမဆုံးသော အယူအဆဖြစ်လိမ့်မည်။ DestinationRules (ဆိုလိုသည်မှာ အသွားအလာ/တောင်းဆိုမှုများ လက်ခံရရှိသူနှင့်ပတ်သက်သည့် စည်းမျဉ်းများ - ခန့်မှန်းခြေ ဘာသာပြန်ချက်။)A/B စမ်းသပ်ခြင်း၏အကူအညီဖြင့်၊

A/B စမ်းသပ်ခြင်း- လက်တွေ့တွင် DestinationRules

A/B စမ်းသပ်ခြင်းကို အက်ပလီကေးရှင်းတစ်ခု၏ ဗားရှင်းနှစ်မျိုးရှိ (များသောအားဖြင့် ၎င်းတို့သည် အမြင်အားဖြင့် ကွဲပြားသည်) နှင့် မည်သည့်အရာသည် အသုံးပြုသူအတွေ့အကြုံကို ပိုမိုကောင်းမွန်စေမည်ကို ကျွန်ုပ်တို့ 100% မသေချာပါ။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် ဗားရှင်းနှစ်မျိုးလုံးကို တစ်ပြိုင်နက် လုပ်ဆောင်ပြီး မက်ထရစ်များကို စုဆောင်းပါသည်။

A/B စမ်းသပ်မှုသရုပ်ပြရန်အတွက် လိုအပ်သော Frontend ၏ ဒုတိယဗားရှင်းကို အသုံးချရန် အောက်ပါ command ကို run ပါ။

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

အစိမ်းရောင်ဗားရှင်းအတွက် ဖြန့်ကျက်မှုသည် နေရာနှစ်ခုတွင် ကွဲပြားသည်-

1. ပုံသည် မတူညီသော tag ကိုအခြေခံသည် - istio-green,
2. ဘူးများတွင် အညွှန်းပါရှိပါသည်။ version: green.

ဖြန့်ကျက်မှုနှစ်ခုလုံးတွင် တံဆိပ်တစ်ခုရှိသောကြောင့်ဖြစ်သည်။ app: sa-frontend၊ virtual ဝန်ဆောင်မှုဖြင့် လမ်းကြောင်းပြထားသော တောင်းဆိုချက်များ sa-external-services ဝန်ဆောင်မှုအတွက် sa-frontend၊ ၎င်း၏ဖြစ်ရပ်များအားလုံးသို့ ပြန်ညွှန်းသွားမည်ဖြစ်ပြီး ဝန်အားမှတစ်ဆင့် ဖြန့်ဝေမည်ဖြစ်သည်။ round-robin algorithmအောက်ပါအခြေအနေသို့ ဦးတည်စေမည့်၊

တောင်းဆိုထားသည့်ဖိုင်များကို ရှာမတွေ့ပါ။

ဤဖိုင်များကို အပလီကေးရှင်း၏ ဗားရှင်းအမျိုးမျိုးတွင် ကွဲပြားစွာ အမည်ပေးထားသည့်အတွက် ၎င်းတို့ကို ရှာမတွေ့ပါ။ ဒါကို သေချာကြည့်ရအောင်။

$ 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.htmlstatic ဖိုင်များ၏ ဗားရှင်းတစ်ခုအား တောင်းဆိုခြင်းဖြင့်၊ မတူညီသော ဗားရှင်းရှိသည့် pods များထံသို့ load balancer မှ ပေးပို့နိုင်သည်၊ ထင်ရှားသော အကြောင်းများကြောင့်၊ ထိုသို့သောဖိုင်များ မရှိပါ။ ထို့ကြောင့် လျှောက်လွှာများ အလုပ်လုပ်နိုင်ရန် ကန့်သတ်ချက်တစ်ခု သတ်မှတ်ရန် လိုအပ်သည်-"index.html ဝန်ဆောင်မှုပေးသော အပလီကေးရှင်း၏ တူညီသောဗားရှင်းသည် နောက်ဆက်တွဲတောင်းဆိုမှုများကို ဆောင်ရွက်ပေးသင့်သည်။"။

တသမတ်တည်း hash-based load balancing ဖြင့် ထိုနေရာကို ရောက်ပါမည်။ (တစ်သမတ်တည်း Hash Loadbalancing)... ဒီကိစ္စမှာ တူညီသော client မှ တောင်းဆိုချက်များကို တူညီသော backend instance သို့ ပေးပို့ပါသည်။ကြိုတင်သတ်မှတ်ထားသော ပိုင်ဆိုင်မှုကို အသုံးပြုထားသည့်အတွက် - ဥပမာ HTTP ခေါင်းစီးတစ်ခု။ DestinationRules ကို အသုံးပြု၍ အကောင်အထည်ဖော်ခဲ့သည်။

သွားမည့်နေရာ စည်းကမ်းများ

ယင်းပြီးနောက် VirtualService DestinationRules ကို အသုံးပြု၍ အလိုရှိသော ဝန်ဆောင်မှုသို့ တောင်းဆိုချက်တစ်ခု ပေးပို့ပြီး၊ ဤဝန်ဆောင်မှု၏ ဥပမာများအတွက် ဦးတည်ထားသော အသွားအလာအတွက် အသုံးပြုမည့် မူဝါဒများကို ကျွန်ုပ်တို့ သတ်မှတ်နိုင်သည်-

Istio အရင်းအမြစ်များဖြင့် လမ်းကြောင်းစီမံခန့်ခွဲမှု

ပွောဆို− ကွန်ရက်အသွားအလာအပေါ် Istio အရင်းအမြစ်များ၏ သက်ရောက်မှုကို နားလည်ရလွယ်ကူသောနည်းလမ်းဖြင့် ဤနေရာတွင် တင်ပြထားသည်။ တိကျစွာပြောရလျှင် CRD တွင်ထည့်သွင်းထားသော Ingress Gateway ရှိ သံတမန်မှ တောင်းဆိုချက်ကို ပေးပို့ရန် မည်သည့်ဥပမာကို ပေးပို့ရမည်ကို တိကျစွာဆုံးဖြတ်သည်။

Destination Rules ဖြင့်၊ တူညီသော hashe များကိုအသုံးပြုရန် load balancing ကို configure နိုင်ပြီး တူညီသော service instance သည် တူညီသော user ကိုတုံ့ပြန်ကြောင်းသေချာစေပါသည်။ အောက်ပါဖွဲ့စည်းပုံသည် သင့်အား ၎င်းကိုအောင်မြင်ရန်ခွင့်ပြုသည် (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 header ၏ အကြောင်းအရာများအပေါ် အခြေခံ၍ hash ကို ထုတ်ပေးပါမည်။ version.

အောက်ပါ command ဖြင့် configuration ကိုအသုံးပြုပါ-

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

ယခု အောက်ပါ command ကို run ပြီး header ကို သတ်မှတ်သောအခါ မှန်ကန်သော ဖိုင်များ ရရှိကြောင်း သေချာပါစေ။ version:

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

ပွောဆို: header တွင် မတူညီသောတန်ဖိုးများထည့်ရန်နှင့် browser တွင် တိုက်ရိုက်ရလဒ်များကို စမ်းသပ်ရန်၊ သင်သုံးနိုင်သည်။ ဤတိုးချဲ့မှု Chrome သို့ (သို့မဟုတ် ဤအတူ Firefox အတွက် - ခန့်မှန်းခြေ။ ဘာသာပြန်။).

ယေဘူယျအားဖြင့်၊ DestinationRules သည် load balancing ဧရိယာတွင်ပိုမိုလုပ်ဆောင်နိုင်စွမ်းရှိသည် - အသေးစိတ်ကိုစစ်ဆေးပါ။ တရားဝင်စာရွက်စာတမ်း.

VirtualService ကို ထပ်မံမလေ့လာမီ၊ အောက်ပါ command များကို လုပ်ဆောင်ခြင်းဖြင့် အပလီကေးရှင်း၏ "အစိမ်းရောင်ဗားရှင်း" နှင့် သက်ဆိုင်ရာ ယာဉ်လမ်းကြောင်း စည်းကမ်းကို ဖျက်ကြပါစို့။

$ 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

Mirroring- လက်တွေ့တွင် Virtual Services

အရိပ် ("အကာအရံ") သို့မဟုတ် ကြေးမုံပြင်ခြင်း။ ("မှန်ပြောင်း") အသုံးပြုသူများအပေါ် မထိခိုက်စေဘဲ ထုတ်လုပ်မှုပြောင်းလဲမှုကို စမ်းသပ်လိုသည့်ကိစ္စများတွင် အသုံးပြုသည်- ၎င်းကိုလုပ်ဆောင်ရန်အတွက် ကျွန်ုပ်တို့သည် ("ကြေးမုံ") တောင်းဆိုမှုများကို လိုချင်သောအပြောင်းအလဲများပြုလုပ်ခဲ့သည့် ဒုတိယဥပမာတစ်ခုသို့ ကူးယူပြီး အကျိုးဆက်များကိုကြည့်ပါ။ ရိုးရိုးရှင်းရှင်းပြောရလျှင်၊ သင်၏လုပ်ဖော်ကိုင်ဖက်သည် ၎င်းကို အမှန်တကယ်ပြန်လည်သုံးသပ်၍မရနိုင်သော ဤမျှကြီးမားသောအဖုအထစ်ပုံစံဖြင့် ဆွဲငင်တောင်းဆိုမှုပြုလုပ်သည့်အခါတွင် သင်၏လုပ်ဖော်ကိုင်ဖက်သည် အရေးကြီးဆုံးပြဿနာကို ရွေးချယ်လိုက်ခြင်းဖြစ်သည်။

လုပ်ဆောင်ချက်တွင် ဤဇာတ်လမ်းကို စမ်းသပ်ရန်အတွက် SA-Logic ၏ ဒုတိယဥပမာကို bugs ဖြင့် ဖန်တီးကြပါစို့ (buggyအောက်ပါ command ကို run ခြင်းဖြင့်)

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

ယခုတွင် instances အားလုံးကို သေချာအောင် command ကို run ကြပါစို့ 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 instances များသို့ ပေးပို့ပြီး v2 instances များသို့ ပြောင်းပြန်လှန်စေလိုသည်-

စည်းမျဉ်းများသည် VirtualService ၏ လမ်းကြောင်းခွဲများနှင့် လမ်းကြောင်းများကို သတ်သတ်မှတ်မှတ်ခွဲတစ်ခုသို့ သတ်မှတ်ပေးမည့် DestinationRule နှင့် ပေါင်းစပ်ထားသော VirtualService မှတဆင့် ၎င်းကို အောင်မြင်ပါမည်။

Destination စည်းမျဉ်းများတွင် အပိုင်းခွဲများကို သတ်မှတ်ခြင်း။

အပိုင်းများ (အခွဲများ) အောက်ပါ configuration အားဖြင့်ဆုံးဖြတ်ကြသည် (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

1. အိမ်ရှင် (host) ဤစည်းမျဉ်းသည် ဝန်ဆောင်မှုဆီသို့ လမ်းကြောင်းသွားသည့်အခါ ကိစ္စများတွင်သာ သက်ဆိုင်သည်ဟု သတ်မှတ်သည်။ sa-logic;
2. ခေါင်းစဉ်များ (nameအစုခွဲများကို လမ်းကြောင်းပေးသည့်အခါတွင် အခွဲများကို အသုံးပြုသည်။
3. အညွှန်း (label) အစုခွဲ၏ အစိတ်အပိုင်းတစ်ခုဖြစ်လာရန် သာဓကများနှင့် ကိုက်ညီရမည်ဖြစ်သော သော့တန်ဖိုးအတွဲများကို သတ်မှတ်သည်။

အောက်ပါ command ဖြင့် configuration ကိုအသုံးပြုပါ-

$ 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-subsets-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

အောက်ပါ command ကိုခေါ်ဆိုခြင်းဖြင့် load ကိုထည့်ကြပါစို့။

$ 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 အခွဲသို့ တောင်းဆိုချက်အား ပြန်ပြောင်းရန် ပြင်ဆင်ထားသည့် sidecar Envoy မှတဆင့် ဖြတ်သန်းပါသည်။ sa-logic.

Virtual Services သည် ရိုးရှင်းသည်ဟု သင် ထင်ကောင်းထင်နိုင်သည် ။ နောက်အပိုင်းမှာတော့ သူတို့က တကယ်ကောင်းတယ်လို့ ပြောခြင်းအားဖြင့် အဲဒါကို အကျယ်ချဲ့ပြောပါမယ်။

ကိန္နရီ ဖြန့်ချိရေး

Canary Deployment သည် အသုံးပြုသူအနည်းစုထံသို့ အက်ပလီကေးရှင်းဗားရှင်းအသစ်ကို ဖြန့်ချိသည့်လုပ်ငန်းစဉ်ဖြစ်သည်။ ထုတ်ဝေမှုတွင် ပြဿနာမရှိကြောင်း သေချာစေရန်အတွက် ၎င်းကို အသုံးပြုပြီးမှသာ ၎င်း၏ (ဖြန့်ချိမှု) အရည်အသွေးကို ယုံကြည်ပြီး အခြားအသုံးပြုသူများထံ ဖြန့်ဝေပါ။оပရိတ်သတ်ကြီး။

Canary ဖြန့်ချိမှုများကို သရုပ်ပြရန်၊ ကျွန်ုပ်တို့သည် အပိုင်းခွဲတစ်ခုဖြင့် ဆက်လက်လုပ်ဆောင်သွားပါမည်။ buggy у sa-logic.

အသေးအမွှားကိစ္စများတွင် အချိန်မဖြုန်းဘဲ သုံးစွဲသူ 20% ကို bug များဖြင့် ဗားရှင်းသို့ ချက်ခြင်းပို့ပါ (၎င်းက ကျွန်ုပ်တို့၏ canary rollout ကို ကိုယ်စားပြုသည်) နှင့် ကျန် 80% ကို ပုံမှန်ဝန်ဆောင်မှုသို့ ပေးပို့ပါ။ ဒီလိုလုပ်ဖို့၊ အောက်ပါ VirtualService ကိုသုံးပါ (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 အောက်ပါ command ဖြင့်

$ 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 ဖြန့်ချိမှုများကို လုပ်ဆောင်နိုင်သည်- ဤကိစ္စတွင်၊ ကျွန်ုပ်တို့သည် ပြဿနာများ၏ ဖြစ်နိုင်ခြေရှိသော သက်ရောက်မှုကို အသုံးပြုသူအခြေခံ၏ 20% သို့ ကျဉ်းမြောင်းသွားပါသည်။ အံ့သြဖွယ်! ယခု၊ ကျွန်ုပ်တို့၏ကုဒ်ကို မသေချာသည့်အခါတိုင်း (တစ်နည်းအားဖြင့် - အမြဲတမ်း...)၊ ကျွန်ုပ်တို့သည် mirroring နှင့် canary rollouts ကိုသုံးနိုင်သည်။

အချိန်ကုန်ပြီး ပြန်စမ်းပါ။

သို့သော် bug များသည် ကုဒ်တွင် အမြဲမဆုံးပါ။ စာရင်းထဲမှာ "8 Distributed Computing အကြောင်း အထင်အမြင်လွဲမှားမှုများ"ပထမနေရာတွင် "ကွန်ရက်သည် ယုံကြည်စိတ်ချရသော" ဟူသော မှားယွင်းသောယုံကြည်ချက်ဖြစ်သည်။ တကယ်တော့ ကွန်ရက် မဟုတ် ယုံကြည်စိတ်ချရသော၊ ဤအကြောင်းကြောင့် ကျွန်ုပ်တို့သည် အချိန်ကုန်ရန် လိုအပ်ပါသည်။ (အချိန်ကုန်သွားသည်) ထပ်ကြိုးစားတယ်။ (ထပ်စမ်းပါ).

သရုပ်ပြရန်အတွက် ကျွန်ုပ်တို့သည် တူညီသောပြဿနာဗားရှင်းကို ဆက်လက်အသုံးပြုပါမည်။ sa-logic (buggy) နှင့် ကျွန်ုပ်တို့သည် ကျပန်းပျက်ကွက်မှုများဖြင့် ကွန်ရက်၏ မယုံကြည်နိုင်မှုကို အတုယူပါမည်။

bug များဖြင့် ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုသည် တုံ့ပြန်ရန် 1/3 ကြာမြင့်မည့်အခွင့်အရေး၊ Internal Server Error နှင့် အဆုံးသတ်ရန် 1/3 အခွင့်အလမ်းနှင့် စာမျက်နှာကို အောင်မြင်စွာပြန်ပို့ရန် 1/3 အခွင့်အရေးရှိသည်။

ထိုကဲ့သို့သော ပြဿနာများ၏ သက်ရောက်မှုကို လျော့ပါးစေရန်နှင့် သုံးစွဲသူများအတွက် ဘဝပိုမိုကောင်းမွန်စေရန်၊ ကျွန်ုပ်တို့ လုပ်ဆောင်နိုင်သည်-

1. ဝန်ဆောင်မှုသည် တုံ့ပြန်ရန် 8 စက္ကန့်ထက် ပိုကြာပါက အချိန်ကုန်သွားခြင်း၊
2. တောင်းဆိုမှု မအောင်မြင်ပါက ပြန်လည်ကြိုးစားပါ။

အကောင်အထည်ဖော်ရန်အတွက်၊ ကျွန်ုပ်တို့သည် အောက်ပါ အရင်းအမြစ် အဓိပ္ပါယ်ဖွင့်ဆိုချက်ကို အသုံးပြုပါမည် (sa-logic-retries-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 စက္ကန့်ထက် ပိုစောင့်ဆိုင်းရန် မလိုအပ်သောကြောင့် ပိုမိုကောင်းမွန်အောင်ပြုလုပ်ခြင်းဖြစ်ပြီး ပျက်ကွက်မှုများရှိပါက တုံ့ပြန်မှုအသစ်သုံးကြိမ်ပြုလုပ်ကာ အောင်မြင်သောတုံ့ပြန်မှုအခွင့်အလမ်းကို တိုးမြင့်ပေးမည်ဖြစ်သည်။

အောက်ပါ command ဖြင့် အပ်ဒိတ်လုပ်ထားသော ဖွဲ့စည်းမှုပုံစံကို အသုံးပြုပါ-

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

အထက်တွင် အောင်မြင်သော တုံ့ပြန်မှုအရေအတွက် တိုးလာကြောင်း Grafana ဂရပ်များကို စစ်ဆေးပါ-

အချိန်ကုန်ခြင်းနှင့် ထပ်ခါထပ်ခါ ပေါင်းထည့်ပြီးနောက် အောင်မြင်သော တုံ့ပြန်မှုစာရင်းဇယားများတွင် တိုးတက်မှုများ

နောက်အပိုင်းကို ဆက်မသွားခင် (ဒါမှမဟုတ် ဆောင်းပါးရဲ့ နောက်အပိုင်းအတွက်၊ ဘာကြောင့်လဲဆိုတော့ ဒီထဲမှာ လက်တွေ့စမ်းသပ်မှုတွေ ရှိတော့မှာ မဟုတ်ဘူး - ခန့်မှန်းခြေ ဘာသာပြန်တယ်။), ဖျက် sa-logic-buggy အောက်ပါ command များကို run ခြင်းဖြင့် 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 ပုံစံများ

ကျွန်ုပ်တို့သည် သင့်အား မိမိကိုယ်ကို ပြန်လည်နာလန်ထူလာစေရန် ခွင့်ပြုပေးသော မိုက်ခရိုဆားဗစ်ဗိသုကာတွင် အရေးကြီးသောပုံစံနှစ်ခုအကြောင်း ပြောနေပါသည်။ (မိမိကိုယ်ကို ကုသခြင်း) ဝန်ဆောင်မှုများ။

တိုက်နယ်တနေ့ ("ဆားကစ်ဖြတ်ကိရိယာ") ကျန်းမာရေးမကောင်းဟု ယူဆသော ဝန်ဆောင်မှုတစ်ခု၏ ဥပမာတစ်ခုထံ ရောက်ရှိလာသော တောင်းဆိုမှုများကို ရပ်တန့်ရန်နှင့် သုံးစွဲသူများ၏ တောင်းဆိုမှုများကို ထိုဝန်ဆောင်မှု၏ ကောင်းမွန်သောအခြေအနေများသို့ ပြန်ညွှန်းနေချိန်တွင် (အောင်မြင်သော တုံ့ပြန်မှု ရာခိုင်နှုန်းကို တိုးစေသည်)။ (မှတ်ချက်- ဥပမာအားဖြင့် ပုံစံ၏ အသေးစိတ်ဖော်ပြချက်ကို ရှာတွေ့နိုင်သည်၊ ဥပမာ၊ ဒီမှာ.)

။ ("အပိုင်းပိုင်း") ဝန်ဆောင်မှု ချို့ယွင်းချက်များကို စနစ်တစ်ခုလုံးကို ထိခိုက်စေခြင်းမှ ခွဲထုတ်သည်။ ဥပမာအားဖြင့်၊ Service B ပျက်သွားကာ အခြားဝန်ဆောင်မှု (Service B ၏ client) သည် Service B သို့ တောင်းဆိုချက်တစ်ခုပြုလုပ်ပြီး ၎င်းသည် ၎င်း၏ thread pool ကိုကုန်ဆုံးစေပြီး အခြားသောတောင်းဆိုမှုများကို ဆောင်ရွက်ပေးနိုင်ခြင်း (၎င်းတို့သည် Service B မှမဟုတ်လျှင်ပင်)။ (မှတ်ချက်- ဥပမာအားဖြင့် ပုံစံ၏ အသေးစိတ်ဖော်ပြချက်ကို ရှာတွေ့နိုင်သည်၊ ဥပမာ၊ ဒီမှာ.)

ရှာဖွေရလွယ်ကူသောကြောင့် ဤပုံစံများ၏ အကောင်အထည်ဖော်မှုအသေးစိတ်အချက်အလက်များကို ကျွန်ုပ်ချန်လှပ်ထားပါမည်။ တရားဝင်စာရွက်စာတမ်းပြီးတော့ ဆောင်းပါးရဲ့ နောက်အပိုင်းမှာ ဆွေးနွေးမယ့် စစ်မှန်ကြောင်းအထောက်အထားနဲ့ ခွင့်ပြုချက်ကို ကျွန်တော် တကယ်ပြချင်ပါတယ်။

PS ဘာသာပြန်မှ

ကျွန်ုပ်တို့၏ဘလော့ဂ်တွင်လည်းဖတ်ပါ

• "Istio ဖြင့် အသေးစားဝန်ဆောင်မှုများသို့ ပြန်သွားရန်"- အပိုင်း 1 (အဓိကအင်္ဂါရပ်များမိတ်ဆက်), အပိုင်း ၃ (စစ်မှန်ကြောင်းနှင့် ခွင့်ပြုချက်);
• «Conduit - Kubernetes အတွက် ပေါ့ပါးသော ဝန်ဆောင်မှုကွက်";
• «ဝန်ဆောင်မှု mesh ဆိုတာ ဘာလဲ၊ [မိုက်ခရိုဝန်ဆောင်မှုများပါသော cloud application တစ်ခုအတွက်] ဘာကြောင့် လိုအပ်တာလဲ။"။

source: www.habr.com