ការដាក់ពង្រាយ Canary នៅក្នុង Kubernetes # 3: Istio

ការប្រើប្រាស់ Istio+Kiali ដើម្បីចាប់ផ្តើម និងមើលឃើញការដាក់ពង្រាយ Canary

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

1. ការដាក់ពង្រាយ Canary នៅក្នុង Kubernetes # 1: Gitlab CI
2. ការដាក់ពង្រាយ Canary នៅក្នុង Kubernetes # 2: ការចេញផ្សាយ Argo
3. (អត្ថបទ​នេះ)
4. ការដាក់ពង្រាយ Canary ដោយប្រើ Jenkins-X Istio Flagger

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

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

អ៊ីស៊ីអូ

ហើយយើងសន្មត់ថាដោយការអានអត្ថបទនេះ អ្នកដឹងរួចហើយថា Istio ជាអ្វី។ បើមិនដូច្នោះទេអ្នកអាចអានអំពីវា។ នៅទីនេះ.

ពាក្យស្នើសុំសម្រាប់ការធ្វើតេស្ត

ផតនីមួយៗមានធុងពីរ៖ កម្មវិធីរបស់យើង និង istio-ប្រូកស៊ី។

យើងនឹងប្រើកម្មវិធីសាកល្បងដ៏សាមញ្ញមួយជាមួយ frontend-nginx និង backend python pods ។ ផត nginx នឹងបញ្ជូនបន្តសំណើនីមួយៗទៅកាន់ផ្នែកខាងក្រោយ ហើយដំណើរការជាប្រូកស៊ី។ ព័ត៌មាន​លម្អិត​អាច​រក​បាន​នៅ​ក្នុង​យ៉ាម​ដូច​ខាង​ក្រោម៖

• frontend.yaml
• backend.yaml
• istio.yaml

ដំណើរការកម្មវិធីសាកល្បងដោយខ្លួនឯង។

ប្រសិនបើអ្នកចង់ធ្វើតាមគំរូរបស់ខ្ញុំ ហើយប្រើកម្មវិធីសាកល្បងនេះដោយខ្លួនឯង សូមមើល គម្រោងអានខ្ញុំ.

ការដាក់ពង្រាយដំបូង

នៅពេលដែលយើងចាប់ផ្តើមការដាក់ពង្រាយដំបូង យើងឃើញថា pods នៃកម្មវិធីរបស់យើងមានតែ 2 containers នោះគឺ Istio sidecar ទើបតែត្រូវបានអនុវត្ត៖

ហើយយើងក៏ឃើញ Istio Gateway Loadbalancer នៅក្នុង namespace istio-system:

ការបង្កើតចរាចរណ៍

យើង​នឹង​ប្រើ IP ខាងក្រោម​ដើម្បី​បង្កើត​ចរាចរណ៍​ដែល​នឹង​ត្រូវ​បាន​ទទួល​ដោយ frontend pods និង​បញ្ជូន​បន្ត​ទៅ pods ខាងក្រោយ៖

while true; do curl -s --resolve 'frontend.istio-test:80:35.242.202.152' frontend.istio-test; sleep 0.1; done

យើងក៏នឹងបន្ថែមផងដែរ។ frontend.istio-test ទៅកាន់ឯកសារ hosts របស់យើង។

មើល Mesh តាមរយៈ Kiali

យើងបានដំឡើងកម្មវិធីសាកល្បង និង Istio រួមជាមួយនឹង Tracing, Grafana, Prometheus និង Kiali (សូមមើលខាងក្រោមសម្រាប់ព័ត៌មានលម្អិត)។ គម្រោងអានខ្ញុំ) ដូច្នេះយើងអាចប្រើ Kiali តាមរយៈ៖

istioctl dashboard kiali # admin:admin

Kiali មើលឃើញចរាចរណ៍បច្ចុប្បន្នតាមរយៈ Mesh

ដូចដែលយើងអាចមើលឃើញ 100% នៃចរាចរទៅកាន់សេវាផ្នែកខាងមុខ បន្ទាប់មកទៅកាន់ផតផតខាងមុខដែលមានស្លាក v1 ចាប់តាំងពីយើងកំពុងប្រើប្រូកស៊ី nginx សាមញ្ញដែលបញ្ជូនបន្តសំណើទៅកាន់សេវាកម្មផ្នែកខាងក្រោយ ដែលនាំពួកគេទៅកាន់ផ្នែកខាងក្រោយ។ ជាមួយស្លាក v1.

Kiali ដំណើរការបានល្អជាមួយ Istio និងផ្តល់នូវដំណោះស្រាយបង្ហាញ Mesh ប្រអប់។ គ្រាន់តែអស្ចារ្យ។

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

