Kubernetes #2 တွင် Canary ဖြန့်ကျက်မှု- Argo ဖြန့်ချိမှုများ

Kubernetes တွင် Canary ဖြန့်ကျက်မှုများကို လုပ်ဆောင်ရန် k8s-native Argo Rollouts ဖြန့်ကျက်ထိန်းချုပ်ကိရိယာနှင့် GitlabCI ကို အသုံးပြုပါမည်။

https://unsplash.com/photos/V41PulGL1z0

ဤစီးရီးရှိ ဆောင်းပါးများ

• Kubernetes #1 တွင် Canary ဖြန့်ကျက်မှု- Gitlab CI
• (ဤဆောင်ပါး)
• Istio ကို အသုံးပြု၍ Canary Deployment
• Jenkins-X Istio Flagger ကို အသုံးပြု၍ Canary ဖြန့်ကျက်ခြင်း။

Canary ဖြန့်ကျက်

သင်ဖတ်ဖို့မျှော်လင့်ပါတယ်။ ပထမပိုင်းCanary Deployments က ဘာလဲဆိုတာ အတိုချုံးရှင်းပြထားတဲ့နေရာပါ။ စံ Kubernetes အရင်းအမြစ်များကို အသုံးပြု၍ ၎င်းကို အကောင်အထည်ဖော်ပုံကိုလည်း ပြသထားသည်။

Argo Rollouts

Argo Rollouts သည် Kubernetes မူလအသုံးပြုမှု ထိန်းချုပ်ကိရိယာတစ်ခုဖြစ်သည်။ ၎င်းသည် Kubernetes အတွက် CRD (Custom Resource Definition) ကို ပံ့ပိုးပေးပါသည်။ ၎င်းကိုကျေးဇူးတင်ပါသည်၊ ကျွန်ုပ်တို့သည် အကြောင်းအရာအသစ်ကို အသုံးပြုနိုင်ပါသည်။ Rolloutဖွဲ့စည်းမှုရွေးချယ်စရာအမျိုးမျိုးဖြင့် စိမ်းပြာရောင်နှင့် ကိန္နရီဖြန့်ကျက်မှုများကို စီမံပေးသည်။

စိတ်ကြိုက်အရင်းအမြစ်တစ်ခုမှအသုံးပြုသော Argo Rollouts ထိန်းချုပ်ကိရိယာ Rollout, Kubernetes အတွက် စိမ်းပြာရောင် နှင့် ကိန္နရီ ကဲ့သို့သော နောက်ထပ် ဖြန့်ကျက်မှု ဗျူဟာများအတွက် ခွင့်ပြုပါ။ အရင်းအမြစ် Rollout တူညီသောလုပ်ဆောင်နိုင်စွမ်းကိုပေးသည်။ Deploymentထပ်လောင်းဖြန့်ကျက်မှုဗျူဟာများဖြင့်သာ၊
သယံဇာတ Deployments ဖြန့်ကျက်ခြင်းအတွက် ဗျူဟာနှစ်ခုရှိသည်။ RollingUpdate и Recreate. ဤနည်းဗျူဟာများသည် ကိစ္စအများစုအတွက် သင့်လျော်သော်လည်း၊ အလွန်ကြီးမားသောအတိုင်းအတာဖြင့် ဆာဗာများသို့ ဖြန့်ကျက်အသုံးပြုရန်အတွက် Deployment controller တွင်မရရှိနိုင်သော အစိမ်းရောင်အပြာ သို့မဟုတ် Canary ကဲ့သို့သော အပိုမဟာဗျူဟာများကို အသုံးပြုပါသည်။ Kubernetes တွင် ဤနည်းဗျူဟာများကို အသုံးပြုရန်၊ အသုံးပြုသူများသည် ၎င်းတို့၏ Deployments ၏ထိပ်တွင် scripts များရေးသားရပါမည်။ Argo Rollouts Controller သည် ဤဗျူဟာများကို ရိုးရှင်းသော၊ ကြေငြာနိုင်သော၊ ပြင်ဆင်နိုင်သော ဘောင်များအဖြစ် ထုတ်ဖော်သည်။
https://argoproj.github.io/argo-rollouts

Rollouts နှင့်အသုံးပြုရန်အတွက်အဆင်ပြေသောဝဘ်အင်တာဖေ့စ်ကိုပံ့ပိုးပေးသော Argo CI လည်းရှိပါသည်၊ နောက်ဆောင်းပါးတွင်၎င်းကိုကြည့်ရှုပါမည်။

Argo Rollouts ကို ထည့်သွင်းခြင်း။

Server ဘက်မှာ

kubectl create namespace argo-rolloutskubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml

ကျွန်ုပ်တို့၏ အခြေခံအဆောက်အဦ ဟင်းနုနွယ်တွင် (အောက်တွင်ကြည့်ပါ) ကျွန်ုပ်တို့သည် i/k8s/argo-rollouts/install.yaml အဖြစ် install.yaml ကို ထည့်သွင်းပြီးဖြစ်သည်။ ဤနည်းဖြင့် GitlabCI သည် ၎င်းကို အစုအဝေးတွင် ထည့်သွင်းမည်ဖြစ်သည်။

