အင်တာနက်ကိုတွင် စည်း ဆောင်းပါးများ о ဝန်ဆောင်မှုကွက် (service mesh) ၊ ဒါက နောက်တစ်မျိုး။ ဟူး! ဒါနဲ့ဘာဖြစ်လို့လဲ? ထို့နောက် Docker နှင့် Kubernetes ကဲ့သို့သော ကွန်တိန်နာပလပ်ဖောင်းများ မထွန်းကားမီ လွန်ခဲ့သည့် 10 နှစ်က ဝန်ဆောင်မှု Meshes များ ပေါ်ထွန်းလာပါက ပိုကောင်းမည်ဟု ကျွန်ုပ်၏ ထင်မြင်ချက်ကို ဖော်ပြလိုပါသည်။ ကျွန်ုပ်၏အမြင်သည် အခြားသူများထက် ပိုကောင်းသည် သို့မဟုတ် ပိုဆိုးသည်ဟု မဆိုလိုပါ၊ သို့သော် ဆားဗစ်ကွက်များသည် အလွန်ရှုပ်ထွေးသော တိရိစ္ဆာန်များဖြစ်သောကြောင့်၊ ရှုထောင့်များစွာက ၎င်းတို့ကို ပိုမိုနားလည်ရန် ကူညီပေးပါလိမ့်မည်။

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

dotCloud ၏သမိုင်း

dotCloud ၏သမိုင်းကြောင်းနှင့် ဤပလပ်ဖောင်းအတွက် ဗိသုကာရွေးချယ်မှုများအကြောင်း ရေးသားထားသော်လည်း ကွန်ရက်အလွှာအကြောင်း သိပ်မပြောဖြစ်ပါ။ စာမဖတ်ချင်ဘူးဆိုရင် နောက်ဆုံးဆောင်းပါး dotCloud အကြောင်း၊ အတိုချုပ်ပြောရလျှင် ဤသည်မှာ အတိုချုပ်အားဖြင့်- ၎င်းသည် သုံးစွဲသူများအား ကျယ်ပြန့်သော အပလီကေးရှင်းများ (Java၊ PHP၊ Python...) ကို ဒေတာများစွာ ပံ့ပိုးပေးသည့် PaaS ပလပ်ဖောင်း-as-a-service တစ်ခုဖြစ်သည်။ ဝန်ဆောင်မှုများ (MongoDB၊ MySQL၊ Redis...) နှင့် Heroku ကဲ့သို့သော အလုပ်အသွားအလာတစ်ခု- သင်သည် သင်၏ကုဒ်ကို ပလပ်ဖောင်းသို့ အပ်လုဒ်လုပ်ကာ၊ ၎င်းသည် ကွန်တိန်နာပုံများကို တည်ဆောက်ပြီး ၎င်းတို့ကို အသုံးချသည်။

dotCloud ပလပ်ဖောင်းသို့ လမ်းကြောင်းအသွားအလာကို မည်ကဲ့သို့ ဦးတည်ထားသည်ကို ပြောပြပါမည်။ အထူးကောင်းမွန်သောကြောင့် မဟုတ်ဘဲ (စနစ်သည် အချိန်အတွက် ကောင်းမွန်သော်လည်း!)၊ သို့သော် အဓိကအားဖြင့် ခေတ်မီကိရိယာများဖြင့် ပေါ့ပေါ့ပါးပါးအဖွဲ့တစ်ဖွဲ့က ၎င်းတို့သည် လမ်းကြောင်းတစ်ခုကြားလမ်းကြောင်းကို လမ်းကြောင်းပေးလိုပါက အချိန်တိုအတွင်း လွယ်ကူစွာအကောင်အထည်ဖော်နိုင်သောကြောင့်ဖြစ်သည်။ မိုက်ခရိုဝန်ဆောင်မှုများ သို့မဟုတ် အသုံးချပလီကေးရှင်းများ။ ဤနည်းအားဖြင့် သင်သည် ရွေးချယ်စရာများကို နှိုင်းယှဉ်နိုင်သည်- သင်သည် အရာအားလုံးကို သင်ကိုယ်တိုင် ဖန်တီးခြင်း သို့မဟုတ် ရှိပြီးသား ဝန်ဆောင်မှု mesh ကို အသုံးပြုပါက ဘာဖြစ်မည်နည်း။ စံရွေးချယ်မှုမှာ ကိုယ်တိုင်ပြုလုပ်ရန် သို့မဟုတ် ဝယ်ရန်ဖြစ်သည်။

လက်ခံထားသည့် အက်ပ်လီကေးရှင်းများအတွက် လမ်းကြောင်းလမ်းကြောင်း

