Pinterest တွင် kubernetes ပလပ်ဖောင်းတစ်ခုဖန်တီးခြင်း။

နှစ်များတစ်လျှောက် Pinterest ၏အသုံးပြုသူ သန်း 300 သည် ဘုတ်ပေါင်း 200 ဘီလီယံကျော်တွင် pin 4 ဘီလီယံကျော်ဖန်တီးခဲ့သည်။ ဤအသုံးပြုသူများ၏စစ်တပ်နှင့် ကျယ်ပြန့်သောအကြောင်းအရာအခြေခံကို ဝန်ဆောင်မှုပေးရန်၊ ပေါ်တယ်သည် CPU အနည်းငယ်မှကိုင်တွယ်နိုင်သော microservices မှသည် virtual machines တစ်ခုလုံးပေါ်တွင်လည်ပတ်နိုင်သော ဧရာမ monolith များအထိ ဝန်ဆောင်မှုထောင်ပေါင်းများစွာကို တီထွင်ခဲ့သည်။ ပြီးတော့ ကုမ္ပဏီရဲ့ မျက်လုံးတွေက k8s ကို စိုက်ကြည့်တဲ့ အချိန်ရောက်လာတယ်။ Pinterest တွင် "cube" သည်အဘယ်ကြောင့်ကြည့်ကောင်းသနည်း။ ဤအကြောင်းကို ကျွန်ုပ်တို့၏ မကြာသေးမီက ဘာသာပြန်ထားသော ဆောင်းပါးမှ ဤအကြောင်းကို သင်လေ့လာရလိမ့်မည်။ ဘလော့ဂ် Pinterest တီထွင်ဖန်တီးခြင်း။.

ဒါကြောင့် သုံးစွဲသူ သန်းရာနဲ့ချီပြီး ပင်နံပါတ် ဘီလီယံရာနဲ့ချီပါတယ်။ ဤအသုံးပြုသူများ၏စစ်တပ်နှင့် ကျယ်ပြန့်သောအကြောင်းအရာအခြေခံကို ထမ်းဆောင်ရန်အတွက် ကျွန်ုပ်တို့သည် CPU အနည်းငယ်မှကိုင်တွယ်နိုင်သော microservices မှသည် virtual machines တစ်ခုလုံးတွင်လည်ပတ်နေသော ဧရာမ monolith များအထိ ဝန်ဆောင်မှုထောင်ပေါင်းများစွာကို တီထွင်ခဲ့ပါသည်။ ထို့အပြင်၊ ကျွန်ုပ်တို့တွင် CPU၊ Memory သို့မဟုတ် I/O အသုံးပြုခွင့်တို့လည်း လိုအပ်နိုင်သည့် ဘောင်အမျိုးမျိုးရှိသည်။

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

