ស្តង់ដារការប្រើប្រាស់ស៊ីភីយូសម្រាប់ Istio និង Linkerd

សេចក្តីណែនាំ

យើង​ស្ថិត​នៅ​ក្នុង Shopify បានចាប់ផ្តើមដាក់ពង្រាយ Istio ជាបណ្តាញសេវា។ ជាគោលការណ៍ អ្វីៗគឺល្អ លើកលែងតែរឿងមួយ៖ វា​មាន​តម្លៃ​ថ្លៃ.

В ស្តង់ដារដែលបានបោះពុម្ពផ្សាយ សម្រាប់ Istio វានិយាយថា:

ជាមួយនឹង Istio 1.1 ប្រូកស៊ីប្រើប្រាស់ប្រហែល 0,6 vCPUs (ស្នូលនិម្មិត) ក្នុង 1000 សំណើក្នុងមួយវិនាទី។

សម្រាប់តំបន់ទីមួយនៅក្នុងបណ្តាញសេវា (ប្រូកស៊ី 2 នៅផ្នែកម្ខាងនៃការតភ្ជាប់) យើងនឹងមាន 1200 ស្នូលសម្រាប់ប្រូកស៊ី ក្នុងអត្រាមួយលានសំណើក្នុងមួយវិនាទី។ យោងតាមការគណនាតម្លៃរបស់ Google វាដំណើរការប្រហែល $40/month/core សម្រាប់ការកំណត់រចនាសម្ព័ន្ធ n1-standard-64នោះគឺតំបន់នេះតែមួយនឹងធ្វើឱ្យយើងចំណាយច្រើនជាង 50 ពាន់ដុល្លារក្នុងមួយខែសម្រាប់សំណើ 1 លានក្នុងមួយវិនាទី។

អ៊ីវ៉ាន ស៊ីម (អ៊ីវ៉ានស៊ីម) ប្រៀបធៀបដោយមើលឃើញ service mesh បានពន្យារពេលកាលពីឆ្នាំមុន ហើយបានសន្យាដូចគ្នាសម្រាប់ memory និង processor ប៉ុន្តែវាមិនដំណើរការទេ៖

ជាក់ស្តែង តម្លៃ-istio-test.yaml នឹងបង្កើនសំណើស៊ីភីយូយ៉ាងធ្ងន់ធ្ងរ។ ប្រសិនបើខ្ញុំធ្វើគណិតវិទ្យាបានត្រឹមត្រូវ អ្នកត្រូវការស្នូលស៊ីភីយូប្រហែល 24 សម្រាប់ផ្ទាំងបញ្ជា និង 0,5 ស៊ីភីយូសម្រាប់ប្រូកស៊ីនីមួយៗ។ ខ្ញុំមិនមានច្រើននោះទេ។ ខ្ញុំនឹងធ្វើតេស្តម្តងទៀត នៅពេលដែលធនធានកាន់តែច្រើនត្រូវបានបែងចែកឱ្យខ្ញុំ។

ខ្ញុំ​ចង់​ឃើញ​ខ្លួន​ឯង​ថា​តើ​ការ​អនុវត្ត​របស់ Istio ស្រដៀង​គ្នា​នឹង​បណ្តាញ​សេវា​ប្រភព​បើក​ចំហ​មួយ​ទៀត​យ៉ាង​ណា៖ តំណភ្ជាប់.

ការដំឡើងសំណាញ់សេវាកម្ម

ជាដំបូងខ្ញុំបានដំឡើងវានៅក្នុងចង្កោម SuperGloo:

$ supergloo init
installing supergloo version 0.3.12
using chart uri https://storage.googleapis.com/supergloo-helm/charts/supergloo-0.3.12.tgz
configmap/sidecar-injection-resources created
serviceaccount/supergloo created
serviceaccount/discovery created
serviceaccount/mesh-discovery created
clusterrole.rbac.authorization.k8s.io/discovery created
clusterrole.rbac.authorization.k8s.io/mesh-discovery created
clusterrolebinding.rbac.authorization.k8s.io/supergloo-role-binding created
clusterrolebinding.rbac.authorization.k8s.io/discovery-role-binding created
clusterrolebinding.rbac.authorization.k8s.io/mesh-discovery-role-binding created
deployment.extensions/supergloo created
deployment.extensions/discovery created
deployment.extensions/mesh-discovery created
install successful!