dotCloud ရှိ အပလီကေးရှင်းများသည် HTTP နှင့် TCP အဆုံးမှတ်များကို ဖော်ထုတ်နိုင်သည်။

HTTP အဆုံးမှတ်များ load balancer cluster configuration တွင် ဒိုင်းနမစ်ဖြင့် ထည့်သွင်းထားသည်။ Hipache. ၎င်းသည် ယနေ့ခေတ် အရင်းအမြစ်များ လုပ်ဆောင်ပုံနှင့် ဆင်တူသည်။ Ingress Kubernetes နှင့် load balancer ကဲ့သို့ဖြစ်သည်။ Traefik.

ဒိုမိန်းအမည်သည် dotCloud load balancers သို့ညွှန်ပြပေးသော ဖောက်သည်များသည် သင့်လျော်သောဒိုမိန်းများမှတစ်ဆင့် HTTP အဆုံးမှတ်များသို့ ချိတ်ဆက်သည်။ ဘာမှ မထူးခြားပါဘူး။

TCP အဆုံးမှတ်များ ပတ်ဝန်းကျင် ကိန်းရှင်များမှတစ်ဆင့် ထိုစစည်းရှိ ကွန်တိန်နာများအားလုံးသို့ ပို့တ်နံပါတ်တစ်ခုနှင့် ဆက်စပ်နေသည်။

ဖောက်သည်များသည် သင့်လျော်သော hostname (gateway-X.dotcloud.com ကဲ့သို့သော) နှင့် port နံပါတ်တို့ကို အသုံးပြု၍ TCP အဆုံးမှတ်များသို့ ချိတ်ဆက်နိုင်သည်။

ဤအိမ်ရှင်အမည်သည် “nats” ဆာဗာအစုအဝေးသို့ ဖြေရှင်းပေးသည် (မသက်ဆိုင်ပါ။ NATS) အဝင် TCP ချိတ်ဆက်မှုများကို မှန်ကန်သော container (သို့မဟုတ် load-balanced services များတွင်၊ မှန်ကန်သော containers) သို့ လမ်းကြောင်းပေးမည်ဖြစ်သည်။

အကယ်၍ သင်သည် Kubernetes နှင့် ရင်းနှီးပါက၊ ၎င်းသည် သင့်အား ဝန်ဆောင်မှုများအကြောင်း သတိပေးနိုင်မည်ဖြစ်သည်။ NodePort.

dotCloud ပလပ်ဖောင်းတွင် တူညီသောဝန်ဆောင်မှုများမရှိပါ။ ClusterIP: ရိုးရှင်းစေရန်အတွက်၊ ဝန်ဆောင်မှုများကို ပလက်ဖောင်းအတွင်းနှင့် အပြင်ဘက်တွင် တူညီသောနည်းလမ်းဖြင့် ဝင်ရောက်အသုံးပြုခဲ့သည်။

အရာအားလုံးကို ရိုးရှင်းစွာဖွဲ့စည်းထားပါသည်- HTTP နှင့် TCP လမ်းကြောင်းသတ်မှတ်ခြင်းကွန်ရက်များ၏ ကနဦးအကောင်အထည်ဖော်မှုများသည် Python တစ်ခုစီ၏ လိုင်းရာဂဏန်းမျှသာဖြစ်နိုင်သည်။ ပလပ်ဖောင်းကြီးထွားလာသည်နှင့် ထပ်ဆင့်လိုအပ်ချက်များ ပေါ်လာသည်နှင့်အမျှ ရိုးရှင်းသော (နုံချာသည်ဟု ဆိုရမည်) အယ်လဂိုရီသမ်များ။

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

၎င်းသည် ခေတ်မီဝန်ဆောင်မှုကွက်နှင့် မည်သို့ကွာခြားသနည်း။

ကန့်သတ်ချက် မြင်နိုင်စွမ်း. ကျွန်ုပ်တို့တွင် TCP လမ်းကြောင်းပြကွက်အတွက် မည်သည့်တိုင်းတာမှုမျှ မရှိပါ။ HTTP လမ်းကြောင်းနှင့်ပတ်သက်လာသောအခါ၊ နောက်ပိုင်းဗားရှင်းများသည် အမှားကုဒ်များနှင့် တုံ့ပြန်မှုအချိန်များနှင့်အတူ အသေးစိတ် HTTP မက်ထရစ်များကို မိတ်ဆက်ခဲ့သည်၊ သို့သော် ခေတ်မီသောဝန်ဆောင်မှုအကွက်များသည် ဥပမာအားဖြင့် Prometheus ကဲ့သို့ မက်ထရစ်စုဆောင်းမှုစနစ်များနှင့် ပေါင်းစည်းမှုကို ပံ့ပိုးပေးပါသည်။