• အင်ဂျင်နီယာများသည် ထုတ်လုပ်မှုပတ်ဝန်းကျင်ကို လုပ်ဆောင်ရန် တူညီသောနည်းလမ်းမရှိပါ။ နိုင်ငံမဲ့ဝန်ဆောင်မှုများ၊ နိုင်ငံပိုင်ဝန်ဆောင်မှုများနှင့် တက်ကြွစွာဖွံ့ဖြိုးတိုးတက်မှုအောက်တွင် ပရောဂျက်များသည် လုံးဝကွဲပြားခြားနားသော နည်းပညာအစုအဝေးများအပေါ် အခြေခံထားသည်။ ယင်းကြောင့် အင်ဂျင်နီယာများအတွက် လေ့ကျင့်ရေးသင်တန်းတစ်ခုလုံးကို ဖန်တီးပေးခဲ့ပြီး ကျွန်ုပ်တို့၏ အခြေခံအဆောက်အဦအဖွဲ့၏ လုပ်ငန်းကိုလည်း ပြင်းထန်စွာ ရှုပ်ထွေးစေသည်။
• ကိုယ်ပိုင် virtual machine များရှိသော developer များသည် အတွင်းပိုင်းစီမံခန့်ခွဲသူများအပေါ် ကြီးမားသောဝန်ထုပ်ဝန်ပိုးဖြစ်စေသည်။ ရလဒ်အနေဖြင့် OS သို့မဟုတ် AMI ကို အဆင့်မြှင့်တင်ခြင်းကဲ့သို့သော ရိုးရှင်းသောလုပ်ဆောင်ချက်များသည် ရက်သတ္တပတ်နှင့်လများကြာသည်။ ၎င်းသည် လုံးဝနေ့စဥ်အခြေအနေများတွင် အလုပ်တာဝန်များ တိုးလာစေသည်။
• လက်ရှိဖြေရှင်းချက်များ၏ထိပ်တွင် ကမ္ဘာလုံးဆိုင်ရာ အခြေခံအဆောက်အအုံစီမံခန့်ခွဲမှုကိရိယာများ ဖန်တီးရာတွင် ခက်ခဲမှုများ။ virtual machines များ၏ပိုင်ရှင်များကိုရှာဖွေရန်မလွယ်ကူသောအချက်ကြောင့်အခြေအနေသည်ပိုမိုရှုပ်ထွေးသည်။ ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့၏ အခြေခံအဆောက်အဦ၏ အခြားအစိတ်အပိုင်းများတွင် ဤစွမ်းရည်ကို ဘေးကင်းစွာ ထုတ်ယူနိုင်သည်ဆိုသည်ကို ကျွန်ုပ်တို့ မသိပါ။

Container orchestration systems သည် workload management ကို ပေါင်းစည်းရန် နည်းလမ်းတစ်ခုဖြစ်သည်။ ပရောဂျက်တွင် ပါဝင်သော အရင်းအမြစ်အားလုံးကို ဗဟိုချုပ်ကိုင်မှုစနစ်တစ်ခုဖြင့် စီမံခန့်ခွဲသောကြောင့် ၎င်းတို့သည် ဖွံ့ဖြိုးတိုးတက်မှု အရှိန်တိုးမြှင့်ရန်နှင့် အခြေခံအဆောက်အအုံစီမံခန့်ခွဲမှုကို ရိုးရှင်းစေရန် တံခါးဖွင့်ပေးထားသည်။

ပုံ 1- အခြေခံအဆောက်အအုံဆိုင်ရာ ဦးစားပေးများ (ယုံကြည်စိတ်ချရမှု၊ တီထွင်သူ၏ ကုန်ထုတ်စွမ်းအားနှင့် စွမ်းဆောင်ရည်)။

Pinterest ရှိ Cloud Management Platform အဖွဲ့သည် K8s ကို 2017 ခုနှစ်တွင် ရှာဖွေတွေ့ရှိခဲ့သည်။ 2017 ခုနှစ် ပထမနှစ်ဝက်တွင် API နှင့် ကျွန်ုပ်တို့၏ဝဘ်ဆာဗာများအပါအဝင် ကျွန်ုပ်တို့၏ထုတ်လုပ်မှုစွမ်းရည်အများစုကို မှတ်တမ်းတင်ခဲ့ပါသည်။ ထို့နောက်၊ ကျွန်ုပ်တို့သည် ကွန်တိန်နာဖြေရှင်းချက်များအား ကြိုးကိုင်ခြင်း၊ အစုအဝေးများတည်ဆောက်ခြင်းနှင့် ၎င်းတို့နှင့်လုပ်ဆောင်ခြင်းအတွက် အမျိုးမျိုးသောစနစ်များကို စေ့စေ့စပ်စပ်အကဲဖြတ်ခြင်းပြုလုပ်ခဲ့ပါသည်။ 2017 နှစ်ကုန်ခါနီးတွင် Kubernetes ကို အသုံးပြုရန် ဆုံးဖြတ်ခဲ့သည်။ ၎င်းသည် ဆော့ဖ်ဝဲရေးသားသူ အသိုင်းအဝိုင်းတွင် အတော်လေး လိုက်လျောညီထွေရှိပြီး ကျယ်ပြန့်စွာ ပံ့ပိုးပေးခဲ့ပါသည်။

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

