Istio மற்றும் Linkerd க்கான CPU நுகர்வு அளவுகோல்

அறிமுகம்

நாங்கள் உள்ளோம் shopify இஸ்டியோவை ஒரு சேவை வலையாகப் பயன்படுத்தத் தொடங்கினார். கொள்கையளவில், ஒரு விஷயத்தைத் தவிர, எல்லாம் நன்றாக இருக்கிறது: அது விலை உயர்ந்தது.

В வெளியிடப்பட்ட அளவுகோல்கள் இஸ்டியோவிற்கு அது கூறுகிறது:

Istio 1.1 உடன், ப்ராக்ஸி ஒரு வினாடிக்கு 0,6 கோரிக்கைகளுக்கு தோராயமாக 1000 vCPUகளை (மெய்நிகர் கோர்கள்) பயன்படுத்துகிறது.

சேவை மெஷில் உள்ள முதல் பகுதிக்கு (இணைப்பின் ஒவ்வொரு பக்கத்திலும் 2 ப்ராக்ஸிகள்), வினாடிக்கு ஒரு மில்லியன் கோரிக்கைகள் என்ற விகிதத்தில் ப்ராக்ஸிக்காக மட்டும் 1200 கோர்களை வைத்திருப்போம். கூகுளின் செலவுக் கால்குலேட்டரின் படி, இது உள்ளமைவுக்காக சுமார் $40/மாதம்/கோர் ஆகும் n1-standard-64, அதாவது, இந்த பிராந்தியத்தில் மட்டும் ஒரு வினாடிக்கு 50 மில்லியன் கோரிக்கைகளுக்கு மாதத்திற்கு 1 ஆயிரம் டாலர்களுக்கு மேல் செலவாகும்.

இவான் சிம் (இவான் சிம்) பார்வையுடன் ஒப்பிடப்படுகிறது சேவை மெஷ் கடந்த ஆண்டு தாமதமானது மற்றும் நினைவகம் மற்றும் செயலிக்கு அதே வாக்குறுதி அளித்தது, ஆனால் அது செயல்படவில்லை:

வெளிப்படையாக, values-istio-test.yaml CPU கோரிக்கைகளை தீவிரமாக அதிகரிக்கும். நான் எனது கணிதத்தைச் சரியாகச் செய்திருந்தால், கட்டுப்பாட்டுப் பலகத்திற்கு தோராயமாக 24 CPU கோர்களும் ஒவ்வொரு ப்ராக்ஸிக்கும் 0,5 CPUகளும் தேவைப்படும். என்னிடம் அவ்வளவு இல்லை. எனக்கு அதிக ஆதாரங்கள் ஒதுக்கப்படும் போது நான் சோதனைகளை மீண்டும் செய்வேன்.

இஸ்டியோவின் செயல்திறன் மற்றொரு ஓப்பன் சோர்ஸ் சர்வீஸ் மெஷுடன் எவ்வளவு ஒத்திருக்கிறது என்பதை நானே பார்க்க விரும்பினேன்: லிங்கர்ட்.

சேவை மெஷ் நிறுவல்

முதலில், நான் அதை ஒரு கிளஸ்டரில் நிறுவினேன் சூப்பர் குளோ:

$ 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 உடன் வரும் கட்டுப்படுத்தியைப் பயன்படுத்தினேன். நேம்ஸ்பேஸில் ஷார்ட்கட் இருக்கும் போது கன்ட்ரோலர் இயல்புநிலையாக சைட்கார்களை செலுத்துகிறது 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 விற்பனையாளர்கள் இத்தகைய விற்பனையை அடிக்கடி நடத்த பரிந்துரைக்கிறது. பெரிய வாடிக்கையாளர்கள் சில நேரங்களில் திட்டமிட்ட ஃபிளாஷ் விற்பனையைப் பற்றி எச்சரிக்கின்றனர். மற்றவர்கள் பகல் அல்லது இரவின் எந்த நேரத்திலும் நமக்கு எதிர்பாராத விதமாக அவற்றை நடத்துகிறார்கள்.