မြင်နိုင်မှုသည် လုပ်ငန်းလည်ပတ်မှု ရှုထောင့်မှသာမက (ပြဿနာများကို ဖြေရှင်းရန်) တွင်သာမက အင်္ဂါရပ်အသစ်များကို ထုတ်လွှတ်သည့်အခါတွင်လည်း အရေးကြီးပါသည်။ အဲဒါက ဘေးကင်းပါတယ်။ စိမ်းပြာ ဖြန့်ကျက်ခြင်း။ и Canary ဖြန့်ကျက်မှု.

Routing လုပ်တယ်။ အကန့်အသတ်လည်းရှိသည်။ dotCloud လမ်းကြောင်းပြကွက်တွင်၊ အသွားအလာအားလုံးသည် သီးခြားလမ်းကြောင်းပြခြင်းဆိုင်ရာ nodes အစုအဝေးတစ်ခုမှတဆင့် သွားရမည်ဖြစ်သည်။ ၎င်းသည် AZ (Availability Zone) နယ်နမိတ်များကို ဖြတ်ကျော်နိုင်ပြီး latency သိသိသာသာ တိုးလာနိုင်သည်။ စာမျက်နှာတစ်ခုလျှင် SQL queries တစ်ရာကျော်ပြုလုပ်ပြီး query တစ်ခုစီအတွက် SQL server သို့ ချိတ်ဆက်မှုအသစ်တစ်ခုဖွင့်လှစ်သည့် ပြဿနာဖြေရှင်းခြင်းကုဒ်ကို မှတ်မိပါသည်။ စက်တွင်းသုံးသည့်အခါ၊ စာမျက်နှာသည် ချက်ချင်းပွင့်လာသော်လည်း TCP ချိတ်ဆက်မှုတစ်ခုစီ (နှင့် နောက်ဆက်တွဲ SQL query) တစ်ခုစီသည် ဆယ်ဂဏန်းမီလီစက္ကန့်ကြာသောကြောင့် dotCloud တွင် တင်ရန် စက္ကန့်အနည်းငယ်ကြာသည်။ ဤကိစ္စတွင်၊ မြဲမြံသောဆက်သွယ်မှုများသည် ပြဿနာကို ဖြေရှင်းပေးသည်။

ခေတ်မီ ဝန်ဆောင်မှု ကွက်လပ်များသည် ထိုကဲ့သို့သော ပြဿနာများကို ကိုင်တွယ်ဖြေရှင်းရာတွင် ပိုမိုကောင်းမွန်ပါသည်။ ပထမဦးစွာ၊ ၎င်းတို့သည် ချိတ်ဆက်မှုများကို လမ်းကြောင်းပြောင်းကြောင်း စစ်ဆေးပါ။ အရင်းအမြစ်၌. logical flow သည် အတူတူပင်ဖြစ်သည်- клиент → меш → сервисသို့သော် ယခု mesh သည် စက်တွင်းတွင် အလုပ်လုပ်ပြီး remote node များတွင် မပါသောကြောင့် ချိတ်ဆက်မှုဖြစ်သည်။ клиент → меш ဒေသန္တရနှင့် အလွန်မြန်သည် (မီလီစက္ကန့်များအစား မိုက်ခရိုစက္ကန့်များ)။

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

လုံခွုံမှု ပိုကောင်းပါတယ်။ dotCloud လမ်းကြောင်းပြကွက်သည် EC2 Classic တွင် လုံးလုံးလျားလျား လည်ပတ်နေပြီး အသွားအလာကို စာဝှက်မထားပါ (တစ်စုံတစ်ဦးသည် EC2 ကွန်ရက်အသွားအလာတွင် sniffer တစ်ခုထည့်ရန် စီမံထားကြောင်း ယူဆချက်အပေါ် အခြေခံ၍ သင်သည် ပြဿနာကြီးကြီးမားမားရှိနေပြီ)။ ခေတ်မီ ဝန်ဆောင်မှု ကွက်လပ်များသည် ကျွန်ုပ်တို့၏ လမ်းကြောင်းအားလုံးကို ပွင့်လင်းမြင်သာစွာ ကာကွယ်ပေးပါသည်။ ဥပမာအားဖြင့်၊ အပြန်အလှန် TLS စစ်မှန်ကြောင်းနှင့် နောက်ဆက်တွဲ ကုဒ်ဝှက်ခြင်းတို့ဖြင့် ကာကွယ်ပါသည်။