Kubernetes- Pinterest နည်းလမ်း

ကျွန်ုပ်တို့၏အင်ဂျင်နီယာများနှစ်သက်မည့် ပလပ်ဖောင်းတစ်ခုအနေဖြင့် Pinterest ၏အတိုင်းအတာတွင် Kubernetes နှင့် စတင်ခြင်းမှာ စိန်ခေါ်မှုများစွာဖြင့် ရောက်ရှိလာပါသည်။

ကုမ္ပဏီကြီးတစ်ခုအနေဖြင့် ကျွန်ုပ်တို့သည် အခြေခံအဆောက်အအုံဆိုင်ရာကိရိယာများတွင် ကြီးကြီးမားမားရင်းနှီးမြှုပ်နှံထားသည်။ ဥပမာများတွင် လက်မှတ်များနှင့် သော့ခွဲဝေခြင်းကို ကိုင်တွယ်သည့် လုံခြုံရေးကိရိယာများ၊ ယာဉ်ကြောအသွားအလာ ထိန်းချုပ်မှု အစိတ်အပိုင်းများ၊ ဝန်ဆောင်မှု ရှာဖွေတွေ့ရှိမှုစနစ်များ၊ မြင်နိုင်မှု အစိတ်အပိုင်းများနှင့် မှတ်တမ်းနှင့် မက်ထရစ်များ ပေးပို့သည့် အစိတ်အပိုင်းများ ပါဝင်သည်။ ဤအရာအားလုံးကို အကြောင်းပြချက်တစ်ခုဖြင့် စုဆောင်းထားသည်- ကျွန်ုပ်တို့သည် အစမ်းသုံးခြင်းနှင့် အမှားအယွင်း၏ ပုံမှန်လမ်းကြောင်းကို ဖြတ်သန်းခဲ့ရသောကြောင့် ကျွန်ုပ်တို့သည် ဤစက်ပစ္စည်းအားလုံးကို ပလပ်ဖောင်းအသစ်တွင် ဘီးဟောင်းကို ပြန်လည်တီထွင်မည့်အစား Kubernetes ရှိ အခြေခံအဆောက်အအုံအသစ်တွင် ဤစက်ပစ္စည်းအားလုံးကို ပေါင်းစပ်လိုပါသည်။ အပလီကေးရှင်း ပံ့ပိုးမှုအားလုံး ရှိနှင့်ပြီးဖြစ်ပြီး အစမှ ဖန်တီးရန် မလိုအပ်သောကြောင့် ဤချဉ်းကပ်မှုသည် အလုံးစုံ ရွှေ့ပြောင်းခြင်းကို ရိုးရှင်းစေသည်။

အခြားတစ်ဖက်တွင်၊ Kubernetes ကိုယ်တိုင် (အသုံးပြုမှု၊ အလုပ်များနှင့် Daemon အစုံများကဲ့သို့) ရှိ ဝန်ခန့်မှန်းချက်မော်ဒယ်များသည် ကျွန်ုပ်တို့၏ပရောဂျက်အတွက် မလုံလောက်ပါ။ ဤအသုံးပြုမှုပြဿနာများသည် Kubernetes သို့ပြောင်းရန် ကြီးမားသောအတားအဆီးများဖြစ်သည်။ ဥပမာအားဖြင့်၊ ပျောက်ဆုံးနေသော သို့မဟုတ် မှားယွင်းသော လော့ဂ်အင်ဆက်တင်များအကြောင်း ဝန်ဆောင်မှု developer များက တိုင်ကြားသည်ကို ကျွန်ုပ်တို့ကြားပါသည်။ တူညီသောသတ်မှတ်ချက်နှင့် လုပ်ငန်းဆောင်တာများဖြင့် ကော်ပီရာနှင့်ချီသော ပုံစံခွက်အင်ဂျင်များကို မှားယွင်းစွာအသုံးပြုခြင်းကိုလည်း ကြုံတွေ့ခဲ့ရပြီး အိပ်မက်ဆိုး အမှားရှာပြင်ခြင်း ပြဿနာများကို ဖြစ်ပေါ်စေခဲ့သည်။

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

