🥇ការដាក់ពង្រាយ Canary នៅក្នុង Kubernetes #1: Gitlab CI

យើងនឹងប្រើ Gitlab CI និង GitOps ដោយដៃ ដើម្បីអនុវត្ត និងប្រើប្រាស់ការដាក់ពង្រាយ Canary នៅក្នុង Kubernetes

អត្ថបទពីស៊េរីនេះ៖

(អត្ថបទនេះ)
ការដាក់ពង្រាយ Canary ដោយប្រើ ArgoCI
ការដាក់ពង្រាយ Canary ដោយប្រើ Istio
ការដាក់ពង្រាយ Canary ដោយប្រើ Jenkins-X Istio Flagger

យើងនឹងអនុវត្តការដាក់ពង្រាយ Canary ដោយដៃតាមរយៈ GitOps និងបង្កើត/កែប្រែធនធាន Kubernetes សំខាន់ៗ។ អត្ថបទនេះត្រូវបានបម្រុងទុកជាចម្បងសម្រាប់ការណែនាំ ជាមួយនឹងរបៀបដែលការដាក់ពង្រាយដំណើរការនៅក្នុង Kubernetes Canary ចាប់តាំងពីមានវិធីសាស្រ្តស្វ័យប្រវត្តិកម្មដែលមានប្រសិទ្ធភាពជាងមុន ដែលយើងនឹងពិចារណានៅក្នុងអត្ថបទខាងក្រោម។

https://www.norberteder.com/canary-deployment/

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

ជាមួយនឹងយុទ្ធសាស្ត្រ Canary ការធ្វើបច្ចុប្បន្នភាពត្រូវបានអនុវត្តដំបូងចំពោះតែអ្នកប្រើប្រាស់មួយចំនួនប៉ុណ្ណោះ។ តាមរយៈការត្រួតពិនិត្យ ទិន្នន័យកំណត់ហេតុ ការធ្វើតេស្តដោយដៃ ឬបណ្តាញមតិកែលម្អផ្សេងទៀត ការចេញផ្សាយត្រូវបានសាកល្បង មុនពេលវាត្រូវបានចេញផ្សាយទៅកាន់អ្នកប្រើប្រាស់ទាំងអស់។

ការដាក់ឱ្យប្រើប្រាស់ Kubernetes (ការធ្វើបច្ចុប្បន្នភាពរំកិល)

យុទ្ធសាស្ត្រលំនាំដើមសម្រាប់ការដាក់ឱ្យប្រើប្រាស់ Kubernetes គឺការអាប់ដេតរំកិល ដែលចំនួនផតឃែរមួយចំនួនត្រូវបានចាប់ផ្តើមជាមួយនឹងកំណែថ្មីនៃរូបភាព។ ប្រសិនបើពួកវាត្រូវបានបង្កើតដោយគ្មានបញ្ហានោះ ផតដែលមានរូបភាពជំនាន់ចាស់ត្រូវបានបញ្ចប់ ហើយផតថ្មីត្រូវបានបង្កើតស្របគ្នា។

ហ្គីតូប

យើងប្រើ GitOps ក្នុងឧទាហរណ៍នេះ ដោយសារយើង៖

ការប្រើប្រាស់ Git ជាប្រភពតែមួយនៃការពិត
យើងប្រើ Git Operations សម្រាប់បង្កើត និងដាក់ពង្រាយ (មិនចាំបាច់មានពាក្យបញ្ជាក្រៅពី git tag/merge)

ឧទាហរណ៍:

ចូរយើងអនុវត្តការអនុវត្តដ៏ល្អមួយ - ដើម្បីមានឃ្លាំងមួយសម្រាប់កូដកម្មវិធី និងមួយទៀតសម្រាប់ហេដ្ឋារចនាសម្ព័ន្ធ។

ឃ្លាំងកម្មវិធី

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

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

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

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

នៅក្នុង turnip នេះយើងនឹងដាក់ពង្រាយតាមរយៈ GitlabCI ទៅ Kubernetes, .gitlab-ci.yml មើលទៅដូចនេះ:

image: traherom/kustomize-docker

before_script:
   - printenv
   - kubectl version

stages:
 - deploy

deploy 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: app
 name: app
spec:
 ports:
 - port: 80
   protocol: TCP
   targetPort: 5000
 selector:
   id: app
 type: LoadBalancer

និងការដាក់ពង្រាយនៅក្នុង deploy.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: app
spec:
 replicas: 10
 selector:
   matchLabels:
     id: app
     type: main
 template:
   metadata:
     labels:
       id: app
       type: main
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

និងការដាក់ពង្រាយមួយផ្សេងទៀតនៅក្នុង deploy-canary.yaml:

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 0
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

ចំណាំថា app-deploy មិនទាន់មានការកំណត់ចម្លងណាមួយនៅឡើយទេ។

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

ដើម្បីចាប់ផ្តើមការដាក់ពង្រាយដំបូង អ្នកអាចចាប់ផ្តើមបំពង់ GitlabCI ដោយដៃនៅលើសាខាមេ។ បន្ទាប់មក kubectl គួរតែចេញលទ្ធផលដូចខាងក្រោមៈ