ខ្ញុំបានប្រើ SuperGloo ព្រោះវាធ្វើឱ្យ bootstrapping សេវាងាយស្រួលជាង។ ខ្ញុំមិនចាំបាច់ធ្វើអ្វីច្រើនទេ។ យើងមិនប្រើ SuperGloo ក្នុងការផលិតទេ ប៉ុន្តែវាល្អសម្រាប់ការងារបែបនេះ។ ខ្ញុំ​ត្រូវ​ប្រើ​ពាក្យ​បញ្ជា​ពីរ​បី​ឃ្លា​សម្រាប់​សេវាកម្ម​នីមួយៗ។ ខ្ញុំបានប្រើចង្កោមពីរសម្រាប់ភាពឯកោ - មួយសម្រាប់ Istio និង Linkerd ។

ការពិសោធន៍ត្រូវបានធ្វើឡើងនៅលើ Google Kubernetes Engine ។ ខ្ញុំបានប្រើ Kubernetes 1.12.7-gke.7 និងក្រុមថ្នាំង n1-standard-4 ជាមួយនឹងការធ្វើមាត្រដ្ឋានថ្នាំងដោយស្វ័យប្រវត្តិ (អប្បបរមា 4 អតិបរមា 16) ។

បន្ទាប់មកខ្ញុំបានដំឡើងសេវា Meshes ទាំងពីរពីបន្ទាត់ពាក្យបញ្ជា។

អ្នកភ្ជាប់ដំបូង៖

$ supergloo install linkerd --name linkerd
+---------+--------------+---------+---------------------------+
| INSTALL |     TYPE     | STATUS  |          DETAILS          |
+---------+--------------+---------+---------------------------+
| linkerd | Linkerd Mesh | Pending | enabled: true             |
|         |              |         | version: stable-2.3.0     |
|         |              |         | namespace: linkerd        |
|         |              |         | mtls enabled: true        |
|         |              |         | auto inject enabled: true |
+---------+--------------+---------+---------------------------+

បន្ទាប់មក Istio៖

$ supergloo install istio --name istio --installation-namespace istio-system --mtls=true --auto-inject=true
+---------+------------+---------+---------------------------+
| INSTALL |    TYPE    | STATUS  |          DETAILS          |
+---------+------------+---------+---------------------------+
| istio   | Istio Mesh | Pending | enabled: true             |
|         |            |         | version: 1.0.6            |
|         |            |         | namespace: istio-system   |
|         |            |         | mtls enabled: true        |
|         |            |         | auto inject enabled: true |
|         |            |         | grafana enabled: true     |
|         |            |         | prometheus enabled: true  |
|         |            |         | jaeger enabled: true      |
+---------+------------+---------+---------------------------+

រង្វិលជុំគាំងបានចំណាយពេលពីរបីនាទី ហើយបន្ទាប់មកផ្ទាំងបញ្ជាមានស្ថេរភាព។

(ចំណាំ៖ SuperGloo គាំទ្រតែ Istio 1.0.x ប៉ុណ្ណោះសម្រាប់ពេលនេះ។ ខ្ញុំបានធ្វើការពិសោធន៍ម្តងទៀតជាមួយ Istio 1.1.3 ប៉ុន្តែមិនបានកត់សម្គាល់ពីភាពខុសគ្នាគួរឱ្យកត់សម្គាល់នោះទេ។)

ការដំឡើង Istio ការដាក់ឱ្យប្រើប្រាស់ដោយស្វ័យប្រវត្តិ

ដើម្បីធ្វើឱ្យ Istio ដំឡើង sidecar Envoy យើងប្រើ sidecar injector − MutatingAdmissionWebhook. យើងនឹងមិននិយាយអំពីវានៅក្នុងអត្ថបទនេះទេ។ ខ្ញុំគ្រាន់តែនិយាយថានេះគឺជាឧបករណ៍បញ្ជាដែលត្រួតពិនិត្យការចូលប្រើផតថលថ្មីទាំងអស់ ហើយបន្ថែមថាមវន្ត sidecar និង initContainer ដែលទទួលខុសត្រូវចំពោះកិច្ចការ។ iptables.

យើងនៅ Shopify បានសរសេរឧបករណ៍បញ្ជាការចូលដំណើរការផ្ទាល់ខ្លួនរបស់យើងដើម្បីអនុវត្តរថយន្តចំហៀង ប៉ុន្តែសម្រាប់ស្តង់ដារនេះ ខ្ញុំបានប្រើឧបករណ៍បញ្ជាដែលភ្ជាប់មកជាមួយ Istio ។ ឧបករណ៍បញ្ជាចាក់ថ្នាំចំហៀងតាមលំនាំដើម នៅពេលដែលមានផ្លូវកាត់ក្នុងចន្លោះឈ្មោះ istio-injection: enabled:

$ kubectl label namespace irs-client-dev istio-injection=enabled
namespace/irs-client-dev labeled

$ kubectl label namespace irs-server-dev istio-injection=enabled
namespace/irs-server-dev labeled

រៀបចំការដាក់ឱ្យប្រើប្រាស់ Linkerd ដោយស្វ័យប្រវត្តិ

ដើម្បីដំឡើងការបង្កប់ Linkerd sidecar យើងប្រើចំណារពន្យល់ (ខ្ញុំបានបន្ថែមវាដោយដៃតាមរយៈ kubectl edit):

metadata:
  annotations:
    linkerd.io/inject: enabled

$ k edit ns irs-server-dev 
namespace/irs-server-dev edited

$ k get ns irs-server-dev -o yaml
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    linkerd.io/inject: enabled
  name: irs-server-dev
spec:
  finalizers:
  - kubernetes
status:
  phase: Active

Istio Fault Tolerance Simulator

យើងបានបង្កើតកម្មវិធីត្រាប់តាមកំហុសដែលហៅថា Istio ដើម្បីសាកល្បងជាមួយនឹងចរាចរណ៍តែមួយគត់ចំពោះ Shopify ។ យើងត្រូវការឧបករណ៍ដើម្បីបង្កើត topology ផ្ទាល់ខ្លួន ដែលនឹងតំណាងឱ្យផ្នែកជាក់លាក់នៃក្រាហ្វសេវាកម្មរបស់យើង ដែលត្រូវបានកំណត់រចនាសម្ព័ន្ធថាមវន្តដើម្បីធ្វើគំរូនៃបន្ទុកការងារជាក់លាក់។

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

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

នៅក្នុងបេះដូងនៃម៉ាស៊ីនក្លែងធ្វើការអត់ឱនកំហុសគឺជាថ្នាំងកម្មករដែលដើរតួជាថ្នាំងសំណាញ់សេវាកម្ម។ ថ្នាំងកម្មករអាចត្រូវបានកំណត់រចនាសម្ព័ន្ធថេរនៅពេលចាប់ផ្តើមឬថាមវន្តតាមរយៈ REST API ។ យើងប្រើការកំណត់រចនាសម្ព័ន្ធថាមវន្តនៃថ្នាំងកម្មករដើម្បីបង្កើតលំហូរការងារក្នុងទម្រង់នៃការធ្វើតេស្តតំរែតំរង់។

នេះគឺជាឧទាហរណ៍នៃដំណើរការបែបនេះ៖

• យើងបើកដំណើរការ 10 servers as bar សេវាកម្មដែលផ្តល់ការឆ្លើយតប 200/OK បន្ទាប់ពី 100 ms ។
• យើងបើកដំណើរការអតិថិជន 10 នាក់ - ម្នាក់ៗផ្ញើសំណើ 100 ក្នុងមួយវិនាទីទៅ bar.
• រៀងរាល់ 10 វិនាទី យើងលុបម៉ាស៊ីនមេ 1 និងត្រួតពិនិត្យកំហុស 5xx លើអតិថិជន។

នៅចុងបញ្ចប់នៃដំណើរការការងារ យើងពិនិត្យមើលកំណត់ហេតុ និងរង្វាស់ ហើយពិនិត្យមើលថាតើការធ្វើតេស្តបានឆ្លងកាត់ដែរឬទេ។ វិធីនេះយើងរៀនអំពីដំណើរការនៃសេវាសំណាញ់របស់យើង និងដំណើរការការធ្វើតេស្តតំរែតំរង់ដើម្បីសាកល្បងការសន្មត់របស់យើងអំពីការអត់ឱនកំហុស។

(ចំណាំ៖ យើងកំពុងគិតអំពីប្រភពបើកចំហនៃម៉ាស៊ីនពិសោធភាពអត់ធ្មត់ Istio ប៉ុន្តែមិនទាន់រួចរាល់ដើម្បីធ្វើដូច្នេះនៅឡើយទេ។ )

Istio fault tolerance simulator សម្រាប់សេវាកម្ម​ mesh benchmark

យើងរៀបចំថ្នាំងធ្វើការជាច្រើននៃម៉ាស៊ីនក្លែងធ្វើ៖