Pinterest User Properties နှင့် Controllers

ကျွန်ုပ်တို့၏ အင်ဂျင်နီယာများအတွက် Kubernetes ကို အကောင်အထည်ဖော်ရန် ပိုမိုလွယ်ကူစေရန်နှင့် ကျွန်ုပ်တို့၏ အခြေခံအဆောက်အဦများကို ရိုးရှင်းပြီး မြန်ဆန်စေရန်အတွက်၊ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ ကိုယ်ပိုင်အရင်းအမြစ် အဓိပ္ပါယ်သတ်မှတ်ချက်များ (CRDs) ကို တီထွင်ထားပါသည်။

CRD များသည် အောက်ပါလုပ်ဆောင်ချက်များကို ပံ့ပိုးပေးသည်-

1. မတူညီသော မူရင်း Kubernetes အရင်းအမြစ်များကို ပေါင်းစပ်ခြင်းဖြင့် ၎င်းတို့သည် အလုပ်တစ်ခုတည်းအဖြစ် လုပ်ဆောင်နိုင်မည်ဖြစ်သည်။ ဥပမာအားဖြင့်၊ PinterestService အရင်းအမြစ်တွင် ဖြန့်ကျက်ခြင်း၊ အကောင့်ဝင်ခြင်းဝန်ဆောင်မှုနှင့် ဖွဲ့စည်းမှုမြေပုံတစ်ခု ပါဝင်သည်။ ၎င်းသည် ဆော့ဖ်ဝဲအင်ဂျင်နီယာများအား DNS စနစ်ထည့်သွင်းခြင်းအတွက် စိတ်ပူစရာမလိုပါ။
2. လိုအပ်သောလျှောက်လွှာပံ့ပိုးမှုအကောင်အထည်ဖော်ပါ။ CRD controller သည် လိုအပ်သော init containers၊ ပတ်ဝန်းကျင် variable များနှင့် pod specifications အားလုံးကို အကောင်အထည်ဖေါ်နေချိန်တွင် အသုံးပြုသူသည် ၎င်းတို့၏ business logic အရ container specification ပေါ်တွင်သာ အာရုံစိုက်ရန်လိုအပ်ပါသည်။ ၎င်းသည် ဆော့ဖ်ဝဲအင်ဂျင်နီယာများအတွက် အခြေခံအားဖြင့် ကွဲပြားသော နှစ်သိမ့်မှုအဆင့်ကို ပေးဆောင်သည်။
3. CRD ထိန်းချုပ်ကိရိယာများသည် မူလရင်းမြစ်များ၏ ဘဝသံသရာကို စီမံခန့်ခွဲပြီး အမှားရှာပြင်ဆင်နိုင်မှုကို တိုးတက်စေသည်။ ၎င်းတွင် လိုချင်သောနှင့် အမှန်တကယ် သတ်မှတ်ချက်များကို ပြန်လည်ညှိနှိုင်းခြင်း၊ CRD အခြေအနေကို အပ်ဒိတ်လုပ်ခြင်းနှင့် ဖြစ်ရပ်မှတ်တမ်းများကို ထိန်းသိမ်းခြင်းနှင့် အခြားအရာများ ပါဝင်သည်။ CRD မရှိလျှင် developer များသည် error ဖြစ်နိုင်ခြေကို တိုးမြင့်စေမည့် အရင်းအမြစ်များစွာကို စီမံခန့်ခွဲရန် အတင်းအကြပ် ခိုင်းစေမည်ဖြစ်သည်။

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

