Istio, Linkerd എന്നിവയ്ക്കുള്ള സിപിയു ഉപഭോഗ മാനദണ്ഡം

ആമുഖം

ഞങ്ങൾ അകത്താണ് Shopify ഒരു സേവന മെഷായി ഇസ്തിയോയെ വിന്യസിക്കാൻ തുടങ്ങി. തത്വത്തിൽ, എല്ലാം ശരിയാണ്, ഒരു കാര്യം ഒഴികെ: അത് ചെലവേറിയതാണ്.

В പ്രസിദ്ധീകരിച്ച മാനദണ്ഡങ്ങൾ ഇസ്തിയോയെ സംബന്ധിച്ചിടത്തോളം ഇത് പറയുന്നു:

Istio 1.1 ഉപയോഗിച്ച്, പ്രോക്സി സെക്കൻഡിൽ 0,6 അഭ്യർത്ഥനകൾക്ക് ഏകദേശം 1000 vCPU-കൾ (വെർച്വൽ കോറുകൾ) ഉപയോഗിക്കുന്നു.

സർവീസ് മെഷിലെ ആദ്യ മേഖലയ്ക്കായി (കണക്ഷന്റെ ഓരോ വശത്തും 2 പ്രോക്സികൾ), ഒരു സെക്കൻഡിൽ ഒരു ദശലക്ഷം അഭ്യർത്ഥനകൾ എന്ന നിരക്കിൽ, പ്രോക്സിക്കായി മാത്രം 1200 കോറുകൾ ഞങ്ങൾക്കുണ്ടാകും. Google-ന്റെ കോസ്റ്റ് കാൽക്കുലേറ്റർ അനുസരിച്ച്, കോൺഫിഗറേഷനായി ഇത് ഏകദേശം $40/മാസം/കോർ ആയി പ്രവർത്തിക്കുന്നു n1-standard-64അതായത്, സെക്കൻഡിൽ 50 ദശലക്ഷം അഭ്യർത്ഥനകൾക്കായി ഈ പ്രദേശത്തിന് മാത്രം പ്രതിമാസം 1 ആയിരം ഡോളറിലധികം ചിലവാകും.

ഇവാൻ സിം (ഇവാൻ സിം) ദൃശ്യപരമായി താരതമ്യം ചെയ്യുന്നു സേവന മെഷ് കഴിഞ്ഞ വർഷം കാലതാമസം വരുത്തി, മെമ്മറിക്കും പ്രോസസറിനും ഇത് വാഗ്ദാനം ചെയ്തു, പക്ഷേ അത് പ്രവർത്തിച്ചില്ല:

പ്രത്യക്ഷത്തിൽ, values-istio-test.yaml CPU അഭ്യർത്ഥനകൾ ഗൗരവമായി വർദ്ധിപ്പിക്കും. ഞാൻ എന്റെ കണക്ക് ശരിയായി ചെയ്തിട്ടുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് കൺട്രോൾ പാനലിനായി ഏകദേശം 24 സിപിയു കോറുകളും ഓരോ പ്രോക്സിക്കും 0,5 സിപിയുവും ആവശ്യമാണ്. എനിക്ക് അത്രയൊന്നും ഇല്ല. എനിക്ക് കൂടുതൽ വിഭവങ്ങൾ അനുവദിക്കുമ്പോൾ ഞാൻ പരിശോധനകൾ ആവർത്തിക്കും.

ഇസ്തിയോയുടെ പ്രകടനം മറ്റൊരു ഓപ്പൺ സോഴ്‌സ് സേവന മെഷുമായി എത്രത്തോളം സാമ്യമുള്ളതാണെന്ന് സ്വയം കാണാൻ ഞാൻ ആഗ്രഹിച്ചു: ലിങ്കർഡ്.

സേവന മെഷ് ഇൻസ്റ്റാളേഷൻ

ഒന്നാമതായി, ഞാൻ ഇത് ഒരു ക്ലസ്റ്ററിൽ ഇൻസ്റ്റാൾ ചെയ്തു സൂപ്പർഗ്ലൂ:

$ 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 ഉപയോഗിച്ചു, കാരണം ഇത് സേവന മെഷ് ബൂട്ട്‌സ്ട്രാപ്പുചെയ്യുന്നത് വളരെ എളുപ്പമാക്കുന്നു. എനിക്ക് അധികം ചെയ്യേണ്ടിവന്നില്ല. നിർമ്മാണത്തിൽ ഞങ്ങൾ SuperGloo ഉപയോഗിക്കുന്നില്ല, എന്നാൽ ഇത് അത്തരമൊരു ടാസ്ക്കിന് അനുയോജ്യമാണ്. ഓരോ സേവന മെഷിനും എനിക്ക് അക്ഷരാർത്ഥത്തിൽ രണ്ട് കമാൻഡുകൾ ഉപയോഗിക്കേണ്ടി വന്നു. ഐസൊലേഷനായി ഞാൻ രണ്ട് ക്ലസ്റ്ററുകൾ ഉപയോഗിച്ചു - ഇസ്തിയോയ്ക്കും ലിങ്കർഡിനും ഓരോന്നും.

ഗൂഗിൾ കുബർനെറ്റസ് എഞ്ചിനിലാണ് പരീക്ഷണം നടത്തിയത്. ഞാൻ കുബർനെറ്റസ് ഉപയോഗിച്ചു 1.12.7-gke.7 നോഡുകളുടെ ഒരു കുളവും n1-standard-4 ഓട്ടോമാറ്റിക് നോഡ് സ്കെയിലിംഗിനൊപ്പം (കുറഞ്ഞത് 4, പരമാവധി 16).

കമാൻഡ് ലൈനിൽ നിന്ന് രണ്ട് സേവന മെഷുകളും ഞാൻ ഇൻസ്റ്റാൾ ചെയ്തു.

ആദ്യ ലിങ്കർഡ്:

$ 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 |
+---------+--------------+---------+---------------------------+

അപ്പോൾ ഇസ്തിയോ:

$ 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 ഉപയോഗിച്ചുള്ള പരീക്ഷണം ഞാൻ ആവർത്തിച്ചു, പക്ഷേ ശ്രദ്ധേയമായ വ്യത്യാസമൊന്നും കണ്ടില്ല.)

ഇസ്തിയോ ഓട്ടോമാറ്റിക് വിന്യാസം സജ്ജീകരിക്കുന്നു

ഇസ്തിയോയെ സൈഡ്‌കാർ എൻവോയ് ഇൻസ്റ്റാൾ ചെയ്യാൻ, ഞങ്ങൾ സൈഡ്‌കാർ ഇൻജക്ടർ - ഉപയോഗിക്കുന്നു MutatingAdmissionWebhook. ഈ ലേഖനത്തിൽ ഞങ്ങൾ അതിനെക്കുറിച്ച് സംസാരിക്കില്ല. എല്ലാ പുതിയ പോഡുകളുടേയും ആക്‌സസ് നിരീക്ഷിക്കുകയും ജോലികൾക്ക് ഉത്തരവാദിയായ ഒരു സൈഡ്‌കാറും initContainer-ഉം ചലനാത്മകമായി ചേർക്കുന്ന ഒരു കൺട്രോളറാണ് ഇതെന്ന് ഞാൻ പറയട്ടെ. iptables.

