Kubernetes တွင် အသုံးချနည်းဗျူဟာများ- လှိမ့်ခြင်း၊ ပြန်ဖန်တီးခြင်း၊ အပြာ/အစိမ်း၊ ကိန္နရီ၊ အမှောင် (A/B စမ်းသပ်ခြင်း)

မှတ်ချက် ဘာသာပြန်- Weaveworks မှ ဤခြုံငုံသုံးသပ်ချက်သည် ရေပန်းအစားဆုံး အပလီကေးရှင်း ဖြန့်ချိရေးဗျူဟာများကို မိတ်ဆက်ပေးပြီး Kubernetes Flagger အော်ပရေတာကို အသုံးပြု၍ အဆင့်မြင့်ဆုံးများကို မည်သို့အကောင်အထည်ဖော်နိုင်ကြောင်း ပြသသည်။ ၎င်းကို ရိုးရှင်းသောဘာသာစကားဖြင့် ရေးသားထားပြီး ပြဿနာကို အတွေ့အကြုံမရှိသေးသော အင်ဂျင်နီယာများပင်လျှင် နားလည်နိုင်စေမည့် ရုပ်ပုံကားချပ်များပါရှိသည်။

အခုမှ ယူထားတာ နောက်ထပ်သုံးသပ်ချက် Container Solutions တွင် ပြုလုပ်ထားသော မဟာဗျူဟာများကို အကောင်အထည်ဖော်ပါ။

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

ပိုတို၍ မကြာခဏ ဖြန့်ကျက်ခြင်းသည် အောက်ပါ အကျိုးကျေးဇူးများ ရှိသည်။

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

သို့သော် ထုတ်ဝေမှုအကြိမ်ရေ တိုးလာသည်နှင့်အမျှ အပလီကေးရှင်း၏ ယုံကြည်စိတ်ချရမှု သို့မဟုတ် အသုံးပြုသူအတွေ့အကြုံကို ထိခိုက်စေနိုင်သည့် အခွင့်အလမ်းများလည်း တိုးလာပါသည်။ ထို့ကြောင့် လုပ်ဆောင်ချက်များနှင့် DevOps အဖွဲ့များသည် ထုတ်ကုန်နှင့် သုံးစွဲသူများအတွက် အန္တရာယ်အနည်းဆုံးဖြစ်စေသော နည်းလမ်းဖြင့် လုပ်ငန်းစဉ်များတည်ဆောက်ကာ အသုံးချမှုဗျူဟာများကို စီမံခန့်ခွဲရန် အရေးကြီးပါသည်။ (CI/CD ပိုက်လိုင်း အလိုအလျောက်စနစ်အကြောင်း ပိုမိုလေ့လာနိုင်ပါသည်။ ဒီမှာ.)

ဤပို့စ်တွင်၊ ဖြန့်ကျက်ချထားမှုများနှင့် Canary ဖြန့်ချိမှုများနှင့် ၎င်းတို့၏ ကွဲပြားမှုများကဲ့သို့သော ပိုမိုအဆင့်မြင့်သည့်နည်းလမ်းများအပါအဝင် Kubernetes တွင် ဖြန့်ကျက်မှုဗျူဟာအမျိုးမျိုးကို ဆွေးနွေးပါမည်။

ဖြန့်ကျက်နည်းဗျူဟာများ

သင့်ရည်မှန်းချက်ပေါ် မူတည်၍ သင်အသုံးပြုနိုင်သည့် အသုံးချမှုဗျူဟာ အမျိုးအစားများစွာ ရှိပါသည်။ ဥပမာအားဖြင့်၊ သင်သည် နောက်ထပ်စမ်းသပ်မှုများအတွက် အချို့သောပတ်ဝန်းကျင်တွင် အပြောင်းအလဲများပြုလုပ်ရန် လိုအပ်နိုင်သည်၊ သို့မဟုတ် အသုံးပြုသူ/ဖောက်သည်များ၏ အစုအဝေးသို့ ပြောင်းလဲရန် လိုအပ်နိုင်သည်၊ သို့မဟုတ် အင်္ဂါရပ်တစ်ခုမလုပ်ဆောင်မီတွင် သင်သည် အကန့်အသတ်ရှိသော အသုံးပြုသူစမ်းသပ်မှုကို ပြုလုပ်ရန် လိုအပ်နိုင်သည်။ အများသူငှာ.

Rolling (တဖြည်းဖြည်း၊ "လှိမ့်" ဖြန့်ကျက်မှု)

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

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

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: awesomeapp
    spec:
      containers:
        - name: awesomeapp
          image: imagerepo-user/awesomeapp:new
          ports:
            - containerPort: 8080

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

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
       maxSurge: 25%
       maxUnavailable: 25%  
  template:
  ...

ပြန်လည်ဖန်တီးပါ။

ဤအရိုးရှင်းဆုံး အသုံးချမှု အမျိုးအစားတွင် အစေ့ဟောင်းများကို တစ်ပြိုင်နက်သတ်ပြီး အသစ်များဖြင့် အစားထိုးသည်-

