🥇 ការដាក់ពង្រាយ Canary នៅក្នុង Kubernetes #2: Argo Rollouts

យើងនឹងប្រើឧបករណ៍បញ្ជាការដាក់ពង្រាយ Argo Rollouts ដើម k8s និង GitlabCI ដើម្បីដំណើរការការដាក់ពង្រាយ Canary ទៅ Kubernetes

https://unsplash.com/photos/V41PulGL1z0

អត្ថបទនៅក្នុងស៊េរីនេះ។

ការដាក់ពង្រាយ Canary នៅក្នុង Kubernetes # 1: Gitlab CI
(អត្ថបទនេះ)
ការដាក់ពង្រាយ Canary ដោយប្រើ Istio
ការដាក់ពង្រាយ Canary ដោយប្រើ Jenkins-X Istio Flagger

ការដាក់ពង្រាយ Canary

យើងសង្ឃឹមថាអ្នកអាន ផ្នែកដំបូងដែលជាកន្លែងដែលយើងបានពន្យល់យ៉ាងខ្លីអំពីអ្វីដែល Canary Deployments គឺ។ យើងក៏បានបង្ហាញពីរបៀបអនុវត្តវាដោយប្រើធនធាន Kubernetes ស្តង់ដារផងដែរ។

ការចេញផ្សាយ Argo

Argo Rollouts គឺជាឧបករណ៍បញ្ជាការដាក់ពង្រាយដើម Kubernetes ។ វាផ្តល់ CRD (និយមន័យធនធានផ្ទាល់ខ្លួន) សម្រាប់ Kubernetes ។ អរគុណចំពោះវា យើងអាចប្រើអង្គភាពថ្មី៖ Rolloutដែលគ្រប់គ្រងការដាក់ពង្រាយពណ៌ខៀវបៃតង និង Canary ជាមួយនឹងជម្រើសនៃការកំណត់រចនាសម្ព័ន្ធផ្សេងៗ។

ឧបករណ៍បញ្ជា Argo Rollouts ប្រើដោយធនធានផ្ទាល់ខ្លួន Rollout, អនុញ្ញាតឱ្យមានយុទ្ធសាស្ត្រដាក់ពង្រាយបន្ថែមដូចជាពណ៌ខៀវបៃតង និង Canary សម្រាប់ Kubernetes ។ ធនធាន Rollout ផ្តល់មុខងារសមមូល Deploymentមានតែជាមួយយុទ្ធសាស្ត្រដាក់ពង្រាយបន្ថែមប៉ុណ្ណោះ។
ធនធាន Deployments មានយុទ្ធសាស្ត្រពីរសម្រាប់ដាក់ពង្រាយ៖ RollingUpdate и Recreate. ទោះបីជាយុទ្ធសាស្ត្រទាំងនេះមានលក្ខណៈសមរម្យសម្រាប់ករណីភាគច្រើនក៏ដោយ សម្រាប់ការដាក់ពង្រាយទៅកាន់ម៉ាស៊ីនមេក្នុងទ្រង់ទ្រាយធំ យុទ្ធសាស្ត្របន្ថែមត្រូវបានប្រើប្រាស់ ដូចជាពណ៌ខៀវ-បៃតង ឬ Canary ដែលមិនមាននៅក្នុងឧបករណ៍បញ្ជាការដាក់ឱ្យប្រើប្រាស់។ ដើម្បីប្រើយុទ្ធសាស្ត្រទាំងនេះនៅក្នុង Kubernetes អ្នកប្រើប្រាស់ត្រូវសរសេរស្គ្រីបពីលើការដាក់ឱ្យប្រើប្រាស់របស់ពួកគេ។ ឧបករណ៍បញ្ជា Argo Rollouts លាតត្រដាងយុទ្ធសាស្ត្រទាំងនេះជាប៉ារ៉ាម៉ែត្រសាមញ្ញ ប្រកាស និងកំណត់រចនាសម្ព័ន្ធបាន។
https://argoproj.github.io/argo-rollouts

វាក៏មាន Argo CI ដែលផ្តល់នូវចំណុចប្រទាក់បណ្ដាញងាយស្រួលសម្រាប់ប្រើជាមួយ Rollouts យើងនឹងពិនិត្យមើលវានៅក្នុងអត្ថបទបន្ទាប់។

ការដំឡើង Argo Rollouts

ផ្នែកខាងម៉ាស៊ីនមេ

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

នៅក្នុង turnip ហេដ្ឋារចនាសម្ព័ន្ធរបស់យើង (សូមមើលខាងក្រោម) យើងបានបន្ថែម install.yaml ជា i/k8s/argo-rollouts/install.yaml រួចហើយ។ វិធីនេះ GitlabCI នឹងដំឡើងវាទៅក្នុងចង្កោម។