ဖောက်သည်ဘက် (kubectl ပလပ်အင်)

https://argoproj.github.io/argo-rollouts/features/kubectl-plugin

နမူနာလျှောက်လွှာ

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

လျှောက်လွှာအတွက်သိုလှောင်မှု

Kim Wuestkamp/k8s-deployment-example-app

၎င်းသည် JSON အဖြစ် တုံ့ပြန်မှုကို ပြန်ပေးသည့် အလွန်ရိုးရှင်းသော Python+Flask API ဖြစ်သည်။ ကျွန်ုပ်တို့သည် GitlabCI ကို အသုံးပြု၍ အထုပ်ကိုတည်ဆောက်ပြီး ရလဒ်ကို Gitlab Registry သို့ တွန်းပို့ပါမည်။ မှတ်ပုံတင်ခြင်းတွင် ကျွန်ုပ်တို့တွင် မတူညီသော ဗားရှင်းနှစ်မျိုးရှိသည်။

• wuestkamp/k8s-deployment-example-app:v1
• wuestkamp/k8s-deployment-example-app:v2

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

အခြေခံအဆောက်အအုံ သိုလှောင်ရုံ

ဤသိုလှောင်ခန်းတွင် Kubernetes တွင် ဖြန့်ကျက်ရန်အတွက် GitlabCI ကိုအသုံးပြုမည်ဖြစ်ပြီး၊ .gitlab-ci.yml သည် ဤကဲ့သို့ဖြစ်သည်-

image: traherom/kustomize-dockerbefore_script:
   - printenv
   - kubectl versionstages:
 - deploydeploy test:
   stage: deploy
   before_script:
     - echo $KUBECONFIG
   script:
     - kubectl get all
     - kubectl apply -f i/k8s    only:
     - master

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

gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b
gcloud compute firewall-rules create incoming-80 --allow tcp:80

လမ်းခွဲရန် လိုအပ်သည်။ https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure variable တစ်ခုဖန်တီးပါ။ KUBECONFIG GitlabCI တွင် access အတွက် config ပါရှိသည်။ kubectl သင်၏အစုအဝေးသို့

ဒါဟာဖြစ်ပါတယ် အစုအဖွဲ့ (Gcloud) အတွက် အထောက်အထားများ မည်သို့ရယူရမည်ကို သင်ဖတ်နိုင်သည်။

အခြေခံအဆောက်အဦ Yaml

အခြေခံအဆောက်အဦ သိုလှောင်ရုံအတွင်းတွင် ကျွန်ုပ်တို့ ဝန်ဆောင်မှု ရှိသည်-

apiVersion: v1
kind: Service
metadata:
 labels:
   id: rollout-canary
 name: app
spec:
 ports:
 - port: 80
   protocol: TCP
   targetPort: 5000
 selector:
   id: app
 type: LoadBalancer

နှင့် rollout.yaml :

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
 replicas: 10
 revisionHistoryLimit: 2
 selector:
   matchLabels:
     id: rollout-canary
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       imagePullPolicy: Always
 strategy:
   canary:
     steps:
     - setWeight: 10
     # Rollouts can be manually resumed by running `kubectl argo rollouts promote ROLLOUT`
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # two minutes

Rollout Deployment နဲ့အတူတူအလုပ်လုပ်ပါတယ်။ ကျွန်ုပ်တို့သည် အပ်ဒိတ်ဗျူဟာကို မသတ်မှတ်ထားပါက (ဤနေရာတွင် ကိန္နရီကဲ့သို့) ၎င်းသည် ပုံသေ လှုံ့ဆော်မှု-မွမ်းမံမှု ဖြန့်ကျက်မှုကဲ့သို့ ပြုမူလိမ့်မည်။

Canary ဖြန့်ကျက်ခြင်းအတွက် yaml တွင် အဆင့်နှစ်ဆင့်သတ်မှတ်ထားပါသည်။

1. ကိန္နရီသို့ သွားလာမှု၏ 10% (လူကိုယ်တိုင် အိုကေကို စောင့်ပါ)
2. ကိန္နရီသို့ လမ်းကြောင်း 50% (2 မိနစ်စောင့်ပြီးနောက် 100%) သို့ ဆက်သွားပါ

ကနဦး ဖြန့်ကျက်မှုကို လုပ်ဆောင်ခြင်း။

ကနဦး ဖြန့်ကျက်ပြီးနောက်၊ ကျွန်ုပ်တို့၏ အရင်းအမြစ်များသည် ဤကဲ့သို့ ဖြစ်နေပါမည်-

ကျွန်ုပ်တို့သည် အပလီကေးရှင်း၏ ပထမဗားရှင်းမှသာလျှင် တုံ့ပြန်မှုကို ရရှိသည်-