ဆက်စပ်ဖော်ပြချက်သည် ဤကဲ့သို့ ဖြစ်သည်-

spec:
  replicas: 3
  strategy:
    type: Recreate
  template:
  ...

အပြာ/အစိမ်း (အပြာ-အစိမ်း ဖြန့်ကျက်မှုများ)

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

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: awesomeapp-02
spec:
  template:
    metadata:
      labels:
        app: awesomeapp
        version: "02"

အပြာ (အသစ်) ဗားရှင်းကို စမ်းသပ်ပြီး ၎င်း၏ ထုတ်ဝေမှုကို အတည်ပြုပြီးနောက်၊ ဝန်ဆောင်မှုသည် ၎င်းသို့ ပြောင်းသွားပြီး အစိမ်းရောင် (အဟောင်း) ဗားရှင်းကို ခေါက်လိုက်သည်-

apiVersion: v1
kind: Service
metadata:
  name: awesomeapp
spec:
  selector:
    app: awesomeapp
    version: "02"
...

Canary (ကိန္နရီတပ်များ)

Canary ဖြန့်ချိမှုများသည် စိမ်းပြာရောင် ဖြန့်ချိမှုများနှင့် ဆင်တူသော်လည်း ပိုမိုကောင်းမွန်သော ထိန်းချုပ်မှုနှင့် အသုံးပြုမှုရှိသည်။ တိုးတက်သော တဆင့်ပြီးတဆင့် ချဉ်းကပ်ပါတယ်။ ဤအမျိုးအစားတွင် "ကိုယ်ပျောက်" လွှတ်တင်ခြင်း နှင့် A/B စမ်းသပ်ခြင်း အပါအဝင် မတူညီသော နည်းဗျူဟာများစွာ ပါဝင်သည်။

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

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

ဥပမာအားဖြင့်၊ သင့်တွင် Git တွင် မတူညီသော manifest နှစ်ခုရှိနိုင်သည်- tag 0.1.0 ဖြင့် ပုံမှန် manifest နှင့် tag 0.2.0 ရှိသော canary manifest တို့ဖြစ်သည်။ Istio virtual gateway manifest တွင် အလေးချိန်များကို ပြောင်းလဲခြင်းဖြင့်၊ သင်သည် အဆိုပါ ဖြန့်ကျက်မှုနှစ်ခုကြား လမ်းကြောင်းခွဲဝေမှုကို ထိန်းချုပ်နိုင်သည်-

Istio ကို အသုံးပြု၍ Canary ဖြန့်ကျက်မှုများကို အကောင်အထည်ဖော်ရန် အဆင့်ဆင့်လမ်းညွှန်ချက်ကို ကြည့်ပါ။ Istio ဖြင့် GitOps အလုပ်အသွားအလာများ. (မှတ်ချက်။ ဘာသာပြန်: ကျွန်ုပ်တို့သည် Canary ဖြန့်ချိမှုများအကြောင်း အကြောင်းအရာများကို Istio သို့ ဘာသာပြန်ပါသည်။ ဒီမှာ.)

Weaveworks Flagger ဖြင့် Canary ဖြန့်ကျက်မှုများ

Weaveworks Flagger Canary rollouts များကို အလွယ်တကူနှင့် ထိထိရောက်ရောက် စီမံခန့်ခွဲနိုင်စေပါသည်။

Flagger များသည် ၎င်းတို့နှင့် အလုပ်လုပ်ပါသည်။ ၎င်းသည် အသွားအလာလမ်းကြောင်းပြောင်းရန် Istio သို့မဟုတ် AWS App Mesh ကိုအသုံးပြုကာ ရလဒ်များကိုခွဲခြမ်းစိတ်ဖြာရန် Prometheus မက်ထရစ်များကို အသုံးပြုသည်။ ထို့အပြင်၊ Canary ဖြန့်ကျက်မှုများကို ခွဲခြမ်းစိတ်ဖြာခြင်းဖြင့် လက်ခံမှုစစ်ဆေးမှုများ၊ load tests နှင့် အခြားစစ်ဆေးမှုအမျိုးအစားများကိုလုပ်ဆောင်ရန် webhooks များဖြင့် ဖြည့်စွက်နိုင်ပါသည်။

Kubernetes ဖြန့်ကျက်မှုအပေါ် အခြေခံ၍ လိုအပ်ပါက၊ အလျားလိုက် အလျားလိုက် အတိုင်းအတာ (HPA)၊ Flagger သည် အရာဝတ္ထုအစုံများ (Kubernetes ဖြန့်ကျက်မှု၊ ClusterIP ဝန်ဆောင်မှုများနှင့် Istio သို့မဟုတ် App Mesh virtual ဝန်ဆောင်မှုများ) ကို ခွဲခြမ်းစိတ်ဖြာပြီး အကောင်အထည်ဖော်ရန်-

