Istio සහ Linkerd සඳහා CPU පරිභෝජන මිණුම් ලකුණ

හැඳින්වීම

අපි ඇතුලේ Shopify Istio සේවා දැලක් ලෙස යෙදවීමට පටන් ගත්තේය. ප්‍රතිපත්තිමය වශයෙන්, එක් දෙයක් හැර, සියල්ල හොඳයි: එය මිල අධිකයි.

В ප්‍රකාශිත මිණුම් සලකුණු Istio සඳහා එය මෙසේ කියයි.

Istio 1.1 සමඟින්, ප්‍රොක්සි තත්පරයකට ඉල්ලීම් 0,6කට ආසන්න වශයෙන් 1000 vCPUs (අථත්‍ය හරයන්) පරිභෝජනය කරයි.

සේවා දැලෙහි පළමු කලාපය සඳහා (සම්බන්ධතාවයේ සෑම පැත්තකින්ම ප්‍රොක්සි 2ක්), අපට තත්පරයකට ඉල්ලීම් මිලියනයක අනුපාතයකින් ප්‍රොක්සි සඳහා පමණක් මධ්‍ය 1200 ක් ඇත. Google හි පිරිවැය කැල්කියුලේටරයට අනුව, එය වින්‍යාස කිරීම සඳහා දළ වශයෙන් $40/මස/core ලෙස ක්‍රියා කරයි n1-standard-64, එනම්, මෙම කලාපයට පමණක් තත්පරයකට ඉල්ලීම් මිලියන 50 ක් සඳහා මසකට ඩොලර් 1 දහසකට වඩා වැඩි මුදලක් වැය වේ.

අයිවන් සිම් (අයිවන් සිම්) දෘශ්යමය වශයෙන් සංසන්දනය කර ඇත සේවා දැල් පසුගිය වසරේ ප්‍රමාද වූ අතර මතකය සහ ප්‍රොසෙසරය සඳහා එයම පොරොන්දු වූ නමුත් එය ක්‍රියාත්මක වූයේ නැත:

පෙනෙන විදිහට, values-istio-test.yaml CPU ඉල්ලීම් බරපතල ලෙස වැඩි කරයි. මම මගේ ගණිතය නිවැරදිව සිදු කර ඇත්නම්, ඔබට පාලක පැනලය සඳහා CPU මධ්‍ය 24 ක් සහ එක් එක් ප්‍රොක්සි සඳහා CPU 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 භාවිතා කළේ එය සේවා දැල බූට්ස්ට්‍රැප් කිරීම වඩාත් පහසු කරන බැවිනි. මට වැඩි දෙයක් කරන්න වුණේ නැහැ. අපි නිෂ්පාදනයේදී SuperGloo භාවිතා නොකරන නමුත් එවැනි කාර්යයක් සඳහා එය වඩාත් සුදුසුය. එක් එක් සේවා දැලක් සඳහා වචනාර්ථයෙන් විධාන කිහිපයක් භාවිතා කිරීමට මට සිදු විය. මම හුදකලා කිරීම සඳහා පොකුරු දෙකක් භාවිතා කළෙමි - Istio සහ Linkerd සඳහා එක බැගින්.

අත්හදා බැලීම Google Kubernetes එන්ජිම මත සිදු කරන ලදී. මම Kubernetes භාවිතා කළා 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 සමඟ අත්හදා බැලීම නැවත නැවත කළ නමුත් සැලකිය යුතු වෙනසක් නොදැක්කා.)

Istio ස්වයංක්‍රීය යෙදවීම සැකසීම

