🥇 យុទ្ធសាស្ត្រដាក់ពង្រាយនៅក្នុង Kubernetes៖ រមៀល បង្កើតឡើងវិញ ខៀវ/បៃតង កាណារី ងងឹត (ការធ្វើតេស្ត A/B)

ចំណាំ ការបកប្រែ៖ ទិដ្ឋភាពទូទៅនេះពី Weaveworks ណែនាំអំពីយុទ្ធសាស្ត្រដាក់ឱ្យប្រើប្រាស់កម្មវិធីពេញនិយមបំផុត និងបង្ហាញពីរបៀបដែលកម្មវិធីកម្រិតខ្ពស់បំផុតអាចត្រូវបានអនុវត្តដោយប្រើប្រតិបត្តិករ Kubernetes Flagger ។ វាត្រូវបានសរសេរជាភាសាសាមញ្ញ និងមានដ្យាក្រាមដែលមើលឃើញដែលអនុញ្ញាតឱ្យសូម្បីតែវិស្វករថ្មីថ្មោងអាចយល់ពីបញ្ហានេះបាន។

ដ្យាក្រាមត្រូវបានយកចេញពី ពិនិត្យឡើងវិញ យុទ្ធសាស្ត្រដាក់ឱ្យដំណើរការដែលធ្វើឡើងនៅក្នុងដំណោះស្រាយកុងតឺន័រ

បញ្ហាប្រឈមដ៏ធំបំផុតមួយក្នុងការអភិវឌ្ឍន៍កម្មវិធីដើមលើពពកសព្វថ្ងៃនេះ គឺការបង្កើនល្បឿននៃការដាក់ឱ្យប្រើប្រាស់។ នៅក្នុងវិធីសាស្រ្តមីក្រូសេវា អ្នកអភិវឌ្ឍន៍បានធ្វើការជាមួយ និងរចនាកម្មវិធីម៉ូឌុលទាំងស្រុងរួចហើយ ដោយអនុញ្ញាតឱ្យក្រុមផ្សេងៗសរសេរកូដក្នុងពេលដំណាលគ្នា និងធ្វើការផ្លាស់ប្តូរកម្មវិធី។

ការដាក់ពង្រាយរយៈពេលខ្លី និងញឹកញាប់ជាងមុន មានអត្ថប្រយោជន៍ដូចខាងក្រោម៖

ពេលវេលាទៅទីផ្សារត្រូវបានកាត់បន្ថយ។
មុខងារថ្មីទៅដល់អ្នកប្រើប្រាស់លឿនជាងមុន។
មតិរបស់អ្នកប្រើប្រាស់ទៅដល់ក្រុមអភិវឌ្ឍន៍លឿនជាងមុន។ នេះមានន័យថាក្រុមអាចបន្ថែមមុខងារ និងដោះស្រាយបញ្ហាបានលឿនជាងមុន។
សីលធម៌របស់អ្នកអភិវឌ្ឍន៍កើនឡើង៖ លក្ខណៈពិសេសកាន់តែច្រើនក្នុងការអភិវឌ្ឍន៍គឺកាន់តែរីករាយក្នុងការធ្វើការជាមួយ។

ប៉ុន្តែនៅពេលដែលភាពញឹកញាប់នៃការចេញផ្សាយកើនឡើង ឱកាសនៃផលប៉ះពាល់អវិជ្ជមានលើភាពជឿជាក់របស់កម្មវិធី ឬបទពិសោធន៍អ្នកប្រើប្រាស់ក៏កើនឡើងផងដែរ។ នោះហើយជាមូលហេតុដែលវាមានសារៈសំខាន់សម្រាប់ប្រតិបត្តិការ និងក្រុម DevOps ដើម្បីបង្កើតដំណើរការ និងគ្រប់គ្រងយុទ្ធសាស្ត្រដាក់ឱ្យប្រើប្រាស់តាមរបៀបដែលកាត់បន្ថយហានិភ័យដល់ផលិតផល និងអ្នកប្រើប្រាស់។ (អ្នកអាចស្វែងយល់បន្ថែមអំពីស្វ័យប្រវត្តិកម្មបំពង់ CI/CD នៅទីនេះ.)

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

យុទ្ធសាស្ត្រដាក់ពង្រាយ

មានយុទ្ធសាស្ត្រដាក់ពង្រាយប្រភេទផ្សេងៗគ្នាជាច្រើន ដែលអ្នកអាចប្រើអាស្រ័យលើគោលដៅរបស់អ្នក។ ជាឧទាហរណ៍ អ្នកប្រហែលជាត្រូវធ្វើការផ្លាស់ប្តូរចំពោះបរិស្ថានជាក់លាក់មួយសម្រាប់ការធ្វើតេស្តបន្ថែម ឬចំពោះក្រុមអ្នកប្រើប្រាស់/អតិថិជន ឬអ្នកប្រហែលជាត្រូវធ្វើការសាកល្បងអ្នកប្រើប្រាស់ដែលមានកម្រិតមុនពេលបង្កើតមុខងារមួយ។ សាធារណៈ.