ပလက်ဖောင်းဝန်ဆောင်မှုများအတွက် လမ်းကြောင်းလမ်းကြောင်း

ကောင်းပြီ၊ ကျွန်ုပ်တို့သည် အပလီကေးရှင်းများကြား အသွားအလာကို ဆွေးနွေးခဲ့ပြီးဖြစ်သော်လည်း dotCloud ပလပ်ဖောင်းကိုယ်တိုင်ကကော။

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

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

ဤအဆင့်နိမ့်၊ မစ်ရှင်အရေးပါသော ဝန်ဆောင်မှုများကို သော့နံပါတ်အချို့တွင် ကွန်တိန်နာများ တိုက်ရိုက်အသုံးပြုခြင်းဖြင့် အသုံးချခဲ့သည်။ ဤကိစ္စတွင်၊ စံပလက်ဖောင်းဝန်ဆောင်မှုများကို အသုံးမပြုပါ - လင့်ခ်ပေးသူ၊ အချိန်ဇယားဆွဲသူနှင့် အပြေးသမား။ ခေတ်မီကွန်တိန်နာပလပ်ဖောင်းများနှင့် နှိုင်းယှဉ်လိုပါက၊ ၎င်းသည် ထိန်းချုပ်မှုလေယာဉ်ဖြင့် လည်ပတ်နေသကဲ့သို့ဖြစ်သည်။ docker run အလုပ်တာဝန်ကို Kubernetes သို့လွှဲအပ်မည့်အစား node များပေါ်တွင် တိုက်ရိုက်။ သဘောတရားနဲ့ တော်တော်တူတယ်။ static modules (pods)၎င်းကိုအသုံးပြုသည်။ kubeadm သို့မဟုတ် bootkube standalone cluster ကို စတင်သောအခါ။

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

တစ်ဖက်တွင်၊ Zookeeper ကဲ့သို့သော ပြင်ပသော့/တန်ဖိုးစတိုးဆိုင်၏ ပံ့ပိုးကူညီမှု မလိုအပ်သောကြောင့် ၎င်းသည် အလွန်ယုံကြည်စိတ်ချရပါသည်။ အခြားတစ်ဖက်တွင်မူ ဝန်ဆောင်မှုများ ပြောင်းရွှေ့ရန် အခက်အခဲရှိသည်။ ရွှေ့လိုက်တိုင်း၊ သုံးစွဲသူများအားလုံးသည် အပ်ဒိတ်လုပ်ထားသော YAML ဖိုင်ကို ရရှိလိမ့်မည် (နှင့် ပြန်လည်စတင်နိုင်သည်)။ သိပ်အဆင်မပြေဘူး!

နောက်ပိုင်းတွင်၊ client တစ်ခုစီသည် local proxy server သို့ ချိတ်ဆက်ထားသည့် အစီအစဉ်အသစ်တစ်ခုကို စတင်အကောင်အထည်ဖော်ခဲ့သည်။ လိပ်စာနှင့် ပို့တ်အစား ဝန်ဆောင်မှု၏ ပို့တ်နံပါတ်ကို သိရန်နှင့် ချိတ်ဆက်ရန်သာ လိုအပ်သည်။ localhost. ဒေသတွင်း proxy သည် ဤချိတ်ဆက်မှုကို ကိုင်တွယ်ပြီး တကယ့်ဆာဗာသို့ ပေးပို့သည်။ ယခု၊ နောက်ကွယ်ကို အခြားစက်တစ်ခုသို့ ရွှေ့ခြင်း သို့မဟုတ် ချဲ့ထွင်သည့်အခါ၊ ကလိုင်းယင့်အားလုံးကို မွမ်းမံခြင်းအစား၊ သင်သည် ဤဒေသခံ ပရောက်စီများအားလုံးကို အပ်ဒိတ်လုပ်ရန်သာ လိုအပ်ပါသည်။ နှင့် reboot လုပ်ရန်မလိုအပ်တော့ပါ။

(၎င်းသည် TLS ချိတ်ဆက်မှုများတွင် အသွားအလာကို ကန့်သတ်ရန် စီစဉ်ထားပြီး လက်ခံသည့်ဘက်တွင် အခြားသော ပရောက်စီဆာဗာကို ထားရှိကာ လက်ခံခြင်းဝန်ဆောင်မှုတွင်သာ ပါဝင်ခြင်းမရှိဘဲ TLS လက်မှတ်များကို စစ်ဆေးအတည်ပြုရန် စီစဉ်ထားသည်၊၊ localhost. ဤအကြောင်းကို နောက်မှ ဆက်ပြောပါ။)