အထက်တွင်တွေ့မြင်ရသည့်အတိုင်း၊ စိတ်ကြိုက်ကွန်တိန်နာကို ပံ့ပိုးရန်အတွက် လုံခြုံရေး၊ မြင်နိုင်စွမ်းနှင့် ကွန်ရက်အသွားအလာများကို ပံ့ပိုးပေးရန်အတွက် ကျွန်ုပ်တို့သည် init container နှင့် add-ons များစွာကို ပေါင်းစပ်ရန် လိုအပ်ပါသည်။ ထို့အပြင်၊ ကျွန်ုပ်တို့သည် ဖွဲ့စည်းမှုမြေပုံပုံစံများကို ဖန်တီးပြီး အတွဲလိုက်အလုပ်များအတွက် PVC နမူနာပုံစံများကို ပံ့ပိုးပေးသည့်အပြင် အထောက်အထား၊ အရင်းအမြစ်သုံးစွဲမှုနှင့် အမှိုက်စုဆောင်းမှုတို့ကို ခြေရာခံရန်အတွက် ပတ်ဝန်းကျင်ပြောင်းလဲမှုများစွာကို ခြေရာခံခြင်း။

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

အပလီကေးရှင်း ဖြန့်ကျက်လုပ်ဆောင်မှု

အထက်ပါပုံသည် Pinterest စိတ်ကြိုက်အရင်းအမြစ်ကို Kubernetes အစုအဝေးသို့ မည်သို့အသုံးပြုရမည်ကို ပြသသည်-

1. Developer များသည် CLI နှင့် user interface မှတဆင့် ကျွန်ုပ်တို့၏ Kubernetes အစုအဝေးနှင့် အပြန်အလှန် တုံ့ပြန်ကြသည်။
2. CLI/UI ကိရိယာများသည် အလုပ်အသွားအလာဖွဲ့စည်းပုံ YAML ဖိုင်များနှင့် အခြားတည်ဆောက်မှုဂုဏ်သတ္တိများ (တူညီသောဗားရှင်း ID) ကို Artifactory မှ ရယူပြီးနောက် ၎င်းတို့အား အလုပ်တင်ပြခြင်းဝန်ဆောင်မှုသို့ ပေးပို့ပါ။ ဤအဆင့်သည် ထုတ်လုပ်မှုဗားရှင်းများကိုသာ အစုအဝေးသို့ ပို့ဆောင်ကြောင်း သေချာစေပါသည်။
3. JSS သည် Kubernetes အပါအဝင် ပလပ်ဖောင်းအမျိုးမျိုးအတွက် တံခါးပေါက်တစ်ခုဖြစ်သည်။ ဤနေရာတွင် အသုံးပြုသူအား စစ်မှန်ကြောင်းအထောက်အထားပြပြီး ခွဲတမ်းများကိုထုတ်ပေးပြီး ကျွန်ုပ်တို့၏ CRD ၏ဖွဲ့စည်းပုံအား တစ်စိတ်တစ်ပိုင်းစစ်ဆေးထားသည်။
4. JSS ဘက်မှ CRD ကို စစ်ဆေးပြီးနောက် အချက်အလက်များကို k8s ပလပ်ဖောင်း API သို့ ပေးပို့သည်။
5. ကျွန်ုပ်တို့၏ CRD ထိန်းချုပ်သူသည် အသုံးပြုသူအရင်းအမြစ်များအားလုံးရှိ အဖြစ်အပျက်များကို စောင့်ကြည့်ပါသည်။ ၎င်းသည် CR များကို မူရင်း k8s အရင်းအမြစ်များအဖြစ်သို့ ပြောင်းပေးသည်၊ လိုအပ်သော module များကို ပေါင်းထည့်ကာ၊ သင့်လျော်သော ပတ်၀န်းကျင် ကိန်းရှင်များကို သတ်မှတ်ပေးပြီး containerized user applications များတွင် လုံလောက်သော အခြေခံအဆောက်အဦ ပံ့ပိုးမှုရှိကြောင်း သေချာစေရန်အတွက် အခြားသော ပံ့ပိုးမှုလုပ်ငန်းများကို လုပ်ဆောင်ပါသည်။
6. ထို့နောက် CRD ထိန်းချုပ်သူသည် လက်ခံရရှိသည့်ဒေတာကို Kubernetes API သို့ ပေးပို့ကာ ၎င်းအား အချိန်ဇယားရေးဆွဲသူမှ စီမံဆောင်ရွက်ပေးပြီး ထုတ်လုပ်မှုတွင် ထည့်သွင်းနိုင်မည်ဖြစ်သည်။