រំកិល (ការដាក់ពង្រាយ "រំកិល" បន្តិចម្តងៗ)

នេះគឺជាយុទ្ធសាស្ត្រដាក់ពង្រាយស្តង់ដារនៅក្នុង 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

ប៉ារ៉ាម៉ែត្រធ្វើបច្ចុប្បន្នភាពវិលជុំអាចត្រូវបានបញ្ជាក់នៅក្នុងឯកសារ manifest៖

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)

Canary rollouts គឺស្រដៀងទៅនឹងការចេញពណ៌ខៀវបៃតង ប៉ុន្តែមានការគ្រប់គ្រង និងប្រើប្រាស់បានប្រសើរជាង រីកចម្រើន វិធីសាស្រ្តជាជំហាន ៗ ។ ប្រភេទនេះរួមបញ្ចូលទាំងយុទ្ធសាស្ត្រខុសគ្នាមួយចំនួន រួមទាំងការបាញ់បង្ហោះ "បំបាំងកាយ" និងការធ្វើតេស្ត A/B។

យុទ្ធសាស្ត្រនេះត្រូវបានប្រើនៅពេលដែលមានតម្រូវការសាកល្បងមុខងារថ្មីមួយចំនួន ដែលជាធម្មតានៅក្នុងផ្នែកខាងក្រោយនៃកម្មវិធី។ ខ្លឹមសារនៃវិធីសាស្រ្តគឺបង្កើតម៉ាស៊ីនមេពីរដែលស្ទើរតែដូចគ្នាបេះបិទ៖ មួយបម្រើអ្នកប្រើប្រាស់ស្ទើរតែទាំងអស់ ហើយមួយទៀតមានមុខងារថ្មី បម្រើអ្នកប្រើប្រាស់តែក្រុមរងតូចមួយប៉ុណ្ណោះ បន្ទាប់មកលទ្ធផលនៃការងាររបស់ពួកគេត្រូវបានប្រៀបធៀប។ ប្រសិនបើអ្វីៗដំណើរការទៅដោយមិនមានកំហុស កំណែថ្មីត្រូវបានបញ្ចេញជាបណ្តើរៗទៅកាន់ហេដ្ឋារចនាសម្ព័ន្ធទាំងមូល។

ទោះបីជាយុទ្ធសាស្រ្តនេះអាចត្រូវបានអនុវត្តទាំងស្រុងដោយប្រើ Kubernetes ដោយជំនួសផតចាស់ជាមួយនឹងរបស់ថ្មីក៏ដោយ វាកាន់តែងាយស្រួល និងសាមញ្ញជាងក្នុងការប្រើសំណាញ់សេវាកម្មដូចជា Istio ។

ឧទាហរណ៍ អ្នកប្រហែលជាមាន manifest ពីរផ្សេងគ្នានៅក្នុង Git៖ manifest ធម្មតាជាមួយ tag 0.1.0 និង canary manifest ជាមួយ tag 0.2.0។ តាមរយៈការផ្លាស់ប្តូរទម្ងន់នៅក្នុងការបង្ហាញច្រកផ្លូវនិម្មិត Istio អ្នកអាចគ្រប់គ្រងការចែកចាយចរាចរណ៍រវាងការដាក់ពង្រាយទាំងពីរនេះ៖

សម្រាប់ការណែនាំជាជំហាន ៗ ដើម្បីអនុវត្តការដាក់ពង្រាយ Canary ដោយប្រើ Istio សូមមើល លំហូរការងាររបស់ GitOps ជាមួយ Istio. (ចំណាំ។ បកប្រែ៖ យើងក៏បានបកប្រែសម្ភារៈអំពីការដាក់ពង្រាយ Canary ទៅជា Istio នៅទីនេះ.)

ការដាក់ពង្រាយ Canary ជាមួយ Weaveworks Flagger

Weaveworks Flagger អនុញ្ញាតឱ្យអ្នកគ្រប់គ្រង Canary rollouts យ៉ាងងាយស្រួល និងមានប្រសិទ្ធភាព។

Flagger ស្វ័យប្រវត្តិដំណើរការជាមួយពួកគេ។ វាប្រើ Istio ឬ AWS App Mesh ដើម្បីបញ្ជូន និងប្តូរចរាចរណ៍ និងម៉ែត្រ Prometheus ដើម្បីវិភាគលទ្ធផល។ លើសពីនេះ ការវិភាគលើការដាក់ពង្រាយ Canary អាចត្រូវបានបន្ថែមដោយ webhooks ដើម្បីធ្វើតេស្តការទទួលយក ការធ្វើតេស្តផ្ទុក និងប្រភេទផ្សេងទៀតនៃការត្រួតពិនិត្យ។

ផ្អែកលើការដាក់ពង្រាយ Kubernetes ហើយប្រសិនបើចាំបាច់ ការធ្វើមាត្រដ្ឋានផ្តេកនៃផត (HPA) Flagger បង្កើតសំណុំនៃវត្ថុ (ការដាក់ពង្រាយ Kubernetes សេវា ClusterIP និង Istio ឬសេវាកម្មនិម្មិត App Mesh) ដើម្បីវិភាគ និងអនុវត្តការដាក់ពង្រាយ Canary៖

