Istio અને Linkerd માટે CPU વપરાશ બેન્ચમાર્ક

પરિચય

અમે અંદર છીએ Shopify Istio ને સર્વિસ મેશ તરીકે જમાવવાનું શરૂ કર્યું. સૈદ્ધાંતિક રીતે, એક વસ્તુ સિવાય, બધું સારું છે: તે મોંઘુ છે.

В પ્રકાશિત બેન્ચમાર્ક Istio માટે તે કહે છે:

Istio 1.1 સાથે, પ્રોક્સી પ્રતિ સેકન્ડ દીઠ 0,6 વિનંતીઓ માટે આશરે 1000 vCPUs (વર્ચ્યુઅલ કોરો) વાપરે છે.

સર્વિસ મેશમાં પ્રથમ પ્રદેશ માટે (કનેક્શનની દરેક બાજુએ 2 પ્રોક્સી), અમારી પાસે માત્ર પ્રોક્સી માટે 1200 કોરો હશે, પ્રતિ સેકન્ડ એક મિલિયન વિનંતીઓના દરે. Google ના ખર્ચ કેલ્ક્યુલેટર મુજબ, તે ગોઠવણી માટે લગભગ $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 નો ઉપયોગ કરતા નથી, પરંતુ તે આવા કાર્ય માટે આદર્શ છે. દરેક સેવા મેશ માટે મારે શાબ્દિક રીતે થોડા આદેશોનો ઉપયોગ કરવો પડ્યો. મેં આઇસોલેશન માટે બે ક્લસ્ટરનો ઉપયોગ કર્યો - એક-એક Istio અને Linkerd માટે.

આ પ્રયોગ Google Kubernetes Engine પર કરવામાં આવ્યો હતો. મેં કુબરનેટ્સનો ઉપયોગ કર્યો 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. અમે આ લેખમાં તેના વિશે વાત કરીશું નહીં. હું ફક્ત એટલું જ કહી દઉં કે આ એક નિયંત્રક છે જે તમામ નવા પોડ્સની ઍક્સેસ પર નજર રાખે છે અને ગતિશીલ રીતે એક sidecar અને 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 જમાવટ સુયોજિત કરી રહ્યા છીએ

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

Istio ફોલ્ટ ટોલરન્સ સિમ્યુલેટર

Shopify માટે અનન્ય ટ્રાફિક સાથે પ્રયોગ કરવા માટે અમે Istio નામનું ફોલ્ટ ટોલરન્સ સિમ્યુલેટર બનાવ્યું છે. અમને વૈવિધ્યપૂર્ણ ટોપોલોજી બનાવવા માટે એક સાધનની જરૂર હતી જે અમારા સેવા ગ્રાફના ચોક્કસ ભાગને રજૂ કરે, જે ચોક્કસ વર્કલોડને મોડલ કરવા માટે ગતિશીલ રીતે ગોઠવેલ હોય.

ફ્લેશ વેચાણ દરમિયાન Shopify નું ઈન્ફ્રાસ્ટ્રક્ચર ભારે ભાર હેઠળ છે. તે જ સમયે, Shopify વેચાણકર્તાઓને આવા વેચાણને વધુ વખત રાખવાની ભલામણ કરે છે. મોટા ગ્રાહકો ક્યારેક આયોજિત ફ્લેશ વેચાણ વિશે ચેતવણી આપે છે. અન્ય લોકો દિવસ કે રાત્રિના કોઈપણ સમયે આપણા માટે અનપેક્ષિત રીતે તેનું સંચાલન કરે છે.

અમે અમારા સ્થિતિસ્થાપકતા સિમ્યુલેટરને વર્કફ્લોને મોડેલ કરવા ઇચ્છીએ છીએ જે ટોપોલોજી અને વર્કલોડ્સ સાથે મેળ ખાય છે જેણે ભૂતકાળમાં Shopify ના ઇન્ફ્રાસ્ટ્રક્ચરને દબાવી દીધું છે. સર્વિસ મેશનો ઉપયોગ કરવાનો મુખ્ય હેતુ એ છે કે અમને નેટવર્ક સ્તરે વિશ્વસનીયતા અને ખામી સહિષ્ણુતાની જરૂર છે, અને તે અમારા માટે મહત્વપૂર્ણ છે કે સર્વિસ મેશ અગાઉ સેવાઓમાં વિક્ષેપ પાડતા ભારનો અસરકારક રીતે સામનો કરે છે.

ફોલ્ટ ટોલરન્સ સિમ્યુલેટરના હાર્દમાં વર્કર નોડ છે, જે સર્વિસ મેશ નોડ તરીકે કામ કરે છે. વર્કર નોડને સ્ટાર્ટઅપ સમયે સ્થિર રીતે ગોઠવી શકાય છે અથવા REST API દ્વારા ગતિશીલ રીતે ગોઠવી શકાય છે. રીગ્રેસન ટેસ્ટના સ્વરૂપમાં વર્કફ્લો બનાવવા માટે અમે વર્કર નોડ્સના ડાયનેમિક કન્ફિગરેશનનો ઉપયોગ કરીએ છીએ.