• irs-client-loadgen៖ ការចម្លងចំនួន 3 ដែលផ្ញើសំណើ 100 ក្នុងមួយវិនាទីក្នុងមួយ irs-client.
• irs-client៖ 3 ច្បាប់ចម្លងដែលទទួលសំណើ រង់ចាំ 100ms ហើយបញ្ជូនសំណើទៅ irs-server.
• irs-server៖ 3 រូបចម្លងដែលត្រឡប់មកវិញ 200/OK បន្ទាប់ពី 100 ms ។

ជាមួយនឹងការកំណត់រចនាសម្ព័ន្ធនេះ យើងអាចវាស់ស្ទង់លំហូរចរាចរណ៍ដែលមានស្ថេរភាពរវាងចំណុចបញ្ចប់ 9 ។ អ្នកជិះក្នុង irs-client-loadgen и irs-server ទទួលបាន 100 សំណើក្នុងមួយវិនាទី irs-client - 200 (ចូលនិងចេញ) ។

យើងតាមដានការប្រើប្រាស់ធនធានតាមរយៈ DataDogដោយសារតែយើងមិនមានចង្កោម Prometheus ។

Результаты

ផ្ទាំងបញ្ជា

ដំបូងយើងពិនិត្យមើលការប្រើប្រាស់ស៊ីភីយូ។

ផ្ទាំងបញ្ជា Linkerd ~ 22 មិល្លីក

ផ្ទាំងបញ្ជា Istio: ~750 millicore

ផ្ទាំងបញ្ជា Istio ប្រើប្រហែល ធនធាន CPU ច្រើនជាង 35 ដងជាង Linkerd ។ ជាការពិតណាស់ អ្វីគ្រប់យ៉ាងត្រូវបានដំឡើងតាមលំនាំដើម ហើយ istio-telemetry ប្រើប្រាស់ធនធានខួរក្បាលជាច្រើននៅទីនេះ (វាអាចត្រូវបានបិទដោយការបិទមុខងារមួយចំនួន)។ ប្រសិនបើយើងដកសមាសភាគនេះចេញ យើងនៅតែទទួលបានច្រើនជាង 100 មិល្លីក ពោលគឺ 4 ដងច្រើនជាងនេះជាង Linkerd ។

ប្រូកស៊ី Sidecar

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

Linkerd៖ ~100 millicores សម្រាប់ irs-client, ~50 millicores សម្រាប់ irs-client-loadgen

លទ្ធផលមើលទៅឡូជីខល ពីព្រោះប្រូកស៊ីអតិថិជនទទួលបានចរាចរណ៍ច្រើនជាងប្រូកស៊ី loadgen ពីរដង៖ សម្រាប់រាល់សំណើដែលចេញមកពី loadgen អតិថិជនមានមួយចូល និងមួយចេញ។

Istio/Envoy: ~155 millicores សម្រាប់ irs-client, ~75 millicores សម្រាប់ irs-client-loadgen

យើង​ឃើញ​លទ្ធផល​ស្រដៀង​គ្នា​នេះ​សម្រាប់ Istio sidecars។

ប៉ុន្តែជាទូទៅ ប្រូកស៊ី Istio/Envoy ប្រើប្រាស់ ប្រហែល 50% ធនធាន CPU បន្ថែមទៀតជាង Linkerd ។

យើងឃើញគ្រោងការណ៍ដូចគ្នានៅផ្នែកខាងម៉ាស៊ីនមេ៖

Linkerd៖ ~50 millicore សម្រាប់ irs-server

Istio/Envoy៖ ~80 millicore សម្រាប់ irs-server

នៅផ្នែកខាងម៉ាស៊ីនមេ ភាគីរថយន្ត Istio/Envoy ប្រើប្រាស់ ប្រហែល 60% ធនធាន CPU បន្ថែមទៀតជាង Linkerd ។

សេចក្តីសន្និដ្ឋាន

ប្រូកស៊ី Istio Envoy ប្រើប្រាស់ស៊ីភីយូ 50+% ច្រើនជាង Linkerd នៅលើបន្ទុកការងារដែលបានក្លែងធ្វើរបស់យើង។ បន្ទះត្រួតពិនិត្យ Linkerd ប្រើប្រាស់ធនធានតិចជាង Istio ជាពិសេសសម្រាប់សមាសធាតុស្នូល។

យើងនៅតែគិតអំពីរបៀបកាត់បន្ថយការចំណាយទាំងនេះ។ បើមានគំនិត សូមជួយចែករំលែកផង!

ប្រភព: www.habr.com