ဒါက အရမ်းတူတယ်။ SmartStack Airbnb မှ၊ သို့သော် သိသာထင်ရှားသော ကွာခြားချက်မှာ SmartStack ကို ထုတ်လုပ်မှုတွင် အသုံးချပြီး dotCloud ၏အတွင်းပိုင်းလမ်းကြောင်းတင်စနစ်အား dotCloud မှ Docker ဖြစ်လာချိန်တွင် ဖယ်ထားလိုက်ခြင်းဖြစ်သည်။

SmartStack သည် Istio၊ Linkerd နှင့် Consul Connect ကဲ့သို့သော စနစ်များ၏ ရှေ့လာနောက်ဆက်တွဲများထဲမှ တစ်ခုဖြစ်သည်ဟု ကျွန်ုပ်ကိုယ်တိုင်ကိုယ်ကျယူဆပါသည်။

• node တစ်ခုစီတွင် proxy ကိုဖွင့်ပါ။
• ဖောက်သည်များသည် ပရောက်စီသို့ ချိတ်ဆက်သည်။
• နောက်ခံများ ပြောင်းလဲသောအခါ ထိန်းချုပ်မှုလေယာဉ်သည် ပရောက်စီဖွဲ့စည်းပုံကို အပ်ဒိတ်လုပ်သည်။
• ... အမြတ်အစွန်း!

ခေတ်မီဝန်ဆောင်မှုကွက်တစ်ခု အကောင်အထည်ဖော်ခြင်း။

ယနေ့ ကျွန်ုပ်တို့သည် အလားတူဇယားကွက်တစ်ခုကို အကောင်အထည်ဖေါ်ရန် လိုအပ်ပါက၊ အလားတူမူများကို ကျွန်ုပ်တို့အသုံးပြုနိုင်ပါသည်။ ဥပမာအားဖြင့်၊ နေရာလွတ်များရှိ လိပ်စာများသို့ ဝန်ဆောင်မှုအမည်များကို မြေပုံဆွဲခြင်းဖြင့် အတွင်း DNS ဇုန်ကို ပြင်ဆင်သတ်မှတ်ပါ။ 127.0.0.0/8. ထို့နောက် အစုအဝေးရှိ node တစ်ခုစီတွင် HAProxy ကိုဖွင့်ပြီး ဝန်ဆောင်မှုလိပ်စာတစ်ခုစီတွင် ချိတ်ဆက်မှုများကို လက်ခံခြင်း (ထိုကွန်ရက်ခွဲအတွင်းရှိ 127.0.0.0/8) နှင့် သင့်လျော်သော နောက်ကွယ်မှ ဝန်ကို ပြန်ညွှန်းခြင်း/ဟန်ချက်ညီခြင်း။ HAProxy ဖွဲ့စည်းမှုပုံစံကို ထိန်းချုပ်နိုင်သည်။ confdနောက်ခံအချက်အလက်ကို etcd သို့မဟုတ် Consul တွင် သိမ်းဆည်းထားနိုင်ပြီး လိုအပ်သောအခါတွင် မွမ်းမံထားသောဖွဲ့စည်းပုံကို HAProxy သို့ အလိုအလျောက် တွန်းပို့ပေးသည်။

ဒါက Istio အလုပ်လုပ်ပုံပါပဲ။ ဒါပေမယ့် ကွဲပြားမှုတွေနဲ့

• အသုံးများသည်။ အထူးကိုယ်စားလှယ် ပရောက်စီ HAProxy အစား
• etcd သို့မဟုတ် Consul အစား Kubernetes API မှတစ်ဆင့် backend configuration ကို သိမ်းဆည်းသည်။
• ဝန်ဆောင်မှုများသည် 127.0.0.0/8 အစား အတွင်းပိုင်းကွန်ရက်ခွဲများ (Kubernetes ClusterIP လိပ်စာများ) တွင် ခွဲဝေပေးထားသည့် လိပ်စာများဖြစ်သည်။
• ကလိုင်းယင့်နှင့်ဆာဗာများအကြား အပြန်အလှန် TLS စစ်မှန်ကြောင်းအထောက်အထားထည့်သွင်းရန် နောက်ထပ်အစိတ်အပိုင်းတစ်ခု (Citadel) ရှိသည်။
• circuit breaking၊ distribution tracing၊ canary deployment အစရှိသည့် အင်္ဂါရပ်အသစ်များကို ပံ့ပိုးပေးပါသည်။

ကွာခြားချက်အချို့ကို အမြန်ကြည့်ကြပါစို့။