ផ្នែកខាងក្រោយរបស់យើងមានការដាក់ពង្រាយ k8s ពីររួចហើយ មួយសម្រាប់ v1 និងមួយទៀតសម្រាប់ v2។ ឥឡូវនេះយើងគ្រាន់តែត្រូវប្រាប់ Istio ឱ្យបញ្ជូនភាគរយជាក់លាក់នៃសំណើទៅ v2.

ជំហានទី 1: 10%

ហើយអ្វីទាំងអស់ដែលយើងត្រូវធ្វើគឺកែតម្រូវទម្ងន់នៃសេវាកម្ម VirtualService istio.yaml:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

យើងឃើញថា 10% នៃសំណើត្រូវបានបញ្ជូនបន្តទៅ v2.

ជំហានទី 2: 50%

ហើយឥឡូវនេះវាគ្រប់គ្រាន់ហើយក្នុងការបង្កើនវាដល់ 50%៖

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
...
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 50
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 50

ជំហានទី 3: 100%

ឥឡូវនេះ ការដាក់ពង្រាយ Canary អាចត្រូវបានចាត់ទុកថាពេញលេញ ហើយចរាចរណ៍ទាំងអស់ត្រូវបានប្តូរទិសទៅ v2៖

សាកល្បង Canary ដោយដៃ

ឧបមាថាឥឡូវនេះយើងផ្ញើ 2% នៃសំណើទាំងអស់ទៅកាន់ផ្នែកខាងក្រោយ v10 ។ ចុះប្រសិនបើយើងចង់សាកល្បង v2 ដោយដៃ ដើម្បីប្រាកដថាអ្វីៗដំណើរការដូចដែលយើងរំពឹងទុក?

យើងអាចបន្ថែមច្បាប់ផ្គូផ្គងពិសេសដោយផ្អែកលើបឋមកថា HTTP៖

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - headers:
        canary:
          exact: "canary-tester"
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

ឥឡូវនេះដោយប្រើ curl យើងអាចបង្ខំសំណើ v2 ដោយផ្ញើបឋមកថា:

សំណើដោយគ្មានបឋមកថានឹងនៅតែត្រូវបានជំរុញដោយសមាមាត្រ 1/10៖

Canary សម្រាប់កំណែពឹងផ្អែកពីរ

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

យើងឃើញថា frontend v1 និង v2 ទាំងពីរចរាចរទៅមុខក្នុងសមាមាត្រនៃ 1/10 ទៅ backend v1 និង v2 ។

ចុះប្រសិនបើយើងត្រូវការបញ្ជូនចរាចរណ៍ពី frontend-v2 ទៅ backend-v2 ព្រោះវាមិនត្រូវគ្នាជាមួយ v1? ដើម្បីធ្វើដូច្នេះ យើងនឹងកំណត់សមាមាត្រ 1/10 សម្រាប់ផ្នែកខាងមុខ ដែលគ្រប់គ្រងអ្វីដែលចរាចរណ៍ទទួលបានទៅកាន់ backend-v2 ដោយប្រើការចរចា sourceLabels :

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
...
  - match:
    - sourceLabels:
        app: frontend
        version: v2
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100

ជាលទ្ធផលយើងទទួលបានអ្វីដែលយើងត្រូវការ៖

ភាពខុសគ្នាពីវិធីសាស្រ្ត Canary ដោយដៃ

В ផ្នែកដំបូង។ យើងអនុវត្តការដាក់ពង្រាយ Canary ដោយដៃ ដោយប្រើការដាក់ពង្រាយ k8s ពីរផងដែរ។ នៅទីនោះ យើងបានគ្រប់គ្រងសមាមាត្រនៃសំណើដោយការផ្លាស់ប្តូរចំនួននៃការចម្លង។ វិធីសាស្រ្តនេះមានប្រសិទ្ធភាព ប៉ុន្តែមានគុណវិបត្តិយ៉ាងធ្ងន់ធ្ងរ។

Istio ធ្វើឱ្យវាអាចកំណត់សមាមាត្រនៃសំណើដោយមិនគិតពីចំនួននៃការចម្លង។ ជាឧទាហរណ៍ នេះមានន័យថាយើងអាចប្រើ HPAs (Horizontal Pod Autoscalers) ហើយមិនចាំបាច់កំណត់រចនាសម្ព័ន្ធតាមស្ថានភាពបច្ចុប្បន្ននៃការដាក់ពង្រាយ Canary នោះទេ។

លទ្ធផល

Istio ដំណើរការបានល្អណាស់ ហើយការប្រើវារួមគ្នាជាមួយ Kiali ធ្វើឱ្យមានការរួមបញ្ចូលគ្នាដ៏មានឥទ្ធិពល។ បន្ទាប់នៅក្នុងបញ្ជីចំណាប់អារម្មណ៍របស់ខ្ញុំគឺការរួមបញ្ចូល Spinnaker ជាមួយ Istio សម្រាប់ស្វ័យប្រវត្តិកម្ម និង Canary analytics ។

ប្រភព: www.habr.com