ပွောဆို: k8s ပလပ်ဖောင်းအသစ်၏ ပထမဆုံးအသုံးပြုသူများအတွက် ဤဖြန့်ကျက်မှု၏ အကြိုထုတ်ဝေမှုဆိုင်ရာ အလုပ်စီးဆင်းမှုကို ဖန်တီးထားသည်။ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ CI/CD အသစ်နှင့် အပြည့်အ၀ပေါင်းစပ်ရန် ဤလုပ်ငန်းစဉ်ကို လောလောဆယ်တွင် ပြန်လည်သန့်စင်ရန် လုပ်ဆောင်နေပါသည်။ ဆိုလိုသည်မှာ Kubernetes နှင့် ပတ်သက်သည့် အရာအားလုံးကို သင့်အား ပြောပြနိုင်မည်မဟုတ်ပေ။ ကျွန်ုပ်တို့၏နောက်ထပ်ဘလော့ဂ်ပို့စ်တွင် “Pinterest အတွက် CI/CD ပလပ်ဖောင်းတစ်ခုတည်ဆောက်ခြင်း” တွင် ကျွန်ုပ်တို့၏အတွေ့အကြုံနှင့် အသင်း၏တိုးတက်မှုများကို မျှဝေရန် မျှော်လင့်ပါသည်။

အထူးအရင်းအမြစ်အမျိုးအစားများ

Pinterest ၏ သီးခြားလိုအပ်ချက်များအပေါ် အခြေခံ၍ မတူညီသောအလုပ်အသွားအလာများနှင့်ကိုက်ညီစေရန် အောက်ပါ CRDs များကို တီထွင်ထားပါသည်။

• PinterestService သည် ကာလကြာရှည်စွာလည်ပတ်နေသည့် နိုင်ငံမဲ့ဝန်ဆောင်မှုများဖြစ်သည်။ ကျွန်ုပ်တို့၏ ပင်မစနစ်များစွာသည် ထိုကဲ့သို့သော ဝန်ဆောင်မှုများပေါ်တွင် အခြေခံထားသည်။
• PinterestJobSet မော်ဒယ်များ လည်ပတ်မှု အစုလိုက် အလုပ်များ။ Pinterest ပေါ်ရှိ ဘုံအခြေအနေတစ်ခုသည် အခြားအလားတူလုပ်ငန်းစဉ်များမပါဝင်ဘဲ အလုပ်များစွာသည် တူညီသောကွန်တိန်နာများကို အပြိုင်လုပ်ဆောင်ခြင်းပင်ဖြစ်သည်။
• PinterestCronJob ကို အချိန်အပိုင်းအခြားအလိုက် သေးငယ်သော load များနှင့်အတူ တွင်ကျယ်စွာ အသုံးပြုပါသည်။ ၎င်းသည် လုံခြုံရေး၊ အသွားအလာ၊ မှတ်တမ်းများနှင့် မက်ထရစ်များအတွက် တာဝန်ရှိသော Pinterest ပံ့ပိုးမှုယန္တရားများဖြင့် မူရင်း cron အလုပ်အတွက် ထုပ်ပိုးမှုတစ်ခုဖြစ်သည်။
• PinterestDaemon တွင် အခြေခံအဆောက်အဦ Daemons ပါဝင်သည်။ ကျွန်ုပ်တို့၏ အစုအဖွဲ့များသို့ ပံ့ပိုးကူညီမှုများ ပိုမိုထည့်သွင်းပေးခြင်းဖြင့် ဤမိသားစုသည် ဆက်လက်ကြီးထွားလာပါသည်။
• PinterestTrainingJob သည် Tensorflow နှင့် Pytorg လုပ်ငန်းစဉ်များသို့ တိုးချဲ့ပြီး အခြား CRD များအားလုံးကဲ့သို့ runtime ပံ့ပိုးမှု အဆင့်ကို ပေးဆောင်ပါသည်။ Pinterest သည် Tensorflow နှင့် အခြားသော စက်သင်ယူမှုစနစ်များကို တက်ကြွစွာအသုံးပြုသောကြောင့်၊ ၎င်းတို့အနီးတစ်ဝိုက်တွင် သီးခြား CRD တစ်ခုကို တည်ဆောက်ရန် အကြောင်းပြချက်ရှိသည်။

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

