ត្រឡប់ទៅ សេវាមីក្រូ ជាមួយ Istio ។ ផ្នែកទី 2

ចំណាំ។ បកប្រែ: ផ្នែកដំបូង ស៊េរីនេះត្រូវបានឧទ្ទិសដល់ការណែនាំសមត្ថភាព Istio និងបង្ហាញពួកវានៅក្នុងសកម្មភាព។ ឥឡូវនេះ យើងនឹងនិយាយអំពីទិដ្ឋភាពស្មុគស្មាញបន្ថែមទៀតនៃការកំណត់រចនាសម្ព័ន្ធ និងការប្រើប្រាស់បណ្តាញសេវានេះ ហើយជាពិសេសអំពីការកំណត់ផ្លូវដែលបានកែសម្រួលយ៉ាងល្អិតល្អន់ និងការគ្រប់គ្រងចរាចរណ៍បណ្តាញ។

យើងក៏រំលឹកអ្នកថាអត្ថបទប្រើការកំណត់រចនាសម្ព័ន្ធ (បង្ហាញសម្រាប់ Kubernetes និង Istio) ពីឃ្លាំង ជំនាញ istio.

ការគ្រប់គ្រងចរាចរណ៍

ជាមួយនឹង Istio សមត្ថភាពថ្មីលេចឡើងនៅក្នុងចង្កោមដើម្បីផ្តល់៖

• ដំណើរ​ការ​សំណើ​ថាមវន្ត: ការដាក់ចេញ Canary, ការធ្វើតេស្ត A/B;
• ផ្ទុកតុល្យភាព៖ សាមញ្ញ និងជាប់លាប់ ដោយផ្អែកលើសញ្ញាសញ្ញា;
• ការងើបឡើងវិញបន្ទាប់ពីការដួលរលំ៖ អស់ពេល, ព្យាយាមឡើងវិញ, ឧបករណ៍បំបែកសៀគ្វី;
• ការបញ្ចូលកំហុស៖ ការពន្យាពេល សំណើធ្លាក់ចុះ។ល។

នៅពេលអត្ថបទបន្ត សមត្ថភាពទាំងនេះនឹងត្រូវបានបង្ហាញដោយប្រើកម្មវិធីដែលបានជ្រើសរើសជាឧទាហរណ៍ ហើយគំនិតថ្មីនឹងត្រូវបានណែនាំតាមផ្លូវ។ គំនិតបែបនេះដំបូងនឹងមាន DestinationRules (ឧ. ច្បាប់អំពីអ្នកទទួលចរាចរណ៍/សំណើ - ប្រហែលបកប្រែ។ )ដោយមានជំនួយពីការដែលយើងធ្វើឱ្យការធ្វើតេស្ត A/B សកម្ម។

ការធ្វើតេស្ត A/B៖ គោលការណ៍គោលដៅក្នុងការអនុវត្ត

ការធ្វើតេស្ត A/B ត្រូវបានប្រើក្នុងករណីដែលកម្មវិធីមានកំណែពីរ (ជាធម្មតាវាខុសគ្នាដោយមើលឃើញ) ហើយយើងមិនប្រាកដ 100% ថាតើកម្មវិធីមួយណានឹងធ្វើអោយបទពិសោធន៍អ្នកប្រើប្រាស់ប្រសើរឡើងនោះទេ។ ដូច្នេះ យើងដំណើរការកំណែទាំងពីរក្នុងពេលដំណាលគ្នា និងប្រមូលម៉ែត្រ។

ដើម្បីដាក់ពង្រាយកំណែទីពីរនៃផ្នែកខាងមុខ ដែលទាមទារសម្រាប់ការបង្ហាញការធ្វើតេស្ត A/B សូមដំណើរការពាក្យបញ្ជាខាងក្រោម៖

$ kubectl apply -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions/sa-frontend-green created

ការ​ដាក់​ពង្រាយ​បង្ហាញ​ឱ្យ​ឃើញ​សម្រាប់​កំណែ​បៃតង​ខុស​គ្នា​ក្នុង​ពីរ​កន្លែង៖

1. រូបភាពគឺផ្អែកលើស្លាកផ្សេង - istio-green,
2. Pods មានស្លាកមួយ។ version: green.