സൈഡ്‌കാറുകൾ നടപ്പിലാക്കാൻ Shopify-യിൽ ഞങ്ങൾ ഞങ്ങളുടെ സ്വന്തം ആക്‌സസ് കൺട്രോളർ എഴുതി, എന്നാൽ ഈ മാനദണ്ഡത്തിനായി ഞാൻ ഇസ്‌റ്റിയോയ്‌ക്കൊപ്പം വരുന്ന കൺട്രോളർ ഉപയോഗിച്ചു. നെയിംസ്‌പെയ്‌സിൽ ഒരു കുറുക്കുവഴി ഉള്ളപ്പോൾ കൺട്രോളർ സൈഡ്‌കാറുകൾ ഡിഫോൾട്ടായി കുത്തിവയ്ക്കുന്നു 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 സൈഡ്‌കാർ ഉൾച്ചേർക്കൽ സജ്ജീകരിക്കുന്നതിന്, ഞങ്ങൾ വ്യാഖ്യാനങ്ങൾ ഉപയോഗിക്കുന്നു (ഞാൻ അവ മുഖേന സ്വമേധയാ ചേർത്തു 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

ഇസ്റ്റിയോ ഫാൾട്ട് ടോളറൻസ് സിമുലേറ്റർ

Shopify-യുടെ തനതായ ട്രാഫിക് പരീക്ഷിക്കുന്നതിനായി ഞങ്ങൾ Istio എന്ന ഒരു തെറ്റ് സഹിഷ്ണുത സിമുലേറ്റർ നിർമ്മിച്ചു. ഞങ്ങളുടെ സേവന ഗ്രാഫിന്റെ ഒരു പ്രത്യേക ഭാഗത്തെ പ്രതിനിധീകരിക്കുന്ന ഒരു ഇഷ്‌ടാനുസൃത ടോപ്പോളജി സൃഷ്‌ടിക്കാൻ ഞങ്ങൾക്ക് ഒരു ടൂൾ ആവശ്യമാണ്, അത് മോഡൽ നിർദ്ദിഷ്ട ജോലിഭാരങ്ങൾക്കായി ഡൈനാമിക് ആയി കോൺഫിഗർ ചെയ്‌തിരിക്കുന്നു.

ഫ്ലാഷ് സെയിൽസ് സമയത്ത് ഷോപ്പിഫൈയുടെ ഇൻഫ്രാസ്ട്രക്ചർ കനത്ത ഭാരത്തിലാണ്. അതേ സമയം, Shopify അത്തരം വിൽപ്പന കൂടുതൽ തവണ നടത്താൻ വിൽപ്പനക്കാരെ ശുപാർശ ചെയ്യുന്നു. വലിയ ഉപഭോക്താക്കൾ ചിലപ്പോൾ പ്ലാൻ ചെയ്ത ഫ്ലാഷ് വിൽപ്പനയെക്കുറിച്ച് മുന്നറിയിപ്പ് നൽകുന്നു. മറ്റുചിലർ പകലിന്റെയോ രാത്രിയുടെയോ ഏത് സമയത്തും ഞങ്ങൾക്ക് അപ്രതീക്ഷിതമായി അവ നടത്തുന്നു.

മുൻകാലങ്ങളിൽ Shopify-യുടെ ഇൻഫ്രാസ്ട്രക്ചറിനെ അതിജീവിച്ച ടോപ്പോളജികളും വർക്ക് ലോഡുകളും പൊരുത്തപ്പെടുന്ന വർക്ക്ഫ്ലോകളെ മാതൃകയാക്കാൻ ഞങ്ങളുടെ റെസിലൻസി സിമുലേറ്റർ ഞങ്ങൾ ആഗ്രഹിച്ചു. ഒരു സർവീസ് മെഷ് ഉപയോഗിക്കുന്നതിന്റെ പ്രധാന ലക്ഷ്യം നെറ്റ്‌വർക്ക് തലത്തിൽ ഞങ്ങൾക്ക് വിശ്വാസ്യതയും തെറ്റ് സഹിഷ്ണുതയും ആവശ്യമാണ്, കൂടാതെ സേവന മെഷ് മുമ്പ് സേവനങ്ങളെ തടസ്സപ്പെടുത്തിയ ലോഡുകളെ ഫലപ്രദമായി നേരിടുന്നത് ഞങ്ങൾക്ക് പ്രധാനമാണ്.

ഫോൾട്ട് ടോളറൻസ് സിമുലേറ്ററിന്റെ ഹൃദയഭാഗത്ത് ഒരു വർക്കർ നോഡാണ്, അത് ഒരു സർവീസ് മെഷ് നോഡായി പ്രവർത്തിക്കുന്നു. വർക്കർ നോഡ് സ്റ്റാർട്ടപ്പിൽ സ്ഥിരമായി അല്ലെങ്കിൽ ഒരു REST API വഴി ചലനാത്മകമായി ക്രമീകരിക്കാൻ കഴിയും. റിഗ്രഷൻ ടെസ്റ്റുകളുടെ രൂപത്തിൽ വർക്ക്ഫ്ലോകൾ സൃഷ്ടിക്കാൻ ഞങ്ങൾ വർക്കർ നോഡുകളുടെ ഡൈനാമിക് കോൺഫിഗറേഷൻ ഉപയോഗിക്കുന്നു.

അത്തരമൊരു പ്രക്രിയയുടെ ഒരു ഉദാഹരണം ഇതാ:

• ഞങ്ങൾ 10 സെർവറുകൾ സമാരംഭിക്കുന്നു bar ഒരു പ്രതികരണം നൽകുന്ന സേവനം 200/OK 100 ms ശേഷം.
• ഞങ്ങൾ 10 ക്ലയന്റുകളെ സമാരംഭിക്കുന്നു - ഓരോന്നും സെക്കൻഡിൽ 100 ​​അഭ്യർത്ഥനകൾ അയയ്ക്കുന്നു bar.
• ഓരോ 10 സെക്കൻഡിലും ഞങ്ങൾ 1 സെർവർ നീക്കം ചെയ്യുകയും പിശകുകൾ നിരീക്ഷിക്കുകയും ചെയ്യുന്നു 5xx ക്ലയന്റിൽ.

വർക്ക്ഫ്ലോയുടെ അവസാനം, ഞങ്ങൾ ലോഗുകളും മെട്രിക്സും പരിശോധിക്കുകയും ടെസ്റ്റ് വിജയിച്ചോ എന്ന് പരിശോധിക്കുകയും ചെയ്യുന്നു. ഇതുവഴി ഞങ്ങളുടെ സേവന മെഷിന്റെ പ്രകടനത്തെക്കുറിച്ച് ഞങ്ങൾ പഠിക്കുകയും തെറ്റ് സഹിഷ്ണുതയെക്കുറിച്ചുള്ള ഞങ്ങളുടെ അനുമാനങ്ങൾ പരിശോധിക്കുന്നതിന് ഒരു റിഗ്രഷൻ ടെസ്റ്റ് നടത്തുകയും ചെയ്യുന്നു.

(ശ്രദ്ധിക്കുക: ഇസ്റ്റിയോ ഫോൾട്ട് ടോളറൻസ് സിമുലേറ്റർ ഓപ്പൺ സോഴ്‌സിംഗ് ചെയ്യുന്നതിനെക്കുറിച്ച് ഞങ്ങൾ ആലോചിക്കുകയാണ്, പക്ഷേ ഇതുവരെ അങ്ങനെ ചെയ്യാൻ തയ്യാറായിട്ടില്ല.)

സർവീസ് മെഷ് ബെഞ്ച്മാർക്കിനുള്ള ഇസ്തിയോ ഫോൾട്ട് ടോളറൻസ് സിമുലേറ്റർ

ഞങ്ങൾ സിമുലേറ്ററിന്റെ നിരവധി വർക്കിംഗ് നോഡുകൾ സജ്ജീകരിച്ചു:

• 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 (ഇൻകമിംഗ്, ഔട്ട്ഗോയിംഗ്).

വിഭവ ഉപയോഗം ഞങ്ങൾ ട്രാക്ക് ചെയ്യുന്നു ഡാറ്റഡോഗ്കാരണം ഞങ്ങൾക്ക് ഒരു പ്രോമിത്യൂസ് ക്ലസ്റ്റർ ഇല്ല.

ഫലങ്ങൾ

നിയന്ത്രണ പാനലുകൾ

ആദ്യം, ഞങ്ങൾ CPU ഉപഭോഗം പരിശോധിച്ചു.

ലിങ്കർഡ് കൺട്രോൾ പാനൽ ~22 മില്ലികോർ

ഇസ്തിയോ നിയന്ത്രണ പാനൽ: ~750 മില്ലികോർ

Istio നിയന്ത്രണ പാനൽ ഏകദേശം ഉപയോഗിക്കുന്നു 35 മടങ്ങ് കൂടുതൽ സിപിയു ഉറവിടങ്ങൾLinkerd നേക്കാൾ. തീർച്ചയായും, എല്ലാം സ്ഥിരസ്ഥിതിയായി ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ട്, കൂടാതെ istio-ടെലിമെട്രി ഇവിടെ ധാരാളം പ്രോസസർ ഉറവിടങ്ങൾ ഉപയോഗിക്കുന്നു (ചില പ്രവർത്തനങ്ങൾ പ്രവർത്തനരഹിതമാക്കുന്നതിലൂടെ ഇത് പ്രവർത്തനരഹിതമാക്കാം). ഞങ്ങൾ ഈ ഘടകം നീക്കം ചെയ്താൽ, നമുക്ക് ഇപ്പോഴും 100 മില്ലികോറിലധികം ലഭിക്കും, അതായത് 4 മടങ്ങ് കൂടുതൽLinkerd നേക്കാൾ.

സൈഡ്കാർ പ്രോക്സി

തുടർന്ന് ഞങ്ങൾ ഒരു പ്രോക്സിയുടെ ഉപയോഗം പരീക്ഷിച്ചു. അഭ്യർത്ഥനകളുടെ എണ്ണവുമായി ഒരു രേഖീയ ബന്ധം ഉണ്ടായിരിക്കണം, എന്നാൽ ഓരോ സൈഡ്കാറിനും വക്രത്തെ ബാധിക്കുന്ന ചില ഓവർഹെഡ് ഉണ്ട്.

Linkerd: IRs-client-ന് ~100 മില്ലികോറുകൾ, IRs-client-loadgen-ന് ~50 millicores

ഫലങ്ങൾ ലോജിക്കൽ ആയി കാണപ്പെടുന്നു, കാരണം ക്ലയന്റ് പ്രോക്സിക്ക് ലോഡ്ജെൻ പ്രോക്സിയുടെ ഇരട്ടി ട്രാഫിക് ലഭിക്കുന്നു: ലോഡ്ജെനിൽ നിന്നുള്ള ഓരോ ഔട്ട്‌ഗോയിംഗ് അഭ്യർത്ഥനയ്ക്കും, ക്ലയന്റിന് ഒരു ഇൻകമിംഗും ഒരു ഔട്ട്‌ഗോയിംഗും ഉണ്ടായിരിക്കും.

ഇസ്തിയോ/ദൂതൻ: ഐആർഎസ്-ക്ലയന്റിനായി ~155 മില്ലികോറുകൾ, ഐആർഎസ്-ക്ലയന്റ്-ലോഡജെന് ~75 മില്ലികോറുകൾ

ഇസ്തിയോ സൈഡ്കാറുകൾക്ക് സമാനമായ ഫലങ്ങൾ ഞങ്ങൾ കാണുന്നു.

എന്നാൽ പൊതുവേ, ഇസ്തിയോ/എൻവോയ് പ്രോക്സികൾ ഉപയോഗിക്കുന്നു ഏകദേശം 50% കൂടുതൽ CPU ഉറവിടങ്ങൾLinkerd നേക്കാൾ.

സെർവർ വശത്ത് ഞങ്ങൾ ഇതേ സ്കീം കാണുന്നു:

ലിങ്കർഡ്: ഐആർഎസ്-സെർവറിന് ~50 മില്ലികോർ

ഇസ്തിയോ/ദൂതൻ: ഐആർഎസ്-സെർവറിന് ~80 മില്ലികോർ

സെർവർ വശത്ത്, സൈഡ്കാർ ഇസ്തിയോ/എൻവോയ് ഉപയോഗിക്കുന്നു ഏകദേശം 60% കൂടുതൽ CPU ഉറവിടങ്ങൾLinkerd നേക്കാൾ.

തീരുമാനം

ഞങ്ങളുടെ സിമുലേറ്റ് ചെയ്‌ത ജോലിഭാരത്തിൽ ലിങ്കർഡിനേക്കാൾ 50+% കൂടുതൽ സിപിയു ഇസ്തിയോ എൻവോയ് പ്രോക്‌സി ഉപയോഗിക്കുന്നു. ലിങ്കർഡ് കൺട്രോൾ പാനൽ ഇസ്തിയോയേക്കാൾ വളരെ കുറച്ച് വിഭവങ്ങൾ ഉപയോഗിക്കുന്നു, പ്രത്യേകിച്ച് പ്രധാന ഘടകങ്ങൾക്ക്.

ഈ ചെലവുകൾ എങ്ങനെ കുറയ്ക്കാം എന്നതിനെക്കുറിച്ച് ഞങ്ങൾ ഇപ്പോഴും ചിന്തിക്കുന്നു. നിങ്ങൾക്ക് ആശയങ്ങൾ ഉണ്ടെങ്കിൽ, ദയവായി പങ്കിടുക!

അവലംബം: www.habr.com