Runtime ပံ့ပိုးမှု

အပလီကေးရှင်း pod တစ်ခုသည် Kubernetes တွင် အလုပ်လုပ်သောအခါ၊ ၎င်းသည် သူ့ကိုယ်သူ ခွဲခြားသတ်မှတ်ရန် လက်မှတ်ကို အလိုအလျောက် ရရှိသည်။ ဤလက်မှတ်ကို လျှို့ဝှက်သိုလှောင်မှုသို့ ဝင်ရောက်ရန် သို့မဟုတ် mTLS မှတစ်ဆင့် အခြားဝန်ဆောင်မှုများနှင့် ဆက်သွယ်ရန်အတွက် အသုံးပြုပါသည်။ ဤအတောအတွင်း၊ Container Init Configurator နှင့် Daemon သည် containerized application ကိုမလည်ပတ်မီ လိုအပ်သော မှီခိုမှုအားလုံးကို ဒေါင်းလုဒ်လုပ်မည်ဖြစ်သည်။ အရာအားလုံးအဆင်သင့်ဖြစ်သောအခါ၊ ယာဉ်အသွားအလာဆိုက်ကားနှင့် Daemon သည် မော်ဂျူး၏ IP လိပ်စာကို ကျွန်ုပ်တို့၏ Zookeeper တွင် စာရင်းသွင်းပေးမည်ဖြစ်ပြီး သုံးစွဲသူများက ၎င်းကိုရှာဖွေတွေ့ရှိနိုင်မည်ဖြစ်သည်။ အပလီကေးရှင်းမစတင်မီတွင် ကွန်ရက် module ကို configure လုပ်ထားသောကြောင့် ၎င်းအားလုံးသည် အလုပ်ဖြစ်ပါမည်။

အထက်ဖော်ပြပါများသည် workloads အတွက် runtime support ၏ ပုံမှန်ဥပမာများဖြစ်သည်။ အခြားအလုပ်ချိန်အမျိုးအစားများသည် အနည်းငယ်ကွဲပြားသောပံ့ပိုးမှုလိုအပ်နိုင်သော်လည်း ၎င်းတို့အားလုံးကို pod-level sidecars၊ node-level သို့မဟုတ် virtual machine-level Daemons ပုံစံဖြင့်လာပါသည်။ ဤအရာအားလုံးကို စီမံခန့်ခွဲမှုအခြေခံအဆောက်အအုံအတွင်း အသုံးချပြီး အသုံးချပလီကေးရှင်းများတစ်လျှောက် တသမတ်တည်းဖြစ်ကြောင်း သေချာစေကာ၊ နည်းပညာဆိုင်ရာအလုပ်နှင့် ဖောက်သည်ပံ့ပိုးမှုဆိုင်ရာ ဝန်ထုပ်ဝန်ပိုးကို အဆုံးစွန်ထိ လျှော့ချပေးပါသည်။

