Istio နှင့် Linkerd အတွက် CPU သုံးစွဲမှုစံနှုန်း

နိဒါန်း

ကျွန်ုပ်တို့၌ရှိသည် Shopify Istio ကို service mesh အဖြစ် စတင်အသုံးပြုခဲ့သည်။ မူအရ၊ အရာတစ်ခုမှလွဲ၍ အရာအားလုံးအဆင်ပြေသည်- ဈေးကြီးတယ်။.

В စံနှုန်းများကို ထုတ်ပြန်ခဲ့သည်။ Istio အတွက်တော့

Istio 1.1 ဖြင့်၊ ပရောက်စီသည် တစ်စက္ကန့်လျှင် တောင်းဆိုမှု 0,6 လျှင် ခန့်မှန်းခြေ 1000 vCPUs (virtual cores) ကို စားသုံးပါသည်။

ဝန်ဆောင်မှု mesh ရှိ ပထမဒေသအတွက် (ချိတ်ဆက်မှု၏တစ်ဖက်စီရှိ ပရောက်စီ 2 ခု) အတွက် ကျွန်ုပ်တို့သည် တစ်စက္ကန့်လျှင် တောင်းဆိုချက်တစ်သန်းနှုန်းဖြင့် proxy အတွက်သာ cores 1200 ရှိပါမည်။ Google ၏ကုန်ကျစရိတ်ဂဏန်းတွက်စက်အရ၊ ၎င်းသည် configuration အတွက်ခန့်မှန်းခြေအားဖြင့် တစ်လလျှင် $40/core ဖြစ်သည် n1-standard-64ဆိုလိုသည်မှာ၊ ဤဒေသတစ်ခုတည်းသည် တစ်စက္ကန့်လျှင် တောင်းဆိုမှု ၁ သန်းအတွက် တစ်လလျှင် ဒေါ်လာ ၅၀,ဝဝဝ ကျော် ကုန်ကျမည်ဖြစ်သည်။

အိုင်ဗန် Sim (Ivan Sim) အမြင်အာရုံနှိုင်းယှဥ် service mesh သည် ယမန်နှစ်က နှောင့်နှေးခဲ့ပြီး memory နှင့် processor အတွက် အလားတူ ကတိပေးခဲ့သော်လည်း အလုပ်မဖြစ်ခဲ့ပါ။

ထင်ရှားသည်မှာ values-istio-test.yaml သည် CPU တောင်းဆိုမှုများကို အလေးအနက်ထား တိုးလာမည်ဖြစ်သည်။ ကျွန်ုပ်၏သင်္ချာကို မှန်ကန်စွာလုပ်ဆောင်ပါက၊ သင်သည် control panel အတွက် ခန့်မှန်းခြေ 24 CPU cores နှင့် proxy တစ်ခုစီအတွက် 0,5 CPU လိုအပ်ပါသည်။ ငါ့မှာ အဲဒီလောက် မရှိဘူး။ ကျွန်ုပ်အတွက် အရင်းအမြစ်များ ပိုမိုခွဲဝေပေးသောအခါတွင် ကျွန်ုပ်အား စမ်းသပ်မှုများ ထပ်မံပြုလုပ်ပါမည်။

Istio ၏ စွမ်းဆောင်ရည်သည် အခြားသော open source ဝန်ဆောင်မှု mesh နှင့် မည်မျှဆင်တူသည်ကို ကျွန်ုပ်ကိုယ်တိုင် မြင်ချင်ပါသည်။ Linkerd.

Service mesh တပ်ဆင်ခြင်း။

ပထမဦးစွာ၊ ကျွန်ုပ်သည် ၎င်းကို အစုအဝေးတစ်ခုတွင် ထည့်သွင်းခဲ့သည်။ SuperGloo:

$ supergloo init
installing supergloo version 0.3.12
using chart uri https://storage.googleapis.com/supergloo-helm/charts/supergloo-0.3.12.tgz
configmap/sidecar-injection-resources created
serviceaccount/supergloo created
serviceaccount/discovery created
serviceaccount/mesh-discovery created
clusterrole.rbac.authorization.k8s.io/discovery created
clusterrole.rbac.authorization.k8s.io/mesh-discovery created
clusterrolebinding.rbac.authorization.k8s.io/supergloo-role-binding created
clusterrolebinding.rbac.authorization.k8s.io/discovery-role-binding created
clusterrolebinding.rbac.authorization.k8s.io/mesh-discovery-role-binding created
deployment.extensions/supergloo created
deployment.extensions/discovery created
deployment.extensions/mesh-discovery created
install successful!

ဝန်ဆောင်မှု mesh ကို bootstrapping ပိုလွယ်ကူစေသောကြောင့် SuperGloo ကိုအသုံးပြုခဲ့သည်။ အများကြီးလုပ်စရာမလိုဘူး။ ကျွန်ုပ်တို့သည် ထုတ်လုပ်ရေးတွင် SuperGloo ကို အသုံးမပြုသော်လည်း ထိုသို့သောအလုပ်အတွက် အကောင်းဆုံးဖြစ်သည်။ service mesh တစ်ခုစီအတွက် command နှစ်ခုကို စာသားအတိုင်း သုံးခဲ့ရပါတယ်။ Istio နှင့် Linkerd အတွက် တစ်ခုစီကို သီးခြားခွဲထုတ်ရန်အတွက် အစုနှစ်ခုကို ကျွန်တော်အသုံးပြုခဲ့သည်။

စမ်းသပ်မှုကို Google Kubernetes Engine တွင် ပြုလုပ်ခဲ့သည်။ Kubernetes ကိုသုံးခဲ့တယ်။ 1.12.7-gke.7 နှင့် nodes ၏ရေကန် n1-standard-4 အလိုအလျောက် node အတိုင်းအတာဖြင့် (အနည်းဆုံး 4၊ အမြင့်ဆုံး 16)။

ထို့နောက် ကျွန်ုပ်သည် command line မှ service meshes နှစ်ခုလုံးကို install လုပ်ခဲ့သည်။

ပထမဆုံး Linkerd-

$ supergloo install linkerd --name linkerd
+---------+--------------+---------+---------------------------+
| INSTALL |     TYPE     | STATUS  |          DETAILS          |
+---------+--------------+---------+---------------------------+
| linkerd | Linkerd Mesh | Pending | enabled: true             |
|         |              |         | version: stable-2.3.0     |
|         |              |         | namespace: linkerd        |
|         |              |         | mtls enabled: true        |
|         |              |         | auto inject enabled: true |
+---------+--------------+---------+---------------------------+

ထို့နောက် Istio-

$ supergloo install istio --name istio --installation-namespace istio-system --mtls=true --auto-inject=true
+---------+------------+---------+---------------------------+
| INSTALL |    TYPE    | STATUS  |          DETAILS          |
+---------+------------+---------+---------------------------+
| istio   | Istio Mesh | Pending | enabled: true             |
|         |            |         | version: 1.0.6            |
|         |            |         | namespace: istio-system   |
|         |            |         | mtls enabled: true        |
|         |            |         | auto inject enabled: true |
|         |            |         | grafana enabled: true     |
|         |            |         | prometheus enabled: true  |
|         |            |         | jaeger enabled: true      |
+---------+------------+---------+---------------------------+

crash-loop သည် မိနစ်အနည်းငယ်ကြာပြီးနောက် control panels များတည်ငြိမ်သွားသည်။

(မှတ်ချက်- SuperGloo သည် ယခုလောလောဆယ်တွင် Istio 1.0.x ကိုသာ ပံ့ပိုးပေးပါသည်။ Istio 1.1.3 နှင့် စမ်းသပ်ချက်ကို ထပ်ခါတလဲလဲ ပြုလုပ်ခဲ့သော်လည်း သိသာထင်ရှားသော ခြားနားချက်ကို မတွေ့မိပါ။)