យើងឃើញ app ការដាក់ពង្រាយជាមួយ 10 replicas និង app-canary ជាមួយ 0. វាក៏មាន LoadBalancer ដែលយើងអាចចូលប្រើបានតាមរយៈ curl តាមរយៈ IP ខាងក្រៅ៖

while true; do curl -s 35.198.149.232 | grep label; sleep 0.1; done

យើងឃើញថាកម្មវិធីសាកល្បងរបស់យើងត្រឡប់មកវិញតែ “v1” ប៉ុណ្ណោះ។

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

ជំហានទី 1: ចេញកំណែថ្មីសម្រាប់អ្នកប្រើប្រាស់មួយចំនួន

យើងកំណត់ចំនួនចម្លងទៅ 1 នៅក្នុងឯកសារ deploy-canary.yaml និងរូបភាពកំណែថ្មី៖

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 1
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

នៅក្នុងឯកសារ deploy.yaml យើងបានផ្លាស់ប្តូរចំនួនចម្លងទៅជា 9៖

kind: Deployment
metadata:
 name: app
spec:
 replicas: 9
 selector:
   matchLabels:
     id: app
...

យើងជំរុញការផ្លាស់ប្តូរទាំងនេះទៅកាន់ឃ្លាំងដែលការដាក់ពង្រាយនឹងចាប់ផ្តើម (តាមរយៈ GitlabCI) ហើយឃើញជាលទ្ធផល៖

សេវាកម្មរបស់យើងនឹងចង្អុលទៅការដាក់ពង្រាយទាំងពីរ ដោយសារទាំងពីរមានកម្មវិធីជ្រើសរើស។ ដោយសារការចៃដន្យលំនាំដើមរបស់ Kubernetes យើងគួរតែឃើញការឆ្លើយតបផ្សេងៗគ្នាសម្រាប់ ~10% នៃសំណើ៖

ស្ថានភាពបច្ចុប្បន្ននៃកម្មវិធីរបស់យើង (GitOps យកចេញពី Git ជាប្រភពតែមួយនៃការពិត) គឺជាវត្តមាននៃការដាក់ពង្រាយពីរជាមួយនឹងការចម្លងសកម្ម មួយសម្រាប់កំណែនីមួយៗ។

~ 10% នៃអ្នកប្រើប្រាស់ស្គាល់កំណែថ្មី ហើយសាកល្បងដោយអចេតនា។ ឥឡូវនេះជាពេលវេលាដើម្បីពិនិត្យមើលកំហុសនៅក្នុងកំណត់ហេតុ និងត្រួតពិនិត្យទិន្នន័យដើម្បីស្វែងរកបញ្ហា។

ជំហានទី 2: ចេញផ្សាយកំណែថ្មីដល់អ្នកប្រើប្រាស់ទាំងអស់។

យើងបានសម្រេចចិត្តថាអ្វីៗដំណើរការល្អ ហើយឥឡូវនេះយើងត្រូវដាក់ចេញកំណែថ្មីដល់អ្នកប្រើប្រាស់ទាំងអស់។ ដើម្បីធ្វើដូចនេះយើងគ្រាន់តែធ្វើបច្ចុប្បន្នភាព deploy.yaml ការដំឡើងកំណែថ្មីនៃរូបភាព និងចំនួននៃការចម្លងស្មើនឹង 10. ក្នុង deploy-canary.yaml យើងកំណត់ចំនួនចម្លងត្រឡប់មកត្រឹម 0។ បន្ទាប់ពីការដាក់ពង្រាយ លទ្ធផលនឹងមានដូចខាងក្រោម៖

ដើម្បីសង្ខេប។

សម្រាប់ខ្ញុំ ការដំណើរការការដាក់ពង្រាយដោយដៃ វិធីនេះជួយឱ្យយល់ពីរបៀបដែលវាអាចត្រូវបានកំណត់រចនាសម្ព័ន្ធដោយប្រើ k8s យ៉ាងងាយស្រួល។ ដោយសារ Kubernetes អនុញ្ញាតឱ្យអ្នកធ្វើបច្ចុប្បន្នភាពអ្វីៗគ្រប់យ៉ាងតាមរយៈ API ជំហានទាំងនេះអាចត្រូវបានស្វ័យប្រវត្តិតាមរយៈស្គ្រីប។

រឿងមួយទៀតដែលត្រូវអនុវត្តគឺចំណុចបញ្ចូលអ្នកសាកល្បង (LoadBalancer ឬតាមរយៈ Ingress) ដែលមានតែកំណែថ្មីប៉ុណ្ណោះដែលអាចចូលប្រើបាន។ វាអាចត្រូវបានប្រើសម្រាប់ការរុករកដោយដៃ។

នៅក្នុងអត្ថបទនាពេលអនាគត យើងនឹងពិនិត្យមើលដំណោះស្រាយស្វ័យប្រវត្តិផ្សេងទៀត ដែលអនុវត្តភាគច្រើននៃអ្វីដែលយើងបានធ្វើ។

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

ប្រភព: www.habr.com

ការដាក់ពង្រាយ Canary នៅក្នុង Kubernetes # 1: Gitlab CI