Canary Deployment လုပ်ဆောင်ခြင်း။

အဆင့် 1: 10% လမ်းကြောင်း

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

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
...
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
...

ပြီးတော့ အပြောင်းအလဲတွေကို တွန်းအားပေးတဲ့အတွက် Gitlab CI က အသုံးချပြီး အပြောင်းအလဲတွေကို တွေ့ရတယ်-

ယခု ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုကို ဝင်ရောက်ပါက၊

မိုက်တယ်! ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ကိန္နရီဖြန့်ကျက်မှုအလယ်တွင် ရှိနေပါသည်။ လည်ပတ်ခြင်းဖြင့် တိုးတက်မှုကို ကျွန်ုပ်တို့ မြင်နိုင်သည်-

kubectl argo rollouts get rollout rollout-canary

အဆင့် 2- လမ်းကြောင်း 50%

ယခု နောက်တစ်ဆင့်သို့ ဆက်သွားကြပါစို့- ယာဉ်ကြောအသွားအလာ၏ 50% ကို ပြန်ညွှန်းပါ။ ဤအဆင့်ကို ကိုယ်တိုင်လုပ်ဆောင်ရန် ကျွန်ုပ်တို့ စီစဉ်သတ်မှတ်ထားသည်-

kubectl argo rollouts promote rollout-canary # continue to step 2

ကျွန်ုပ်တို့၏အပလီကေးရှင်းသည် ဗားရှင်းအသစ်များမှ တုံ့ပြန်မှု 50% ကို ပြန်ပေးသည်-

နှင့် ထုတ်ဝေမှု ပြန်လည်သုံးသပ်ခြင်း-

Прекрасно

အဆင့် 3- လမ်းကြောင်း 100%

2 မိနစ်အကြာတွင် 50% ခြေလှမ်းသည် အလိုအလျောက်အဆုံးသတ်ပြီး 100% ခြေလှမ်းစတင်ရန် ကျွန်ုပ်တို့ ၎င်းကိုသတ်မှတ်လိုက်ပါသည်။

နှင့် application output

နှင့် ထုတ်ဝေမှု ပြန်လည်သုံးသပ်ခြင်း-

Canary ဖြန့်ကျက်မှု ပြီးပါပြီ။

Argo Rollouts နှင့်အတူ နောက်ထပ်ဥပမာများ

ကိန္နရီကိုအခြေခံ၍ ပတ်ဝန်းကျင်အကြိုကြည့်ရှုမှုများနှင့် နှိုင်းယှဉ်ချက်များကို သတ်မှတ်ပုံကဲ့သို့သော ဤနေရာတွင် နောက်ထပ်ဥပမာများရှိပါသည်။

https://github.com/argoproj/argo-rollouts/tree/master/examples

Argo Rollouts နှင့် Argo CI အကြောင်း ဗီဒီယို

ဤဗီဒီယိုကို ကျွန်ုပ်တကယ်အကြံပြုလိုပါသည်၊ ၎င်းသည် Argo Rollouts နှင့် Argo CI မည်ကဲ့သို့ အတူတကွ လုပ်ဆောင်သည်ကို ပြသသည်-

ရလဒ်

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

သို့သော်၊ Argo CI နှင့် Flux CI တို့၏ ကြီးမားသော ပေါင်းစပ်မှုတစ်ခု ရောက်ရှိလာပုံပေါ်သည်၊ ထို့ကြောင့် အသစ်ထွက်ရှိလာသည့်အချိန်အထိ ကျွန်ုပ်စောင့်နိုင်ပါသည်။ Argo Flux.

Argo Rollouts သို့မဟုတ် Argo CI နှင့် ပတ်သက်၍ အတွေ့အကြုံရှိပါသလား။

ကျွန်ုပ်တို့၏ဘလော့ဂ်ရှိ အခြားဆောင်းပါးများကိုလည်း ဖတ်ပါ-

• Nginx ဝဘ်ဆာဗာဖြင့် Spring အက်ပ်လီကေးရှင်းများ၏ Blue-Green ဖြန့်ကျက်ခြင်း။
• Kubernetes- စနစ်အရင်းအမြစ်စီမံခန့်ခွဲမှုကို စတင်သတ်မှတ်ရန် အဘယ်ကြောင့် အလွန်အရေးကြီးသနည်း။
• Hashicorp ကောင်စစ်ဝန်၏ Kubernetes ခွင့်ပြုချက်အား နိဒါန်း
• Tekton ပိုက်လိုင်း - Kubernetes-ဇာတိပိုက်လိုင်းများ
• Nginx အတွက် ပြောင်းလဲနေသော မော်ဂျူးများကို တည်ဆောက်ခြင်း။
• Redmine အတွက် Telegram bot ။ သင်ကိုယ်တိုင်ရော အခြားသူများအတွက်ပါ ဘဝကို ရိုးရှင်းအောင် ဘယ်လိုလုပ်မလဲ။

source: www.habr.com