ផ្នែកអតិថិជន (កម្មវិធីជំនួយ kubectl)

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

កម្មវិធីឧទាហរណ៍

វាជាការអនុវត្តល្អក្នុងការមានឃ្លាំងដាច់ដោយឡែកសម្រាប់កូដកម្មវិធី និងហេដ្ឋារចនាសម្ព័ន្ធ។

ឃ្លាំងសម្រាប់កម្មវិធី

Kim Wuestkamp/k8s-deployment-example-app

នេះគឺជា Python+Flask API ដ៏សាមញ្ញបំផុតដែលត្រឡប់ការឆ្លើយតបជា JSON ។ យើងនឹងបង្កើតកញ្ចប់ដោយប្រើ GitlabCI ហើយរុញលទ្ធផលទៅ Gitlab Registry ។ នៅក្នុងបញ្ជីឈ្មោះ យើងមានកំណែចេញផ្សាយពីរផ្សេងគ្នា៖

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

ភាពខុសគ្នាតែមួយគត់រវាងពួកវាគឺឯកសារ JSON ត្រឡប់មកវិញ។ យើងប្រើកម្មវិធីនេះដើម្បីមើលឃើញយ៉ាងងាយស្រួលតាមដែលអាចធ្វើទៅបានថាតើកំណែណាមួយដែលយើងកំពុងទាក់ទងជាមួយ។

ឃ្លាំងហេដ្ឋារចនាសម្ព័ន្ធ

នៅក្នុងឃ្លាំងនេះ យើងនឹងប្រើ GitlabCI សម្រាប់ការដាក់ឱ្យប្រើប្រាស់ទៅកាន់ Kubernetes, .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

ដើម្បីដំណើរការវាដោយខ្លួនឯង អ្នកនឹងត្រូវការ cluster អ្នកអាចប្រើ 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 និងបង្កើតអថេរ KUBECONFIG នៅក្នុង GitlabCI ដែលនឹងមាន 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 ដំណើរការដូចគ្នានឹងការដាក់ពង្រាយ។ ប្រសិនបើយើងមិនកំណត់យុទ្ធសាស្ត្រអាប់ដេតទេ (ដូចជា Canary នៅទីនេះ) វានឹងមានលក្ខណៈដូចជា default rolling-update Deployment។

យើងកំណត់ពីរជំហាននៅក្នុង yaml សម្រាប់ការដាក់ពង្រាយ Canary:

10% នៃចរាចរណ៍ទៅកាន់ Canary (រង់ចាំដោយដៃ OK)
50% ចរាចរទៅកាន់ Canary (រង់ចាំ 2 នាទីបន្ទាប់មកបន្តទៅ 100%)

អនុវត្តការដាក់ពង្រាយដំបូង

បន្ទាប់ពីការដាក់ឱ្យប្រើប្រាស់ដំបូង ធនធានរបស់យើងនឹងមើលទៅដូចនេះ៖

ហើយយើងទទួលបានការឆ្លើយតបតែពីកំណែដំបូងនៃកម្មវិធីប៉ុណ្ណោះ៖

ការអនុវត្តការដាក់ពង្រាយ Canary

ជំហានទី 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 ដាក់ពង្រាយ ហើយយើងឃើញការផ្លាស់ប្តូរ៖

ឥឡូវនេះប្រសិនបើយើងចូលប្រើសេវាកម្ម៖

អស្ចារ្យ! យើងស្ថិតនៅចំកណ្តាលនៃការដាក់ពង្រាយ Canary របស់យើង។ យើងអាចមើលឃើញវឌ្ឍនភាពដោយការដំណើរការ៖

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% នឹងចាប់ផ្តើម៖

និងលទ្ធផលកម្មវិធី៖

និងការពិនិត្យឡើងវិញនៃការចេញផ្សាយ:

ការដាក់ពង្រាយ Canary ត្រូវបានបញ្ចប់។

ឧទាហរណ៍បន្ថែមទៀតជាមួយ Argo Rollouts

មានឧទាហរណ៍ជាច្រើនទៀតនៅទីនេះ ដូចជារបៀបរៀបចំការមើលបរិស្ថានជាមុន និងការប្រៀបធៀបដោយផ្អែកលើ Canary៖

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 ទេ?

សូមអានអត្ថបទផ្សេងទៀតនៅលើប្លក់របស់យើងផងដែរ៖

ប្រភព: www.habr.com

ការដាក់ពង្រាយ Canary នៅក្នុង Kubernetes # 2: ការចេញផ្សាយ Argo