Istio အလိုအလျောက် ဖြန့်ကျက်မှုကို စနစ်ထည့်သွင်းခြင်း။

Istio သည် sidecar Envoy ကိုတပ်ဆင်ရန်၊ ကျွန်ုပ်တို့သည် sidecar injector − ကိုအသုံးပြုသည်။ MutatingAdmissionWebhook. ဤဆောင်းပါးတွင် ၎င်းအကြောင်းကို ကျွန်ုပ်တို့ မပြောပါ။ ဤအရာသည် pods အသစ်များအားလုံး၏ ဝင်ရောက်မှုကို စောင့်ကြည့်သည့် ထိန်းချုပ်ကိရိယာဖြစ်ပြီး အလုပ်များအတွက် တာဝန်ရှိသည့် sidecar နှင့် initContainer တို့ကို ဒိုင်းနမစ်ဖြင့် ထည့်သွင်းပေးသည် iptables.

Shopify တွင်ကျွန်ုပ်တို့သည်ဆိုက်ကားများကိုအကောင်အထည်ဖော်ရန်ကျွန်ုပ်တို့၏ကိုယ်ပိုင်ဝင်ရောက်ခွင့်ထိန်းချုပ်ကိရိယာကိုရေးသားခဲ့သည်၊ သို့သော်ဤစံညွှန်းအတွက်ကျွန်ုပ်သည် Istio ပါရှိသောထိန်းချုပ်ကိရိယာကိုအသုံးပြုခဲ့သည်။ namespace တွင် shortcut တစ်ခုရှိသောအခါ controller သည် sidecars များကိုပုံမှန်အားဖြင့်ထိုးသွင်းသည်။ istio-injection: enabled:

$ kubectl label namespace irs-client-dev istio-injection=enabled
namespace/irs-client-dev labeled

$ kubectl label namespace irs-server-dev istio-injection=enabled
namespace/irs-server-dev labeled

အလိုအလျောက် Linkerd ဖြန့်ကျက်မှုကို စနစ်ထည့်သွင်းခြင်း။

Linkerd sidecar မြှပ်နှံခြင်းကို စနစ်ထည့်သွင်းရန်၊ ကျွန်ုပ်တို့သည် မှတ်ချက်များကို အသုံးပြုသည် (ကျွန်ုပ်တို့သည် ၎င်းတို့ကို ကိုယ်တိုင်ထည့်သွင်းထားသည်။ kubectl edit):

metadata:
  annotations:
    linkerd.io/inject: enabled

$ k edit ns irs-server-dev 
namespace/irs-server-dev edited

$ k get ns irs-server-dev -o yaml
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    linkerd.io/inject: enabled
  name: irs-server-dev
spec:
  finalizers:
  - kubernetes
status:
  phase: Active

Istio Fault Tolerance Simulator

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

Flash အရောင်းအ၀ယ်ပြုလုပ်နေစဉ် Shopify ၏အခြေခံအဆောက်အအုံသည် ကြီးမားသောဝန်ထုပ်ဝန်ပိုးဖြစ်နေသည်။ တစ်ချိန်တည်းမှာပင်၊ Shopify ထိုသို့သောအရောင်းကို မကြာခဏပြုလုပ်ရန် ရောင်းချသူများကို အကြံပြုထားသည်။. ဖောက်သည်ကြီးများသည် ရံဖန်ရံခါတွင် စီစဉ်ထားသော flash sale အကြောင်း သတိပေးသည်။ အခြားသူများသည် ကျွန်ုပ်တို့အတွက် နေ့ရောညပါ အချိန်မရွေး ၎င်းတို့ကို မမျှော်လင့်ဘဲ ပေးဆောင်ကြသည်။

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