கடந்த காலங்களில் 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 மில்லிகோர்

இஸ்டியோ கட்டுப்பாட்டுப் பலகம் தோராயமாகப் பயன்படுத்துகிறது 35 மடங்கு அதிகமான CPU ஆதாரங்கள்Linkerd ஐ விட. நிச்சயமாக, எல்லாமே முன்னிருப்பாக நிறுவப்பட்டுள்ளன, மேலும் istio-telemetry இங்கே நிறைய செயலி வளங்களைப் பயன்படுத்துகிறது (சில செயல்பாடுகளை முடக்குவதன் மூலம் அதை முடக்கலாம்). இந்த கூறுகளை அகற்றினால், இன்னும் 100 மில்லிகோர்களுக்கு மேல் கிடைக்கும், அதாவது 4 மடங்கு அதிகம்Linkerd ஐ விட.

சைட்கார் ப்ராக்ஸி

ப்ராக்ஸியின் பயன்பாட்டை நாங்கள் சோதித்தோம். கோரிக்கைகளின் எண்ணிக்கையுடன் நேரியல் உறவு இருக்க வேண்டும், ஆனால் ஒவ்வொரு பக்க காருக்கும் வளைவை பாதிக்கும் சில மேல்நிலை உள்ளது.

Linkerd: IRs-client-க்கு ~100 மில்லிகோர்கள், IRs-client-loadgenக்கு ~50 மில்லிகோர்கள்

லோட்ஜென் ப்ராக்ஸியை விட க்ளையன்ட் ப்ராக்ஸி இருமடங்கு டிராஃபிக்கைப் பெறுவதால், முடிவுகள் தர்க்கரீதியாகத் தெரிகிறது: லோட்ஜெனிடமிருந்து ஒவ்வொரு வெளிச்செல்லும் கோரிக்கைக்கும், கிளையன்ட் ஒரு உள்வரும் மற்றும் ஒரு வெளிச்செல்லும்.

இஸ்டியோ/தூதுவர்: ஐஆர்எஸ்-கிளையண்டிற்கு ~155 மில்லிகோர்கள், ஐஆர்எஸ்-கிளையண்ட்-லோட்ஜெனுக்கு ~75 மில்லிகோர்கள்

இஸ்டியோ சைட்கார்களுக்கும் இதே போன்ற முடிவுகளைப் பார்க்கிறோம்.

ஆனால் பொதுவாக, Istio/Envoy ப்ராக்ஸிகள் பயன்படுத்துகின்றனர் தோராயமாக 50% அதிகமான CPU வளங்கள்Linkerd ஐ விட.

சேவையக பக்கத்தில் அதே திட்டத்தை நாங்கள் காண்கிறோம்:

Linkerd: IRs-serverக்கு ~50 மில்லிகோர்

இஸ்டியோ/தூதுவர்: ஐஆர்எஸ்-சர்வருக்கு ~80 மில்லிகோர்

சர்வர் பக்கத்தில், சைட்கார் இஸ்டியோ/என்வாய் பயன்படுத்துகிறது தோராயமாக 60% அதிகமான CPU வளங்கள்Linkerd ஐ விட.

முடிவுக்கு

எங்களின் உருவகப்படுத்தப்பட்ட பணிச்சுமையில் லிங்கர்டை விட இஸ்டியோ என்வாய் ப்ராக்ஸி 50+% அதிக CPU ஐப் பயன்படுத்துகிறது. லிங்கர்ட் கட்டுப்பாட்டுப் பலகம் இஸ்டியோவை விட மிகக் குறைவான ஆதாரங்களைப் பயன்படுத்துகிறது, குறிப்பாக முக்கிய கூறுகளுக்கு.

இந்தச் செலவுகளை எப்படிக் குறைப்பது என்று இன்னும் யோசித்து வருகிறோம். உங்களுக்கு யோசனைகள் இருந்தால், பகிர்ந்து கொள்ளுங்கள்!

ஆதாரம்: www.habr.com