ការអនុវត្តរង្វិលជុំត្រួតពិនិត្យ (រង្វិលជុំត្រួតពិនិត្យ),Flagger ផ្លាស់ប្តូរចរាចរណ៍បន្តិចម្តងៗទៅកាន់ម៉ាស៊ីនមេ Canary ខណៈពេលដែលកំពុងវាស់ស្ទង់នូវសូចនាករសំខាន់ៗដូចជាភាគរយនៃសំណើ HTTP ដែលទទួលបានជោគជ័យ រយៈពេលស្នើសុំជាមធ្យម និងសុខភាពរបស់ pod ។ ដោយផ្អែកលើការវិភាគ KPI (សូចនាករការអនុវត្តសំខាន់ៗ) Canary លូតលាស់ឬដួលរលំហើយលទ្ធផលនៃការវិភាគត្រូវបានបោះពុម្ពផ្សាយនៅក្នុង Slack ។ ការពិពណ៌នា និងការបង្ហាញនៃដំណើរការនេះអាចត្រូវបានរកឃើញនៅក្នុងសម្ភារៈ ការបញ្ជូនបន្តសម្រាប់ App Mesh.

ងងឹត (លាក់) ឬការដាក់ពង្រាយ A/B

ការដាក់ពង្រាយបំបាំងកាយគឺជាបំរែបំរួលមួយផ្សេងទៀតនៃយុទ្ធសាស្ត្រ Canary (ដែលតាមវិធីនេះ Flagger ក៏អាចធ្វើការជាមួយផងដែរ) ។ ភាពខុសគ្នារវាងការដំឡើងបំបាំងកាយ និងការដាក់ពង្រាយ Canary គឺថា ការដាក់ពង្រាយបំបាំងកាយដោះស្រាយជាមួយផ្នែកខាងមុខជាជាងផ្នែកខាងក្រោយដូចជាការដាក់ពង្រាយ Canary ។

ឈ្មោះផ្សេងទៀតសម្រាប់ការដាក់ពង្រាយទាំងនេះគឺការធ្វើតេស្ត A/B ។ ជំនួសឱ្យការធ្វើឱ្យមុខងារថ្មីមានសម្រាប់អ្នកប្រើប្រាស់ទាំងអស់ វាត្រូវបានផ្តល់ជូនសម្រាប់តែផ្នែកដែលមានកំណត់ប៉ុណ្ណោះ។ ជាធម្មតា អ្នកប្រើប្រាស់ទាំងនេះមិនដឹងថាពួកគេជាអ្នកសាកល្បងត្រួសត្រាយទេ (ហេតុដូច្នេះហើយបានជាពាក្យថា "ការដាក់ពង្រាយបំបាំងកាយ")។

ការប្រើប្រាស់ឧបករណ៍ប្តូរមុខងារ (មុខងារបិទបើក) និងឧបករណ៍ផ្សេងទៀត អ្នកអាចតាមដានពីរបៀបដែលអ្នកប្រើប្រាស់ធ្វើអន្តរកម្មជាមួយមុខងារថ្មីនេះ ថាតើពួកគេត្រូវបានភ្ជាប់ដោយវា ឬថាតើពួកគេរកឃើញចំណុចប្រទាក់អ្នកប្រើថ្មីច្របូកច្របល់ និងប្រភេទម៉ែត្រផ្សេងទៀត។

ការដាក់ពង្រាយ Flagger និង A/B

បន្ថែមពីលើការនាំផ្លូវដោយផ្អែកលើទម្ងន់ Flagger ក៏អាចបញ្ជូនចរាចរទៅកាន់ម៉ាស៊ីនមេ Canary ដោយផ្អែកលើប៉ារ៉ាម៉ែត្រ HTTP ផងដែរ។ នៅក្នុងការធ្វើតេស្ត A/B អ្នកអាចប្រើបឋមកថា HTTP ឬខូគីដើម្បីកំណត់គោលដៅផ្នែកជាក់លាក់នៃអ្នកប្រើប្រាស់។ នេះមានប្រសិទ្ធភាពជាពិសេសនៅក្នុងករណីនៃកម្មវិធី frontend ដែលទាមទារ session binding ទៅ server (ភាពស្និទ្ធស្នាលសម័យ). ព័ត៌មានបន្ថែមអាចរកបាននៅក្នុងឯកសារ Flagger ។

អ្នកនិពន្ធបង្ហាញពីការដឹងគុណ Stefan Prodanវិស្វករ Weaveworks (និងអ្នកបង្កើត Flagger) សម្រាប់គំរូនៃការដាក់ពង្រាយដ៏អស្ចារ្យទាំងអស់នេះ។

PS ពីអ្នកបកប្រែ

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

ប្រភព: www.habr.com

យុទ្ធសាស្ត្រដាក់ឱ្យប្រើប្រាស់នៅក្នុង Kubernetes៖ រមៀល បង្កើតឡើងវិញ ខៀវ/បៃតង កាណារី ងងឹត (ការធ្វើតេស្ត A/B)