အထူးကိုယ်စားလှယ် ပရောက်စီ

Envoy Proxy ကို Lyft [တက္ကစီစျေးကွက်တွင် Uber ၏ပြိုင်ဘက် - ခန့်မှန်းခြေအားဖြင့်ရေးသားခဲ့သည်။ လမ်းသွား]။ အခြား proxy များ (ဥပမာ HAProxy၊ Nginx၊ Traefik...) နှင့် များစွာ ဆင်တူသော်လည်း Lyft သည် အခြား proxy များ ချို့တဲ့သော အင်္ဂါရပ်များ လိုအပ်သောကြောင့် ၎င်းတို့ကို ရေးသားခဲ့ပြီး ရှိပြီးသားတစ်ခုအား တိုးချဲ့ခြင်းထက် အသစ်တစ်ခုပြုလုပ်ရန် ပိုစမတ်ကျပုံရသည်။

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

ဒါပေမယ့် Envoy မှာလည်း အလုပ် လုပ်နိုင်စွမ်းရှိပါတယ်။ ဒေတာလေယာဉ် ဝန်ဆောင်မှုကွက်အတွက် (ဒေတာလေယာဉ်)။ ဆိုလိုသည်မှာ Envoy သည် ဤဝန်ဆောင်မှု mesh အတွက် ယခု ပြင်ဆင်သတ်မှတ်ထားပါသည်။ လေယာဉ်ထိန်းချုပ်မှု (လေယာဉ်ထိန်း)။

လေယာဉ်ထိန်း

ထိန်းချုပ်ရေးလေယာဉ်အတွက်၊ Istio သည် Kubernetes API ကို အားကိုးသည်။ ဒါက confd သုံးတာနဲ့ သိပ်မကွာခြားပါဘူး။ဒေတာစတိုးရှိ သော့အစုံကို ကြည့်ရှုရန် etcd သို့မဟုတ် ကောင်စစ်ဝန်အပေါ် မှီခိုနေရပါသည်။ Istio သည် Kubernetes အရင်းအမြစ်များကို ကြည့်ရှုရန် Kubernetes API ကို အသုံးပြုသည်။

ဒီကြားထဲ: ဒီအသုံးဝင်တာကို ကျွန်တော် ကိုယ်တိုင်ကိုယ်ကျ တွေ့ရှိခဲ့ပါတယ်။ Kubernetes API ဖော်ပြချက်ဟူသည်မှာ-

Kubernetes API ဆာဗာသည် API အရင်းအမြစ်များအတွက် သိုလှောင်မှု၊ ဗားရှင်းထုတ်လုပ်ခြင်း၊ တရားဝင်ခြင်း၊ မွမ်းမံခြင်းနှင့် အဓိပ္ပါယ်သတ်မှတ်ချက်များကို ပေးဆောင်သည့် "မိုက်မဲသောဆာဗာ" ဖြစ်သည်။

Istio သည် Kubernetes နှင့် အလုပ်လုပ်ရန် ဒီဇိုင်းထုတ်ထားသည်။ ၎င်းကို Kubernetes ပြင်ပတွင် သင်အသုံးပြုလိုပါက Kubernetes API ဆာဗာ (နှင့် etcd helper ဝန်ဆောင်မှု) ၏ ဥပမာတစ်ခုကို သင်လုပ်ဆောင်ရန် လိုအပ်ပါသည်။

ဝန်ဆောင်မှုလိပ်စာများ

Istio သည် Kubernetes ခွဲဝေပေးသည့် ClusterIP လိပ်စာများကို မှီခိုနေရသောကြောင့် Istio ဝန်ဆောင်မှုများသည် အတွင်းလိပ်စာကို လက်ခံရရှိသည် (အကွာအဝေးအတွင်းမဟုတ်ပါ 127.0.0.0/8).

Istio မပါဘဲ Kubernetes အစုအဝေးရှိ သတ်မှတ်ထားသော ဝန်ဆောင်မှုတစ်ခုအတွက် ClusterIP လိပ်စာသို့ လမ်းကြောင်းအသွားအလာကို kube-proxy မှ ကြားဖြတ်ပြီး ထိုပရောက်စီ၏ နောက်ခံသို့ ပေးပို့သည်။ နည်းပညာဆိုင်ရာအသေးစိတ်အချက်အလက်များကို သင်စိတ်ဝင်စားပါက၊ Kube-proxy သည် iptables စည်းမျဉ်းများ (သို့မဟုတ် IPVS တွင် ထည့်သွင်းထားသည့်ပုံစံပေါ်မူတည်၍) ချိန်ခွင်လျှာကို ClusterIP လိပ်စာသို့သွားမည့် ချိတ်ဆက်မှုများ၏ ဦးတည်ရာ IP လိပ်စာများကို ပြန်လည်ရေးရန် သတ်မှတ်ပေးပါသည်။