અહીં આવી પ્રક્રિયાનું ઉદાહરણ છે:

• અમે 10 સર્વર તરીકે લોન્ચ કરીએ છીએ bar સેવા જે પ્રતિસાદ આપે છે 200/OK 100 ms પછી.
• અમે 10 ક્લાયન્ટ્સ લોન્ચ કરીએ છીએ - દરેક પ્રતિ સેકન્ડે 100 વિનંતીઓ મોકલે છે bar.
• દર 10 સેકન્ડે અમે 1 સર્વર અને મોનિટરની ભૂલોને દૂર કરીએ છીએ 5xx ગ્રાહક પર.

વર્કફ્લોના અંતે, અમે લોગ અને મેટ્રિક્સની તપાસ કરીએ છીએ અને તપાસ કરીએ છીએ કે ટેસ્ટ પાસ થયો છે કે નહીં. આ રીતે અમે અમારા સર્વિસ મેશના પ્રદર્શન વિશે જાણીએ છીએ અને ખામી સહિષ્ણુતા વિશે અમારી ધારણાઓને ચકાસવા માટે રીગ્રેશન ટેસ્ટ ચલાવીએ છીએ.

(નોંધ: અમે Istio ફોલ્ટ ટોલરન્સ સિમ્યુલેટર ઓપન સોર્સિંગ પર વિચાર કરી રહ્યા છીએ, પરંતુ હજુ સુધી તેમ કરવા તૈયાર નથી.)

સર્વિસ મેશ બેન્ચમાર્ક માટે Istio ફોલ્ટ ટોલરન્સ સિમ્યુલેટર

અમે સિમ્યુલેટરના ઘણા કાર્યકારી ગાંઠો સેટ કર્યા છે:

• 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 મિલીકોર

Istio નિયંત્રણ પેનલ: ~750 મિલીકોર

Istio નિયંત્રણ પેનલ આશરે ઉપયોગ કરે છે 35 ગણા વધુ CPU સંસાધનોLinkerd કરતાં. અલબત્ત, બધું ડિફૉલ્ટ રૂપે ઇન્સ્ટોલ કરેલું છે, અને ઇસ્ટિઓ-ટેલિમેટ્રી અહીં ઘણા બધા પ્રોસેસર સંસાધનોનો ઉપયોગ કરે છે (કેટલાક કાર્યોને અક્ષમ કરીને તેને અક્ષમ કરી શકાય છે). જો આપણે આ ઘટકને દૂર કરીએ, તો પણ આપણને 100 થી વધુ મિલીકોર મળે છે, એટલે કે 4 ગણો વધુLinkerd કરતાં.

સાઇડકાર પ્રોક્સી

અમે પછી પ્રોક્સીના ઉપયોગનું પરીક્ષણ કર્યું. વિનંતીઓની સંખ્યા સાથે રેખીય સંબંધ હોવો જોઈએ, પરંતુ દરેક સાઇડકાર માટે કેટલાક ઓવરહેડ છે જે વળાંકને અસર કરે છે.

લિંકર્ડ: irs-ક્લાયન્ટ માટે ~100 મિલીકોર, IRs-ક્લાયન્ટ-લોડજન માટે ~50 મિલીકોર

પરિણામો તાર્કિક લાગે છે, કારણ કે ક્લાયંટ પ્રોક્સી લોડજન પ્રોક્સી કરતા બમણું ટ્રાફિક મેળવે છે: લોડજનમાંથી દરેક આઉટગોઇંગ વિનંતી માટે, ક્લાયંટ પાસે એક ઇનકમિંગ અને એક આઉટગોઇંગ હોય છે.

Istio/દૂત: irs-client માટે ~155 millicores, ~75 millicores for irs-client-loadgen

અમે Istio sidecars માટે સમાન પરિણામો જોઈએ છીએ.

પરંતુ સામાન્ય રીતે, Istio/Envoy પ્રોક્સીઓ વાપરે છે લગભગ 50% વધુ CPU સંસાધનોLinkerd કરતાં.

અમે સર્વર બાજુ પર સમાન યોજના જોઈએ છીએ:

લિંકર્ડ: IRs-સર્વર માટે ~50 મિલીકોર

Istio/દૂત: irs-સર્વર માટે ~80 મિલીકોર

સર્વર બાજુ પર, સાઇડકાર Istio/દૂત વપરાશ કરે છે લગભગ 60% વધુ CPU સંસાધનોLinkerd કરતાં.

નિષ્કર્ષ

Istio Envoy પ્રોક્સી અમારા સિમ્યુલેટેડ વર્કલોડ પર Linkerd કરતાં 50+% વધુ CPU વાપરે છે. Linkerd કંટ્રોલ પેનલ ખાસ કરીને મુખ્ય ઘટકો માટે, Istio કરતાં ઘણા ઓછા સંસાધનોનો ઉપયોગ કરે છે.

અમે હજી પણ આ ખર્ચને કેવી રીતે ઘટાડવો તે વિશે વિચારી રહ્યા છીએ. જો તમારી પાસે વિચારો હોય, તો કૃપા કરીને શેર કરો!

સોર્સ: www.habr.com