ចាប់តាំងពីការដាក់ពង្រាយទាំងពីរមានស្លាកមួយ។ app: sa-frontendសំណើដែលបញ្ជូនដោយសេវាកម្មនិម្មិត sa-external-services សម្រាប់សេវាកម្ម sa-frontendនឹងត្រូវបានបញ្ជូនបន្តទៅកាន់គ្រប់ករណីរបស់វា ហើយបន្ទុកនឹងត្រូវបានចែកចាយតាមរយៈ ក្បួនដោះស្រាយវិលជុំដែលនឹងនាំឱ្យមានស្ថានភាពដូចខាងក្រោមៈ

រកមិនឃើញឯកសារដែលបានស្នើសុំទេ។

ឯកសារទាំងនេះមិនត្រូវបានរកឃើញទេ ដោយសារពួកវាត្រូវបានដាក់ឈ្មោះខុសគ្នានៅក្នុងកំណែផ្សេងៗគ្នានៃកម្មវិធី។ ចូរ​ធ្វើ​ឱ្យ​ប្រាកដ​ថា​នេះ​:

$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.c7071b22.css
/static/js/main.059f8e9c.js
$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.f87cd8c9.css
/static/js/main.f7659dbb.js

វាមានន័យថា index.htmlការស្នើសុំកំណែមួយនៃឯកសារឋិតិវន្ត អាចត្រូវបានផ្ញើដោយឧបករណ៍ផ្ទុកតុល្យភាពទៅកាន់ផតដែលមានកំណែផ្សេងគ្នា ដែលសម្រាប់ហេតុផលជាក់ស្តែង ឯកសារបែបនេះមិនមានទេ។ ដូច្នេះ ដើម្បី​ឱ្យ​កម្មវិធី​ដំណើរការ​បាន យើង​ត្រូវ​កំណត់​ការ​រឹតត្បិត៖ "កំណែដូចគ្នានៃកម្មវិធីដែលបានបម្រើ index.html គួរតែបម្រើសំណើជាបន្តបន្ទាប់"។

យើងនឹងទៅដល់ទីនោះជាមួយនឹងសមតុល្យបន្ទុកដែលមានមូលដ្ឋានលើ hash (ការរក្សាតុល្យភាព Hash ជាប់លាប់)... ក្នុងករណី​នេះ សំណើ​ពី​អតិថិជន​ដូចគ្នា​ត្រូវ​បាន​ផ្ញើ​ទៅ​វត្ថុ​ខាងក្រោយ​ដូចគ្នា។ដែលទ្រព្យសម្បត្តិដែលបានកំណត់ជាមុនត្រូវបានប្រើ - ឧទាហរណ៍ បឋមកថា HTTP ។ បានអនុវត្តដោយប្រើ DestinationRules ។

គោលការណ៍​គោលដៅ

បន្ទាប់ពី សេវានិម្មិត បានផ្ញើសំណើទៅកាន់សេវាកម្មដែលចង់បាន ដោយប្រើ DestinationRules យើងអាចកំណត់គោលការណ៍ដែលនឹងត្រូវបានអនុវត្តចំពោះចរាចរណ៍ដែលបានកំណត់សម្រាប់ឧទាហរណ៍នៃសេវាកម្មនេះ៖

ការគ្រប់គ្រងចរាចរណ៍ជាមួយធនធាន Istio

ការកត់សម្គាល់៖ ផលប៉ះពាល់នៃធនធាន Istio លើចរាចរណ៍បណ្តាញត្រូវបានបង្ហាញនៅទីនេះតាមរបៀបដែលងាយយល់។ ដើម្បីឱ្យមានភាពច្បាស់លាស់ ការសម្រេចចិត្តលើករណីណាដែលត្រូវផ្ញើសំណើទៅគឺធ្វើឡើងដោយបេសកជននៅក្នុងច្រកទ្វារចូលដែលបានកំណត់រចនាសម្ព័ន្ធនៅក្នុង CRD ។