ထိန်းချုပ်မှုကွင်းကို အကောင်အထည်ဖော်ခြင်း။ (ထိန်းချုပ်မှုကွင်းဆက်)၊Flagger သည် အောင်မြင်သော HTTP တောင်းဆိုမှုရာခိုင်နှုန်း၊ ပျမ်းမျှတောင်းဆိုမှုကြာချိန်နှင့် pod ကျန်းမာရေးစသည့် အဓိက စွမ်းဆောင်ရည်မက်ထရစ်များကို တစ်ပြိုင်နက် တိုင်းတာနေချိန်တွင် ၊Flagger သည် အသွားအလာကို Canary ဆာဗာသို့ တဖြည်းဖြည်းပြောင်းပေးပါသည်။ KPI (Key Performance Indicators) ခွဲခြမ်းစိတ်ဖြာမှုအပေါ် အခြေခံ၍ Canary သည် ကြီးထွားသည် သို့မဟုတ် ပြိုကျပြီး ခွဲခြမ်းစိတ်ဖြာမှုရလဒ်များကို Slack တွင် ထုတ်ပြန်ထားသည်။ ဤလုပ်ငန်းစဉ်၏ ဖော်ပြချက်နှင့် သရုပ်ပြချက်ကို အကြောင်းအရာတွင် တွေ့နိုင်ပါသည်။ App Mesh အတွက် တိုးတက်သော ပို့ဆောင်မှု.

အမှောင် (ဝှက်ထားသည်) သို့မဟုတ် A/B ဖြန့်ကျက်မှုများ

Stealth deployment သည် Canary ဗျူဟာ၏ အခြားသော ကွဲပြားမှုဖြစ်သည် (ထို့အတူ Flagger နှင့်လည်း လုပ်ဆောင်နိုင်သည်)။ ကိုယ်ပျောက် နှင့် ကိန္နရီ ဖြန့်ကျက်မှု အကြား ခြားနားချက်မှာ ကိန္နရီ ဖြန့်ကျက်မှုများကဲ့သို့ နောက်ကွယ်မှ မဟုတ်ဘဲ ကိုယ်ပျောက် ဖြန့်ကျက်မှုများသည် ရှေ့တန်းနှင့် ဆက်ဆံခြင်း ဖြစ်သည်။

ဤဖြန့်ကျက်မှုအတွက် အခြားအမည်မှာ A/B စမ်းသပ်ခြင်း ဖြစ်သည်။ အသုံးပြုသူအားလုံးအတွက် ဝန်ဆောင်မှုအသစ်ကို ရရှိစေမည့်အစား ၎င်းတို့ထဲမှ အကန့်အသတ်ရှိသော အစိတ်အပိုင်းကိုသာ ကမ်းလှမ်းထားသည်။ ပုံမှန်အားဖြင့်၊ ဤအသုံးပြုသူများသည် ၎င်းတို့သည် ရှေ့ဆောင်စမ်းသပ်သူများဖြစ်ကြောင်း (ထို့ကြောင့် "ကိုယ်ပျောက်အသုံးပြုမှု" ဟူသောအသုံးအနှုန်း)။

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

Flagger နှင့် A/B ဖြန့်ကျက်မှုများ

အလေးချိန်အခြေခံလမ်းကြောင်းသတ်မှတ်ခြင်းအပြင်၊ Flagger သည် HTTP ဘောင်များကိုအခြေခံ၍ Canary ဆာဗာသို့ လမ်းကြောင်းပြောင်းနိုင်သည်။ A/B စမ်းသပ်မှုတွင်၊ သင်သည် သုံးစွဲသူများ၏ အစိတ်အပိုင်းတစ်ခုကို ပစ်မှတ်ထားရန် HTTP ခေါင်းစီးများ သို့မဟုတ် ကွက်ကီးများကို အသုံးပြုနိုင်သည်။ ဆာဗာသို့ session binding လိုအပ်သော frontend applications များတွင် အထူးသဖြင့် ၎င်းသည် ထိရောက်သည်။ (ဆက်ရှင်ဆက်စပ်မှု). နောက်ထပ်အချက်အလက်များကို Flagger documentation တွင် တွေ့နိုင်ပါသည်။

စာရေးသူက ကျေးဇူးတင်ကြောင်း ဖော်ပြပါတယ်။ Stefan Prodanဤအံ့သြဖွယ်ကောင်းသော အသုံးချမှုပုံစံများအားလုံးအတွက် Weaveworks အင်ဂျင်နီယာ (နှင့် Flagger ဖန်တီးသူ)။

PS ဘာသာပြန်မှ

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

• «Kubernetes အတွက် Ingress ထိန်းချုပ်ကိရိယာများ၏ ခြုံငုံသုံးသပ်ချက်နှင့် နှိုင်းယှဉ်ချက်";
• «werf - Kubernetes ရှိ CI/CD အတွက် ကျွန်ုပ်တို့၏ကိရိယာ (ခြုံငုံသုံးသပ်ချက်နှင့် ဗီဒီယိုအစီရင်ခံစာ)";
• «werf နှင့် GitLab CI ဖြင့် အမျိုးအစားတူ microservices များကို တည်ဆောက်ပြီး အသုံးချပါ။";
• «GitOps ဆိုတာဘာလဲ။"။

source: www.habr.com