Istio ကို Kubernetes အစုအဝေးတွင် ထည့်သွင်းပြီးသည်နှင့်၊ ကွန်တိန်နာကို မိတ်ဆက်ပေးခြင်းဖြင့် သုံးစွဲသူတစ်ဦးအတွက် သို့မဟုတ် namespace တစ်ခုလုံးကို တိကျပြတ်သားစွာ ဖွင့်မထားသည့်တိုင်အောင် ၎င်းကို မည်သည့်အရာမှ ပြောင်းလဲမည်မဟုတ်ပေ။ sidecar စိတ်ကြိုက် pods များထဲသို့။ ဤကွန်တိန်နာသည် Envoy ၏ စံနမူနာကို လှည့်ပတ်ပြီး အခြားဝန်ဆောင်မှုများသို့ သွားနေသော အသွားအလာကို ကြားဖြတ်ကာ ထိုလမ်းကြောင်းအား Envoy သို့ ပြန်ညွှန်းရန် iptables စည်းမျဉ်းများ အစုံလိုက်ကို တည်ဆောက်ပါမည်။

Kubernetes DNS နှင့် ပေါင်းစည်းလိုက်သောအခါ၊ ဆိုလိုသည်မှာ ကျွန်ုပ်တို့၏ကုဒ်သည် ဝန်ဆောင်မှုအမည်ဖြင့် ချိတ်ဆက်နိုင်ပြီး အရာအားလုံးသည် “အဆင်ပြေသည်” ဟု ဆိုလိုပါသည်။ တစ်နည်းဆိုရသော် ကျွန်ုပ်တို့၏ ကုဒ်သည် ကဲ့သို့သော မေးခွန်းများကို ထုတ်ပေးပါသည်။ http://api/v1/users/4242ထို့နောက် api တောင်းဆိုမှုကိုဖြေရှင်းပါ။ 10.97.105.48iptables စည်းမျဉ်းများသည် 10.97.105.48 မှ ချိတ်ဆက်မှုများကို ကြားဖြတ်ပြီး ၎င်းတို့အား ဒေသတွင်း Envoy proxy သို့ ပေးပို့မည်ဖြစ်ပြီး၊ ထိုဒေသခံ proxy သည် တောင်းဆိုချက်ကို အမှန်တကယ် backend API သို့ ပေးပို့မည်ဖြစ်သည်။ ဝူး!

အပိုအလိုဆန္ဒများ

Istio သည် mTLS (mutual TLS) မှတစ်ဆင့် အဆုံးမှအဆုံးထိ ကုဒ်ဝှက်ခြင်းနှင့် စစ်မှန်ကြောင်းအထောက်အထားပြခြင်းကို ပေးပါသည်။ အစိတ်အပိုင်းဟုခေါ်သည်။ Citadel.

အစိတ်အပိုင်းတစ်ခုလည်း ရှိပါသည်။ ရောစပ်ရာEnvoy က တောင်းဆိုနိုင်တယ်။ တစ်ခုချင်းစီကို ခေါင်းစီးများ၊ backend load စသည်ဖြင့် အမျိုးမျိုးသောအချက်များပေါ်မူတည်၍ အဆိုပါတောင်းဆိုမှုနှင့်ပတ်သက်ပြီး အထူးဆုံးဖြတ်ချက်တစ်ခုချရန် တောင်းဆိုပါ (စိတ်မပူပါနှင့်- Mixer လည်ပတ်နေစေရန် နည်းလမ်းများစွာရှိပါသည်၊ ပျက်သွားလျှင်ပင် Envoy သည် ဆက်လက်အလုပ်လုပ်နေမည်ဖြစ်ပါသည်။ proxy အဖြစ် ဒဏ်ငွေဆောင်ပါ။)