fault tolerance simulator ၏ အဓိကအချက်မှာ service mesh node တစ်ခုအနေဖြင့် လုပ်ဆောင်သည့် worker node တစ်ခုဖြစ်သည်။ အလုပ်သမား node အား စတင်ချိန်တွင် တည်ငြိမ်စွာ သို့မဟုတ် REST API မှတဆင့် dynamically configure လုပ်နိုင်ပါသည်။ ကျွန်ုပ်တို့သည် ဆုတ်ယုတ်မှုစမ်းသပ်မှုပုံစံဖြင့် အလုပ်အသွားအလာများဖန်တီးရန် အလုပ်သမား node များ၏ တက်ကြွသောဖွဲ့စည်းမှုပုံစံကို အသုံးပြုပါသည်။

ဤသည်မှာ ဤကဲ့သို့သော လုပ်ငန်းစဉ်၏ ဥပမာတစ်ခုဖြစ်သည်။

• ကျွန်ုပ်တို့အနေဖြင့် ဆာဗာ 10 ခုကို စတင်လိုက်ပါသည်။ bar တုံ့ပြန်မှုကို ပြန်ပေးသည့် ဝန်ဆောင်မှု 200/OK 100 ms ပြီးနောက်
• ကျွန်ုပ်တို့သည် ဖောက်သည် 10 ဦးကို စတင်လုပ်ဆောင်သည် - တစ်ခုစီသည် တစ်စက္ကန့်လျှင် တောင်းဆိုချက် 100 ပေးပို့သည်။ bar.
• 10 စက္ကန့်တိုင်း ကျွန်ုပ်တို့သည် ဆာဗာ 1 ခုကို ဖယ်ရှားပြီး အမှားများကို စောင့်ကြည့်ပါသည်။ 5xx client ပေါ်မှာ။

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

(မှတ်ချက်- Istio fault tolerance simulator ကို ပွင့်လင်းမြင်သာစွာရှာဖွေရန် ကျွန်ုပ်တို့ စဉ်းစားနေသော်လည်း ထိုသို့လုပ်ဆောင်ရန် အဆင်သင့်မဖြစ်သေးပါ။)

ဝန်ဆောင်မှု mesh စံနှုန်းအတွက် Istio အမှားခံနိုင်ရည်ရှိခြင်း simulator

ကျွန်ုပ်တို့သည် Simulator ၏ အလုပ်လုပ်ဆောင်မှုဆိုင်ရာ node အများအပြားကို တည်ဆောက်သည်-

• irs-client-loadgen- တစ်စက္ကန့်လျှင် တောင်းဆိုချက် 3 ပေးပို့သော ပုံတူ 100 ခု irs-client.
• irs-client: တောင်းဆိုချက်လက်ခံရရှိသည့် ပုံတူ ၃ ခု၊ 3ms စောင့်ပြီး တောင်းဆိုချက်ကို ထပ်ဆင့်ပို့ပါ။ irs-server.
• irs-server: ပြန်လာသော ပုံတူ ၃ ခု 200/OK 100 ms ပြီးနောက်

ဤဖွဲ့စည်းပုံဖြင့်၊ အဆုံးမှတ် ၉ ခုကြားတွင် တည်ငြိမ်သောလမ်းကြောင်းစီးဆင်းမှုကို တိုင်းတာနိုင်သည်။ ဆိုက်ကားထဲဝင် irs-client-loadgen и irs-server တစ်စက္ကန့်လျှင် တောင်းဆိုချက် 100 ကိုလက်ခံရယူပါ။ irs-client - ၂၀၀ (အဝင်အထွက်)။

ကျွန်ုပ်တို့သည် အရင်းအမြစ်အသုံးပြုမှုကို ခြေရာခံသည်။ DataDogကျွန်ုပ်တို့တွင် Prometheus အစုအဝေးမရှိသောကြောင့်ဖြစ်သည်။

ရလဒ်များကို

Control panel များ

ပထမဦးစွာ၊ ကျွန်ုပ်တို့သည် CPU သုံးစွဲမှုကိုစစ်ဆေးသည်။

Linkerd ထိန်းချုပ်မှု panel ~22 millicore

Istio ထိန်းချုပ်မှုဘောင်- ~ 750 မီလီမီတာ