Istio විසින් සයිඩ්කාර් එන්වෝයි ස්ථාපනය කිරීමට, අපි සයිඩ්කාර් ඉන්ජෙක්ටරය භාවිතා කරමු MutatingAdmissionWebhook. අපි මේ ලිපියෙන් ඒ ගැන කතා කරන්නේ නැහැ. මෙය සියලුම නව කරල්වල ප්‍රවේශය නිරීක්ෂණය කරන සහ කාර්යයන් සඳහා වගකිව යුතු සයිඩ්කාර් සහ 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 සයිඩ්කාර් කාවැද්දීම සැකසීමට, අපි අනුසටහන් භාවිතා කරමු (මම ඒවා අතින් එකතු කළා 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 එවැනි විකුණුම් නිතර නිතර පැවැත්වීමට විකුණුම්කරුවන් නිර්දේශ කරයි. විශාල ගනුදෙනුකරුවන් සමහර විට සැලසුම් කර ඇති ෆ්ලෑෂ් අලෙවියක් ගැන අනතුරු අඟවයි. තවත් අය ඒවා දිවා රෑ ඕනෑම වේලාවක අප වෙනුවෙන් අනපේක්ෂිත ලෙස පවත්වති.

අපට අපගේ ඔරොත්තු දීමේ සිමියුලේටරය අවශ්‍ය වූයේ අතීතයේ Shopify යටිතල ව්‍යුහය යටපත් කර ඇති ස්ථාන සහ වැඩ ප්‍රවාහයන්ට ගැලපෙන කාර්ය ප්‍රවාහයන් ආදර්ශයට ගැනීමයි. සේවා දැලක් භාවිතා කිරීමේ ප්‍රධාන අරමුණ වන්නේ අපට ජාල මට්ටමින් විශ්වසනීයත්වය සහ දෝෂ ඉවසීම අවශ්‍ය වන අතර, මීට පෙර සේවා කඩාකප්පල් කළ බර සමඟ සේවා දැල ඵලදායි ලෙස කටයුතු කිරීම අපට වැදගත් වේ.

දෝෂ ඉවසීමේ සිමියුලේටරයේ හදවතේ සේවක නෝඩයක් වන අතර එය සේවා දැල් නෝඩයක් ලෙස ක්‍රියා කරයි. සේවක නෝඩය ආරම්භයේදී ස්ථිතිකව හෝ REST API හරහා ගතිකව වින්‍යාසගත කළ හැක. ප්‍රතිගාමී පරීක්ෂණ ආකාරයෙන් කාර්ය ප්‍රවාහයන් නිර්මාණය කිරීමට අපි සේවක නෝඩ් වල ගතික වින්‍යාසය භාවිතා කරමු.

එවැනි ක්රියාවලියක උදාහරණයක් මෙන්න:

• අපි සේවාදායකයන් 10 ක් දියත් කරමු bar ප්‍රතිචාරයක් ලබා දෙන සේවාව 200/OK 100 ms පසු.
• අපි සේවාදායකයින් 10 ක් දියත් කරමු - එක් එක් තත්පරයකට ඉල්ලීම් 100 ක් යවයි bar.
• සෑම තත්පර 10 කට වරක් අපි සේවාදායකයක් ඉවත් කර දෝෂ නිරීක්ෂණය කරමු 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 (පැමිණෙන සහ පිටතට යන).

අපි සම්පත් භාවිතය නිරීක්ෂණය කරන්නෙමු DataDogමොකද අපිට Prometheus පොකුරක් නැහැ.

ප්රතිඵල

පාලක පැනල්

පළමුව, අපි CPU පරිභෝජනය පරීක්ෂා කළා.

Linkerd පාලන පැනලය ~22 millicore

Istio පාලන පැනලය: ~750 millicore

Istio පාලන පැනලය ආසන්න වශයෙන් භාවිතා කරයි 35 ගුණයකින් වැඩි CPU සම්පත්Linkerd වලට වඩා. ඇත්ත වශයෙන්ම, සෑම දෙයක්ම පෙරනිමියෙන් ස්ථාපනය කර ඇති අතර, istio-telemetry මෙහි ප්‍රොසෙසර සම්පත් විශාල ප්‍රමාණයක් පරිභෝජනය කරයි (සමහර කාර්යයන් අක්‍රිය කිරීමෙන් එය අක්‍රිය කළ හැකිය). අපි මෙම සංරචකය ඉවත් කළහොත්, අපි තවමත් මිලිකෝර් 100 කට වඩා ලබා ගනිමු, එනම් 4 ගුණයකින් වැඩියLinkerd වලට වඩා.

සයිඩ්කාර් ප්‍රොක්සි

පසුව අපි ප්‍රොක්සි භාවිතා කිරීම පරීක්ෂා කළා. ඉල්ලීම් ගණන සමඟ රේඛීය සම්බන්ධතාවයක් තිබිය යුතුය, නමුත් එක් එක් පැති කාර් සඳහා වක්‍රයට බලපාන යම් උඩිස් එකක් තිබේ.

Linkerd: IRs-සේවාලාභියා සඳහා ~100 millicores, irs-client-loadgen සඳහා ~50 ml

ප්‍රතිඵල තාර්කිකව පෙනේ, මන්ද සේවාදායක ප්‍රොක්සියට ලෝඩජන් ප්‍රොක්සිය මෙන් දෙගුණයක් තදබදයක් ලැබේ: loadgen වෙතින් පිටතට යන සෑම ඉල්ලීමක් සඳහාම, සේවාදායකයාට එක් පැමිණෙන සහ එක් පිටතට යන එකක් ඇත.

Istio/Envoy: IRs-සේවාදායකයා සඳහා ~155 millicores, IRs-client-loadgen සඳහා ~75 ml

අපි Istio sidecars සඳහා සමාන ප්‍රතිඵල දකිමු.

නමුත් පොදුවේ, Istio/Envoy proxies පරිභෝජනය කරයි ආසන්න වශයෙන් 50% වැඩි CPU සම්පත්Linkerd වලට වඩා.

අපි සේවාදායකයේ පැත්තෙන් එකම යෝජනා ක්රමය දකිමු:

Linkerd: IRs-server සඳහා ~50 millicore

Istio/Envoy: IRs-server සඳහා ~80 millicores

සේවාදායක පැත්තෙන්, සයිඩ්කාර් ඉස්ටියෝ/එන්වෝයි පරිභෝජනය කරයි ආසන්න වශයෙන් 60% වැඩි CPU සම්පත්Linkerd වලට වඩා.

නිගමනය

Istio එන්වෝයි ප්‍රොක්සිය අපගේ අනුකරණය කළ කාර්ය භාරය මත Linkerdට වඩා 50+% වැඩි CPU පරිභෝජනය කරයි. Linkerd පාලක පැනලය Istio වලට වඩා බෙහෙවින් අඩු සම්පත් පරිභෝජනය කරයි, විශේෂයෙන්ම මූලික සංරචක සඳහා.

අපි තාම කල්පනා කරන්නේ මේ වියදම් අඩු කරන්නේ කොහොමද කියලා. ඔබට අදහස් ඇත්නම්, කරුණාකර බෙදා ගන්න!

මූලාශ්රය: www.habr.com