ထို့အပြင်၊ ကျွန်ုပ်တို့သည် မြင်နိုင်စွမ်းကို ဖော်ပြခဲ့သည်- Envoy သည် ဖြန့်ဝေခြေရာခံခြင်းကို ပံ့ပိုးပေးစဉ်တွင် မက်ထရစ်ပမာဏများစွာကို စုဆောင်းပါသည်။ microservices ဗိသုကာတစ်ခုတွင်၊ API တောင်းဆိုချက်တစ်ခုသည် microservices A၊ B၊ C၊ D မှတဆင့်ဖြတ်သန်းရပါက၊ ဝင်ရောက်သည့်အခါတွင်၊ ဖြန့်ဝေထားသောခြေရာခံခြင်းသည် တောင်းဆိုချက်တွင် ထူးခြားသော identifier ကို ပေါင်းထည့်မည်ဖြစ်ပြီး ဤ microservices များအားလုံးထံ တောင်းဆိုချက်ခွဲများမှတစ်ဆင့် ဤ identifier ကို သိမ်းဆည်းသွားမည်ဖြစ်ပါသည်။ ဆက်စပ်ခေါ်ဆိုမှုများအားလုံးကို ဖမ်းယူရန်။ နှောင့်နှေးမှုများ၊ စသည်တို့။

ဖွံ့ဖြိုးတိုးတက်ရန် သို့မဟုတ် ဝယ်ယူပါ။

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

အကယ်၍ ကျွန်ုပ်တို့တွင် ကျိုးနွံသော လိုအပ်ချက်များ (ကျွန်ုပ်တို့သည် မြင်နိုင်စွမ်း၊ circuit breaker နှင့် အခြားသော ပရိယာယ်များ မလိုအပ်ပါ) ဆိုလျှင် ကျွန်ုပ်တို့၏ ကိုယ်ပိုင် tool ကို တီထွင်ရန် အတွေးများ ပေါ်လာပါသည်။ သို့သော် Kubernetes ကိုအသုံးပြုပါက Kubernetes သည် ဝန်ဆောင်မှုရှာဖွေတွေ့ရှိမှုနှင့် load ချိန်ခွင်လျှာအတွက် အခြေခံကိရိယာများကို ပေးဆောင်ထားပြီးဖြစ်သောကြောင့် ၎င်းသည် မလိုအပ်တော့ပေ။

သို့သော် ကျွန်ုပ်တို့တွင် အဆင့်မြင့်လိုအပ်ချက်များရှိပါက ဝန်ဆောင်မှုကွက်တစ်ခု "ဝယ်ယူခြင်း" သည် များစွာပိုမိုကောင်းမွန်သောရွေးချယ်မှုဖြစ်ပုံရသည်။ ( Istio သည် open source ဖြစ်သောကြောင့် အမြဲတမ်း "ဝယ်သည်" မဟုတ်ပါ၊ သို့သော် ၎င်းကို နားလည်ရန်၊ အသုံးချရန်နှင့် စီမံခန့်ခွဲရန် အင်ဂျင်နီယာဆိုင်ရာ အချိန်ကို ရင်းနှီးမြှပ်နှံရန် လိုအပ်နေသေးသည်။)

Istio၊ Linkerd သို့မဟုတ် Consul Connect ကို ရွေးချယ်သင့်ပါသလား။

ယခုအချိန်အထိ ကျွန်ုပ်တို့သည် Istio အကြောင်းကိုသာ ပြောခဲ့ပြီးဖြစ်သော်လည်း ၎င်းသည် တစ်ခုတည်းသော ဝန်ဆောင်မှုကွက်မဟုတ်ပေ။ လူကြိုက်များသော အခြားရွေးချယ်စရာ - Linkerd, နှင့် ပို ကောင်စစ်ဝန်ချိတ်ဆက်ပါ။.

အဘယ်အရာကိုရွေးချယ်ဖို့?

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

အလားအလာရှိသော ချဉ်းကပ်နည်းတစ်ခုမှာ ကိရိယာကဲ့သို့သော ကိရိယာကို အသုံးပြုခြင်းဖြစ်သည်။ SuperGloo. ၎င်းသည် ဝန်ဆောင်မှု meshes ဖြင့် ထိတွေ့ထားသော API များကို ရိုးရှင်းစေပြီး ပေါင်းစည်းရန် abstraction အလွှာကို အကောင်အထည်ဖော်သည်။ မတူညီသော ဝန်ဆောင်မှု meshes များ၏ သီးခြား (ကျနော့်အမြင်အရတော့ အတော်လေး ရှုပ်ထွေး) API များကို လေ့လာခြင်းအစား SuperGloo ၏ ပိုမိုရိုးရှင်းသော တည်ဆောက်မှုများကို အသုံးပြုနိုင်ပြီး HTTP interfaces နှင့် backends များကို ဖော်ပြနိုင်သော intermediate configuration format တစ်ခုရှိသကဲ့သို့ တစ်ခုမှတစ်ခုသို့ လွယ်ကူစွာပြောင်းနိုင်သည်။ Nginx, HAProxy, Traefik, Apache... အတွက် အမှန်တကယ် configuration ကို ဖန်တီးခြင်း

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

source: www.habr.com