Istio ထိန်းချုပ်မှု panel သည် ခန့်မှန်းခြေအားဖြင့် အသုံးပြုသည်။ CPU အရင်းအမြစ် ၃၅ ဆ ပိုပါတယ်။Linkerd ထက် ဟုတ်ပါတယ်၊ အရာအားလုံးကို မူရင်းအတိုင်း ထည့်သွင်းထားပြီး istio-telemetry သည် ဤနေရာတွင် ပရိုဆက်ဆာအရင်းအမြစ်များစွာကို အသုံးပြုသည် (အချို့သောလုပ်ဆောင်ချက်များကို ပိတ်ထားခြင်းဖြင့် ၎င်းကိုပိတ်ထားနိုင်သည်)။ ဤအစိတ်အပိုင်းကို ဖယ်ရှားပါက၊ ကျွန်ုပ်တို့သည် 100 millicores ထက်ပို၍ ရသေးသည်။ ၁.၂ ဆပိုများပါတယ်Linkerd ထက်

ဆိုက်ကား ပရောက်စီ

ထို့နောက် ကျွန်ုပ်တို့သည် ပရောက်စီအသုံးပြုမှုကို စမ်းသပ်ခဲ့သည်။ တောင်းဆိုမှုအရေအတွက်နှင့် တစ်ပြေးညီ ဆက်စပ်မှုရှိသင့်သော်လည်း ဘေးတွဲကားတစ်ခုစီအတွက် မျဉ်းကွေးကို သက်ရောက်မှုရှိသော ထိပ်ပိုင်းအချို့ရှိသည်။

Linkerd- irs-client အတွက် ~100 millicores၊ irs-client-loadgen အတွက် ~50 millicores

ရလဒ်များသည် ယုတ္တိရှိပုံပေါ်သည်၊ အကြောင်းမှာ ကလိုင်းယင့်ပရောက်စီသည် loadgen proxy ထက် အသွားအလာ နှစ်ဆပိုမိုရရှိသောကြောင့်ဖြစ်သည်- loadgen မှ ထွက်ထွက်တောင်းဆိုမှုတိုင်းအတွက်၊ client တွင် အဝင်တစ်ခုနှင့် အထွက်တစ်ခုရှိသည်။

Istio/Envoy- irs-client အတွက် ~155 millicores၊ irs-client-loadgen အတွက် ~75 millicores

Istio ဆိုက်ကားများအတွက် အလားတူရလဒ်များကို ကျွန်ုပ်တို့မြင်ရသည်။

သို့သော် ယေဘုယျအားဖြင့် Istio/Envoy proxy များသည် စားသုံးကြသည်။ ခန့်မှန်းခြေ 50% ပို CPU အရင်းအမြစ်များLinkerd ထက်

ဆာဗာဘက်ခြမ်းတွင် တူညီသောအစီအစဥ်ကို ကျွန်ုပ်တို့မြင်ရသည်-

Linkerd- irs-ဆာဗာအတွက် ~50 millicore

Istio/Envoy- irs-ဆာဗာအတွက် ~80 millicore

ဆာဗာဘက်တွင်၊ ဘေးတွဲကား Istio/Envoy စားသုံးသည်။ ခန့်မှန်းခြေ 60% ပို CPU အရင်းအမြစ်များLinkerd ထက်

ကောက်ချက်

Istio Envoy proxy သည် ကျွန်ုပ်တို့၏ သရုပ်ဖော်လုပ်ဆောင်မှုတွင် Linkerd ထက် CPU 50+% ပိုမိုစားသုံးပါသည်။ Linkerd ထိန်းချုပ်မှု panel သည် အထူးသဖြင့် core အစိတ်အပိုင်းများအတွက် Istio ထက် အရင်းအမြစ်များကို အလွန်နည်းသည်။

ဒီကုန်ကျစရိတ်တွေကို ဘယ်လိုလျှော့ချရမလဲဆိုတာကို ကျွန်တော်တို့ စဉ်းစားနေတုန်းပါပဲ။ အကြံဥာဏ်တွေရှိရင် မျှဝေပေးပါဦး။

source: www.habr.com