ជាមួយនឹងច្បាប់កំណត់គោលដៅ យើងអាចកំណត់រចនាសម្ព័ន្ធការផ្ទុកបន្ទុក ដើម្បីប្រើសញ្ញាដែលជាប់គ្នា និងធានាថាសេវាកម្មដូចគ្នាឆ្លើយតបចំពោះអ្នកប្រើប្រាស់ដូចគ្នា។ ការកំណត់រចនាសម្ព័ន្ធខាងក្រោមអនុញ្ញាតឱ្យអ្នកសម្រេចបាននូវចំណុចនេះ (destinationrule-sa-frontend.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-frontend
spec:
  host: sa-frontend
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: version   # 1

1 - hash នឹងត្រូវបានបង្កើតដោយផ្អែកលើមាតិកានៃបឋមកថា HTTP version.

អនុវត្តការកំណត់រចនាសម្ព័ន្ធដោយប្រើពាក្យបញ្ជាខាងក្រោម៖

$ kubectl apply -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io/sa-frontend created

ឥឡូវនេះដំណើរការពាក្យបញ្ជាខាងក្រោមហើយត្រូវប្រាកដថាអ្នកទទួលបានឯកសារត្រឹមត្រូវនៅពេលអ្នកបញ្ជាក់បឋមកថា version:

$ curl --silent -H "version: yogo" http://$EXTERNAL_IP/ | tr '"' 'n' | grep main

ការកត់សម្គាល់៖ ដើម្បីបន្ថែមតម្លៃផ្សេងគ្នានៅក្នុងបឋមកថា និងសាកល្បងលទ្ធផលដោយផ្ទាល់នៅក្នុងកម្មវិធីរុករក អ្នកអាចប្រើ ផ្នែកបន្ថែមនេះ។ ទៅ Chrome (ឬ ជាមួយនេះ។ សម្រាប់ Firefox - ប្រហែល។ បកប្រែ។ ).

ជាទូទៅ DestinationRules មានសមត្ថភាពកាន់តែច្រើននៅក្នុងតំបន់នៃតុល្យភាពបន្ទុក - ពិនិត្យមើលព័ត៌មានលម្អិតនៅក្នុង ឯកសារផ្លូវការ.

មុននឹងសិក្សា VirtualService បន្ថែមទៀត សូមលុប "កំណែពណ៌បៃតង" នៃកម្មវិធី និងច្បាប់ទិសដៅចរាចរណ៍ដែលត្រូវគ្នា ដោយដំណើរការពាក្យបញ្ជាខាងក្រោម៖

$ kubectl delete -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions “sa-frontend-green” deleted
$ kubectl delete -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io “sa-frontend” deleted

ការឆ្លុះបញ្ចាំង៖ សេវាកម្មនិម្មិតក្នុងការអនុវត្ត

ការដាក់ស្រមោល ("ការការពារ") ឬការឆ្លុះបញ្ចាំង ("កញ្ចក់") ប្រើក្នុងករណីដែលយើងចង់សាកល្បងការផ្លាស់ប្តូរផលិតកម្មដោយមិនប៉ះពាល់ដល់អ្នកប្រើប្រាស់ចុងក្រោយ៖ ដើម្បីធ្វើដូច្នេះ យើងស្ទួន ("កញ្ចក់") សំណើទៅករណីទីពីរដែលការផ្លាស់ប្តូរដែលចង់បានត្រូវបានធ្វើឡើង ហើយពិនិត្យមើលផលវិបាក។ និយាយឱ្យសាមញ្ញ នេះគឺជាពេលដែលសហសេវិករបស់អ្នកជ្រើសរើសបញ្ហាសំខាន់បំផុត ហើយធ្វើការស្នើសុំទាញក្នុងទម្រង់នៃភាពកខ្វក់ដ៏ធំដែលគ្មាននរណាម្នាក់អាចពិនិត្យមើលវាបានទេ។

ដើម្បីសាកល្បងសេណារីយ៉ូនេះនៅក្នុងសកម្មភាព ចូរយើងបង្កើតឧទាហរណ៍ទីពីរនៃ SA-Logic ជាមួយនឹងកំហុស (buggy) ដោយដំណើរការពាក្យបញ្ជាខាងក្រោម៖

$ kubectl apply -f resource-manifests/kube/shadowing/sa-logic-service-buggy.yaml
deployment.extensions/sa-logic-buggy created

ហើយ​ឥឡូវ​នេះ​សូម​រត់​ពាក្យ​បញ្ជា​ដើម្បី​ធ្វើ​ឱ្យ​ប្រាកដ​ថា​គ្រប់​ករណី​ជាមួយ app=sa-logic ពួកគេក៏មានស្លាកជាមួយនឹងកំណែដែលត្រូវគ្នាផងដែរ៖

$ kubectl get pods -l app=sa-logic --show-labels
NAME                              READY   LABELS
sa-logic-568498cb4d-2sjwj         2/2     app=sa-logic,version=v1
sa-logic-568498cb4d-p4f8c         2/2     app=sa-logic,version=v1
sa-logic-buggy-76dff55847-2fl66   2/2     app=sa-logic,version=v2
sa-logic-buggy-76dff55847-kx8zz   2/2     app=sa-logic,version=v2

RЎRμSЂRІRёSЃ sa-logic កំណត់គោលដៅ pods ជាមួយស្លាកមួយ។ app=sa-logicដូច្នេះសំណើទាំងអស់នឹងត្រូវបានចែកចាយក្នុងចំណោមករណីទាំងអស់៖

... ប៉ុន្តែយើងចង់ផ្ញើសំណើទៅកាន់ v1 instances ហើយឆ្លុះបញ្ចាំងទៅ v2 instances៖

យើង​នឹង​សម្រេច​បាន​វា​តាម​រយៈ VirtualService ដោយ​រួម​បញ្ចូល​គ្នា​ជាមួយ DestinationRule ដែល​ច្បាប់​នឹង​កំណត់​សំណុំ​រង និង​ផ្លូវ​នៃ VirtualService ទៅ​សំណុំ​រង​ជាក់លាក់។

ការកំណត់ផ្នែករងនៅក្នុងច្បាប់គោលដៅ

សំណុំរង (សំណុំរង) ត្រូវបានកំណត់ដោយការកំណត់ដូចខាងក្រោម (sa-logic-subsets-destinationrule.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-logic
spec:
  host: sa-logic    # 1
  subsets:
  - name: v1        # 2
    labels:
      version: v1   # 3
  - name: v2
    labels:
      version: v2

1. ម្ចាស់ផ្ទះ (host) កំណត់ថាច្បាប់នេះអនុវត្តចំពោះតែករណីនៅពេលដែលផ្លូវទៅកាន់សេវាកម្ម sa-logic;
2. ចំណងជើង (name) សំណុំរងត្រូវបានប្រើនៅពេលបញ្ជូនទៅកាន់វត្ថុសំណុំរង។
3. ស្លាក​សញ្ញា (label) កំណត់គូតម្លៃ key-value ដែល instances ត្រូវតែផ្គូផ្គង ដើម្បីក្លាយជាផ្នែកមួយនៃសំណុំរង។

អនុវត្តការកំណត់រចនាសម្ព័ន្ធដោយប្រើពាក្យបញ្ជាខាងក្រោម៖

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-destinationrule.yaml
destinationrule.networking.istio.io/sa-logic created

ឥឡូវ​នេះ​សំណុំ​រង​ត្រូវ​បាន​កំណត់ យើង​អាច​បន្ត​ទៅ​មុខ និង​កំណត់​រចនាសម្ព័ន្ធ VirtualService ដើម្បី​អនុវត្ត​ច្បាប់​ចំពោះ​សំណើ​ទៅ sa-logic ដូច្នេះ​ពួក​វា៖

1. បានបញ្ជូនទៅកាន់ផ្នែករងមួយ។ v1,
2. ឆ្លុះទៅផ្នែករង v2.

ការបង្ហាញខាងក្រោមអនុញ្ញាតឱ្យអ្នកសម្រេចបាននូវផែនការរបស់អ្នក (sa-logic-subsets-shadowing-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic          
  http:
  - route:
    - destination:
        host: sa-logic  
        subset: v1      
    mirror:             
      host: sa-logic     
      subset: v2

មិនចាំបាច់មានការពន្យល់នៅទីនេះទេ ដូច្នេះសូមមើលវានៅក្នុងសកម្មភាព៖

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-shadowing-vs.yaml
virtualservice.networking.istio.io/sa-logic created

តោះបន្ថែមបន្ទុកដោយហៅពាក្យបញ្ជាខាងក្រោម៖

$ while true; do curl -v http://$EXTERNAL_IP/sentiment 
    -H "Content-type: application/json" 
    -d '{"sentence": "I love yogobella"}'; 
    sleep .8; done

សូមក្រឡេកមើលលទ្ធផលនៅក្នុង Grafana ដែលអ្នកអាចមើលឃើញថាកំណែដែលមានកំហុស (buggy) បណ្តាលឱ្យបរាជ័យសម្រាប់ ~60% នៃសំណើ ប៉ុន្តែគ្មានការបរាជ័យទាំងនេះប៉ះពាល់ដល់អ្នកប្រើប្រាស់ចុងក្រោយ ដូចដែលពួកគេត្រូវបានឆ្លើយតបដោយសេវាកម្មដែលកំពុងដំណើរការនោះទេ។

ការឆ្លើយតបដោយជោគជ័យនៃកំណែផ្សេងគ្នានៃសេវាកម្ម sa-logic

នៅទីនេះដំបូងយើងឃើញពីរបៀបដែលសេវាកម្ម VirtualService ត្រូវបានអនុវត្តចំពោះបេសកជននៃសេវាកម្មរបស់យើង៖ ពេលណា sa-web-app ធ្វើសំណើទៅ sa-logicវាទៅតាមរយៈ sidecar Envoy ដែល - តាមរយៈ VirtualService - ត្រូវបានកំណត់រចនាសម្ព័ន្ធដើម្បីបញ្ជូនសំណើទៅសំណុំរង v1 និងឆ្លុះបញ្ចាំងសំណើទៅសំណុំរង v2 នៃសេវាកម្ម sa-logic.

ខ្ញុំដឹង អ្នកប្រហែលជាគិតរួចហើយថាសេវាកម្មនិម្មិតគឺសាមញ្ញ។ នៅក្នុងផ្នែកបន្ទាប់ យើងនឹងពង្រីកវាដោយនិយាយថាពួកគេពិតជាអស្ចារ្យផងដែរ។

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

Canary Deployment គឺជាដំណើរការនៃការដាក់ចេញនូវកំណែថ្មីនៃកម្មវិធីមួយទៅកាន់អ្នកប្រើប្រាស់មួយចំនួនតូច។ វា​ត្រូវ​បាន​ប្រើ​ដើម្បី​ធ្វើ​ឱ្យ​ប្រាកដ​ថា​មិន​មាន​បញ្ហា​អ្វី​នៅ​ក្នុង​ការ​ចេញ​ផ្សាយ ហើយ​បន្ទាប់​ពី​នោះ​ដោយ​មាន​ទំនុក​ចិត្ត​លើ​គុណភាព (ការ​ចេញ​ផ្សាយ) របស់​វា រួច​ហើយ​ចែកចាយ​វា​ទៅ​អ្នក​ប្រើ​ផ្សេង​ទៀត។оទស្សនិកជនធំជាង។

ដើម្បីបង្ហាញពីការបើកដំណើរការ Canary យើងនឹងបន្តធ្វើការជាមួយសំណុំរងមួយ។ buggy у sa-logic.

កុំខ្ជះខ្ជាយពេលវេលាលើរឿងតូចតាច ហើយផ្ញើភ្លាមៗ 20% នៃអ្នកប្រើប្រាស់ទៅកាន់កំណែដែលមានកំហុស (វានឹងតំណាងឱ្យការដំណើរការ Canary របស់យើង) ហើយ 80% ទៀតទៅសេវាកម្មធម្មតា។ ដើម្បីធ្វើដូច្នេះ សូមប្រើ VirtualService ខាងក្រោម (sa-logic-subsets-canary-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic    
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 80         # 1
    - destination: 
        host: sa-logic
        subset: v2
      weight: 20 # 1

1 គឺជាទម្ងន់ (weight) ដែលបញ្ជាក់ពីភាគរយនៃសំណើដែលនឹងត្រូវបញ្ជូនទៅអ្នកទទួល ឬក្រុមរងនៃអ្នកទទួល។

តោះធ្វើបច្ចុប្បន្នភាពការកំណត់រចនាសម្ព័ន្ធ VirtualService ពីមុនសម្រាប់ sa-logic ជាមួយនឹងពាក្យបញ្ជាដូចខាងក្រោមៈ

$ kubectl apply -f resource-manifests/istio/canary/sa-logic-subsets-canary-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

... ហើយយើងនឹងឃើញភ្លាមៗថា សំណើមួយចំនួននាំទៅរកការបរាជ័យ៖

$ while true; do 
   curl -i http://$EXTERNAL_IP/sentiment 
   -H "Content-type: application/json" 
   -d '{"sentence": "I love yogobella"}' 
   --silent -w "Time: %{time_total}s t Status: %{http_code}n" 
   -o /dev/null; sleep .1; done
Time: 0.153075s Status: 200
Time: 0.137581s Status: 200
Time: 0.139345s Status: 200
Time: 30.291806s Status: 500

VirtualServices បើកដំណើរការ Canary rollouts៖ ក្នុងករណីនេះ យើងបានបង្រួមផលប៉ះពាល់សក្តានុពលនៃបញ្ហាមកត្រឹម 20% នៃអ្នកប្រើប្រាស់។ អស្ចារ្យមែន! ឥឡូវនេះ ក្នុងគ្រប់ករណីទាំងអស់ នៅពេលដែលយើងមិនប្រាកដអំពីកូដរបស់យើង (និយាយម្យ៉ាងទៀត - ជានិច្ចកាល...) យើងអាចប្រើការឆ្លុះ និង Canary rollouts ។

អស់ពេល និងព្យាយាមម្តងទៀត

ប៉ុន្តែកំហុសមិនតែងតែបញ្ចប់នៅក្នុងកូដនោះទេ។ នៅក្នុងបញ្ជីពី "8 ការយល់ខុសអំពីកុំព្យូទ័រចែកចាយ"ដំបូងបង្អស់គឺជំនឿខុសដែលថា "បណ្តាញអាចទុកចិត្តបាន" ។ តាមពិតបណ្តាញ មិនមាន អាចទុកចិត្តបាន ហើយសម្រាប់ហេតុផលនេះ យើងត្រូវការពេលវេលាអស់ពេល (អស់ពេល) និងព្យាយាមម្តងទៀត (ព្យាយាមម្តងទៀត).

សម្រាប់ការបង្ហាញ យើងនឹងបន្តប្រើកំណែបញ្ហាដដែល sa-logic (buggy) ហើយយើងនឹងក្លែងធ្វើភាពមិនគួរឱ្យទុកចិត្តនៃបណ្តាញជាមួយនឹងការបរាជ័យចៃដន្យ។

អនុញ្ញាតឱ្យសេវាកម្មរបស់យើងដែលមានកំហុសមានឱកាស 1/3 ក្នុងការឆ្លើយតបយូរពេក ឱកាស 1/3 នៃការបញ្ចប់ដោយកំហុសម៉ាស៊ីនមេខាងក្នុង និង 1/3 ឱកាសនៃការត្រឡប់ទំព័រដោយជោគជ័យ។

ដើម្បីកាត់បន្ថយផលប៉ះពាល់នៃបញ្ហាបែបនេះ និងធ្វើឱ្យជីវិតកាន់តែប្រសើរឡើងសម្រាប់អ្នកប្រើប្រាស់ យើងអាច៖

1. បន្ថែមការអស់ពេល ប្រសិនបើសេវាកម្មចំណាយពេលលើសពី 8 វិនាទីដើម្បីឆ្លើយតប
2. ព្យាយាមម្តងទៀតប្រសិនបើសំណើបរាជ័យ។

សម្រាប់ការអនុវត្ត យើងនឹងប្រើនិយមន័យធនធានខាងក្រោម (sa-logic-retries-timeouts-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 50
    - destination: 
        host: sa-logic
        subset: v2
      weight: 50
    timeout: 8s           # 1
    retries:
      attempts: 3         # 2
      perTryTimeout: 3s # 3

1. ការអស់ពេលសម្រាប់ការស្នើសុំត្រូវបានកំណត់ទៅ 8 វិនាទី;
2. សំណើត្រូវបានព្យាយាមម្តងទៀត 3 ដង;
3. ហើយការប៉ុនប៉ងនីមួយៗត្រូវបានចាត់ទុកថាមិនជោគជ័យ ប្រសិនបើពេលវេលាឆ្លើយតបលើសពី 3 វិនាទី។

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

អនុវត្តការកំណត់រចនាសម្ព័ន្ធដែលបានធ្វើបច្ចុប្បន្នភាពដោយប្រើពាក្យបញ្ជាខាងក្រោម៖

$ kubectl apply -f resource-manifests/istio/retries/sa-logic-retries-timeouts-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

ហើយពិនិត្យមើលក្រាហ្វ Grafana ដែលចំនួននៃការឆ្លើយតបជោគជ័យបានកើនឡើងខាងលើ៖

ការកែលម្អស្ថិតិឆ្លើយតបដោយជោគជ័យ បន្ទាប់ពីបន្ថែមការអស់ពេល និងការព្យាយាមម្តងទៀត

មុនពេលបន្តទៅផ្នែកបន្ទាប់ (ឬផ្ទុយទៅវិញ ទៅផ្នែកបន្ទាប់នៃអត្ថបទ ពីព្រោះនៅក្នុងនេះនឹងមិនមានការពិសោធន៍ជាក់ស្តែងទៀតទេ - ប្រហែលបកប្រែ។ ), លុប sa-logic-buggy និង VirtualService ដោយដំណើរការពាក្យបញ្ជាខាងក្រោម៖

$ kubectl delete deployment sa-logic-buggy
deployment.extensions “sa-logic-buggy” deleted
$ kubectl delete virtualservice sa-logic
virtualservice.networking.istio.io “sa-logic” deleted

ឧបករណ៍បំលែងសៀគ្វី និងគំរូក្បាលគ្រាប់

យើងកំពុងនិយាយអំពីគំរូសំខាន់ពីរនៅក្នុងស្ថាបត្យកម្មមីក្រូសេវាកម្មដែលអនុញ្ញាតឱ្យអ្នកសម្រេចបាននូវការងើបឡើងវិញដោយខ្លួនឯង។ (ការព្យាបាលដោយខ្លួនឯង) សេវាកម្ម។

អ្នកបំបែកសៀគ្វី ("ឧបករណ៍បំបែកសៀគ្វី") ប្រើដើម្បីបញ្ចប់សំណើដែលចូលមកក្នុងឧទាហរណ៍នៃសេវាកម្មដែលត្រូវបានចាត់ទុកថាមិនល្អ ហើយស្ដារវាឡើងវិញ ខណៈដែលសំណើរបស់អតិថិជនត្រូវបានបញ្ជូនបន្តទៅកាន់ករណីដែលមានសុខភាពល្អនៃសេវាកម្មនោះ (ដែលបង្កើនភាគរយនៃការឆ្លើយតបដែលជោគជ័យ)។ (ចំណាំ៖ ការពិពណ៌នាលម្អិតបន្ថែមទៀតនៃគំរូអាចត្រូវបានរកឃើញឧទាហរណ៍។ នៅទីនេះ.)

សំពីងសំពោង ("ភាគថាស") ផ្តាច់ការបរាជ័យនៃសេវាកម្មពីការប៉ះពាល់ដល់ប្រព័ន្ធទាំងមូល។ ឧទាហរណ៍ សេវា B ត្រូវបានខូច ហើយសេវាកម្មផ្សេងទៀត (អតិថិជនរបស់សេវាកម្ម B) ធ្វើសំណើទៅសេវាកម្ម B ដែលបណ្តាលឱ្យវាអស់កំលាំង និងមិនអាចផ្តល់សេវាសំណើផ្សេងទៀតបានទេ (ទោះបីជាវាមិនមែនមកពីសេវាកម្ម B)។ (ចំណាំ៖ ការពិពណ៌នាលម្អិតបន្ថែមទៀតនៃគំរូអាចត្រូវបានរកឃើញឧទាហរណ៍។ នៅទីនេះ.)

ខ្ញុំនឹងលុបចោលព័ត៌មានលម្អិតនៃការអនុវត្តនៃគំរូទាំងនេះ ព្រោះវាងាយស្រួលរក ឯកសារផ្លូវការហើយខ្ញុំក៏ចង់បង្ហាញការផ្ទៀងផ្ទាត់ និងការអនុញ្ញាតផងដែរ ដែលនឹងត្រូវបានពិភាក្សានៅក្នុងផ្នែកបន្ទាប់នៃអត្ថបទ។

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

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

• "ត្រលប់ទៅសេវាកម្មខ្នាតតូចជាមួយ Istio"៖ ផ្នែកទី 1 (ការណែនាំអំពីលក្ខណៈសំខាន់ៗ), ផ្នែកទី 3 (ការផ្ទៀងផ្ទាត់ និងការអនុញ្ញាត);
• «បំពង់ - សំណាញ់សេវាទម្ងន់ស្រាលសម្រាប់ Kubernetes»
• «តើអ្វីទៅជាសេវាសំណាញ់ ហើយហេតុអ្វីបានជាខ្ញុំត្រូវការ [សម្រាប់កម្មវិធីពពកជាមួយមីក្រូសឺវីស]?"។

ប្រភព: www.habr.com