စမ်းသပ်ခြင်းနှင့် QA

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

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

အခြားနည်းလမ်း

mutation access controllers နှင့် template systems ကဲ့သို့သော စိတ်ကြိုက်အရင်းအမြစ်များအတွက် အခြားရွေးချယ်စရာများကို ကျွန်ုပ်တို့ ကြည့်ရှုခဲ့ပါသည်။ သို့သော်လည်း ၎င်းတို့အားလုံးတွင် သိသာထင်ရှားသော လုပ်ငန်းဆောင်ရွက်မှုဆိုင်ရာ စိန်ခေါ်မှုများနှင့် လာသောကြောင့် ကျွန်ုပ်တို့ CRD လမ်းကြောင်းကို ရွေးချယ်ခဲ့သည်။

ဆိုက်ကားများ၊ ပတ်၀န်းကျင်ပြောင်းလွဲမှုများနှင့် အခြား runtime ပံ့ပိုးမှုတို့ကို မိတ်ဆက်ရန်အတွက် ပြောင်းလဲမှုဆိုင်ရာ ဝင်ခွင့်ထိန်းချုပ်ကိရိယာကို အသုံးပြုခဲ့သည်။ သို့သော်၊ CRD တွင် ထိုသို့သောပြဿနာများ မပေါ်ပေါက်သည့် အရင်းအမြစ် ချိတ်ဆက်မှုနှင့် ဘဝလည်ပတ်မှု စီမံခန့်ခွဲမှုကဲ့သို့သော ပြဿနာများစွာကို ရင်ဆိုင်နေရသည်။

မှတ်ချက်: Helm charts ကဲ့သို့သော နမူနာပုံစံစနစ်များကို အလားတူဖွဲ့စည်းပုံများဖြင့် အပလီကေးရှင်းများလည်ပတ်ရန်အတွက် တွင်ကျယ်စွာအသုံးပြုပါသည်။ သို့သော်၊ ကျွန်ုပ်တို့၏ အလုပ်လျှောက်လွှာများသည် ပုံစံပလိတ်များကို အသုံးပြု၍ စီမံခန့်ခွဲရန် ကွဲပြားလွန်းပါသည်။ စဉ်ဆက်မပြတ် ဖြန့်ကျက်စဉ်အတွင်း တင်းပလိတ်များကို အသုံးပြုသည့်အခါတွင်လည်း အမှားအယွင်းများစွာ ရှိလိမ့်မည်။

လုပ်ရမယ့်အလုပ်

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

• အစုအဝေးများ၏ အစုအဝေးသည် အတိုင်းအတာနှင့် တည်ငြိမ်မှုအတွက် မတူညီသော အစုအဝေးများတစ်လျှောက် ကြီးမားသော အပလီကေးရှင်းများကို ဖြန့်ဝေသည်။
• အပလီကေးရှင်းချိတ်ဆက်မှုနှင့် SLA များကိုဖန်တီးရန် အစုအဖွဲ့တည်ငြိမ်မှု၊ အတိုင်းအတာနှင့် မြင်နိုင်စွမ်းကို သေချာစေခြင်း။
• အရင်းအမြစ်များနှင့် ခွဲတမ်းများကို စီမံခန့်ခွဲခြင်းဖြင့် အပလီကေးရှင်းများ တစ်ခုနှင့်တစ်ခု မကွဲလွဲစေရန်၊ အစုအဖွဲ့၏ အတိုင်းအတာကို ကျွန်ုပ်တို့ဘက်မှ ထိန်းချုပ်ထားသည်။
• Kubernetes တွင် အပလီကေးရှင်းများ ပံ့ပိုးခြင်းနှင့် အသုံးပြုခြင်းအတွက် CI/CD ပလပ်ဖောင်းအသစ်။

source: www.habr.com