🥇Kigezo cha matumizi ya CPU kwa Istio na Linkerd

Utangulizi

Tuko ndani Shopify ilianza kupeleka Istio kama matundu ya huduma. Kimsingi, kila kitu ni sawa, isipokuwa kwa jambo moja: ni ghali.

В vigezo vilivyochapishwa kwa Istio inasema:

Kwa Istio 1.1, seva mbadala hutumia takriban 0,6 vCPU (cores halisi) kwa maombi 1000 kwa sekunde.

Kwa eneo la kwanza kwenye matundu ya huduma (wawakilishi 2 kila upande wa muunganisho), tutakuwa na cores 1200 kwa proksi tu, kwa kiwango cha maombi milioni moja kwa sekunde. Kulingana na kikokotoo cha gharama cha Google, inakaribia kuwa takriban $40/mwezi/msingi kwa usanidi. n1-standard-64, yaani, mkoa huu pekee utatugharimu zaidi ya dola elfu 50 kwa mwezi kwa maombi milioni 1 kwa sekunde.

Ivan Sim (Ivan Sim) kulinganishwa kwa macho ucheleweshaji wa matundu ya huduma mwaka jana na kuahidi sawa kwa kumbukumbu na processor, lakini haikufanya kazi:

Inavyoonekana, values-istio-test.yaml itaongeza sana maombi ya CPU. Ikiwa nimefanya hesabu yangu kwa usahihi, unahitaji takriban cores 24 za CPU kwa paneli dhibiti na 0,5 CPU kwa kila proksi. Sina kiasi hicho. Nitarudia majaribio wakati rasilimali zaidi zimetengwa kwangu.

Nilitaka kujionea jinsi utendaji wa Istio unavyofanana na matundu mengine ya huduma ya chanzo wazi: Kiungo.

Ufungaji wa mesh ya huduma

Kwanza kabisa, niliiweka kwenye nguzo 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!

Nilitumia SuperGloo kwa sababu inafanya bootstrapping mesh huduma rahisi zaidi. Sikuhitaji kufanya mengi. Hatutumii SuperGloo katika uzalishaji, lakini ni bora kwa kazi kama hiyo. Ilinibidi nitumie amri kadhaa kwa kila matundu ya huduma. Nilitumia nguzo mbili kutengwa - moja kwa Istio na Linkerd.

Jaribio lilifanywa kwenye Google Kubernetes Engine. Nilitumia Kubernetes 1.12.7-gke.7 na bwawa la nodi n1-standard-4 na kuongeza nodi moja kwa moja (kiwango cha chini 4, kiwango cha juu cha 16).

Kisha niliweka meshes zote mbili za huduma kutoka kwa safu ya amri.

Kiungo wa Kwanza:

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

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

Kitanzi cha ajali kilichukua dakika chache, na kisha paneli za udhibiti zikatulia.

(Kumbuka: SuperGloo inaauni Istio 1.0.x pekee kwa sasa. Nilirudia jaribio la Istio 1.1.3, lakini sikuona tofauti yoyote inayoonekana.)

Kuanzisha Usambazaji Kiotomatiki wa Istio

Ili kufanya Istio kusakinisha Mjumbe wa gari la kando, tunatumia kidunga cha kando - MutatingAdmissionWebhook. Hatutazungumza juu yake katika nakala hii. Acha niseme tu kwamba hiki ni kidhibiti kinachofuatilia ufikiaji wa ganda zote mpya na kuongeza kwa nguvu gari la kando na initContainer, ambayo inawajibika kwa kazi. iptables.

Sisi katika Shopify tuliandika kidhibiti chetu cha ufikiaji ili kutekeleza kando, lakini kwa alama hii nilitumia kidhibiti kinachokuja na Istio. Kidhibiti huingiza kando kwa chaguo-msingi kunapokuwa na njia ya mkato katika nafasi ya majina 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

Inaweka uwekaji wa Linkerd kiotomatiki

Ili kusanidi upachikaji wa gari la pembeni la Linkerd, tunatumia maelezo (niliiongeza mwenyewe kupitia 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

Tulitengeneza kiigaji cha kustahimili makosa kinachoitwa Istio ili kujaribu trafiki ya kipekee kwa Shopify. Tulihitaji zana ili kuunda topolojia maalum ambayo ingewakilisha sehemu mahususi ya grafu yetu ya huduma, iliyosanidiwa kwa uthabiti ili kuiga mizigo mahususi ya kazi.

Miundombinu ya Shopify iko chini ya mzigo mkubwa wakati wa mauzo ya flash. Wakati huo huo, Shopify inapendekeza wauzaji kushikilia mauzo kama hayo mara nyingi zaidi. Wateja wakubwa wakati mwingine huonya juu ya uuzaji uliopangwa wa flash. Wengine hutuandalia bila kutazamia wakati wowote wa mchana au usiku.

Tulitaka kiigaji chetu cha uthabiti kiwe kielelezo cha mtiririko wa kazi unaolingana na mada na mzigo wa kazi ambao ulilemea miundombinu ya Shopify hapo awali. Kusudi kuu la kutumia mesh ya huduma ni kwamba tunahitaji uaminifu na uvumilivu wa makosa katika kiwango cha mtandao, na ni muhimu kwetu kwamba mesh ya huduma inakabiliana kwa ufanisi na mizigo ambayo ilivuruga huduma hapo awali.

Kiini cha simulator ya kuvumilia makosa ni nodi ya mfanyakazi, ambayo hufanya kama nodi ya matundu ya huduma. Nodi ya mfanyakazi inaweza kusanidiwa kitakwimu wakati wa kuanza au kwa nguvu kupitia REST API. Tunatumia usanidi unaobadilika wa nodi za wafanyikazi ili kuunda utiririshaji wa kazi kwa njia ya majaribio ya rejista.

Hapa kuna mfano wa mchakato kama huu:

Tunazindua seva 10 kama bar huduma ambayo inarudisha majibu 200/OK baada ya 100 ms.
Tunazindua wateja 10 - kila mmoja hutuma maombi 100 kwa sekunde bar.
Kila sekunde 10 tunaondoa seva 1 na kufuatilia makosa 5xx juu ya mteja.

Mwishoni mwa mtiririko wa kazi, tunachunguza kumbukumbu na vipimo na kuangalia ikiwa jaribio limepita. Kwa njia hii tunajifunza kuhusu utendakazi wa matundu ya huduma na kufanya jaribio la urekebishaji ili kujaribu mawazo yetu kuhusu uvumilivu wa makosa.

(Kumbuka: Tunazingatia kutafuta wazi kiigaji cha kustahimili makosa cha Istio, lakini hatuko tayari kufanya hivyo bado.)

Kiigaji cha kustahimili hitilafu cha Istio kwa kipimo cha matundu ya huduma

Tunaweka nodi kadhaa za kufanya kazi za simulator:

irs-client-loadgen: nakala 3 zinazotuma maombi 100 kwa kila sekunde irs-client.
irs-client: Nakala 3 zinazopokea ombi, subiri 100ms na utume ombi kwa irs-server.
irs-server: nakala 3 zinazorudi 200/OK baada ya 100 ms.

Kwa usanidi huu, tunaweza kupima mtiririko thabiti wa trafiki kati ya ncha 9 za mwisho. Sidecars ndani irs-client-loadgen и irs-server kupokea maombi 100 kwa sekunde, na irs-client - 200 (zinazoingia na zinazotoka).

Tunafuatilia matumizi ya rasilimali kupitia DataDogkwa sababu hatuna nguzo ya Prometheus.

Matokeo

Paneli za kudhibiti

Kwanza, tulichunguza matumizi ya CPU.

Paneli dhibiti ya Linkerd ~ millicore 22

Paneli dhibiti ya Istio: ~ 750 millicore

Jopo la kudhibiti Istio hutumia takriban Rasilimali za CPU mara 35 zaidikuliko Linkerd. Bila shaka, kila kitu kimewekwa kwa default, na istio-telemetry hutumia rasilimali nyingi za processor hapa (inaweza kuzimwa kwa kuzima baadhi ya kazi). Ikiwa tutaondoa sehemu hii, bado tunapata zaidi ya millicores 100, yaani Mara 4 zaidikuliko Linkerd.

Wakala wa sidecar

Kisha tulijaribu matumizi ya proksi. Kunapaswa kuwa na uhusiano wa mstari na idadi ya maombi, lakini kwa kila kando kuna sehemu ya juu inayoathiri curve.

Linkerd: ~100 millicores kwa irs-client, ~50 millicores kwa irs-client-loadgen

Matokeo yanaonekana kuwa ya kimantiki, kwa sababu proksi ya mteja hupokea trafiki mara mbili zaidi ya proksi ya loadgen: kwa kila ombi linalotoka kutoka kwa loadgen, mteja ana moja inayoingia na moja inayotoka.

Istio/Mjumbe: ~155 millicores kwa irs-client, ~75 millicores kwa irs-client-loadgen

Tunaona matokeo sawa kwa Istio sidecars.

Lakini kwa ujumla, wakala wa Istio/Mjumbe hutumia takriban 50% zaidi ya rasilimali za CPUkuliko Linkerd.

Tunaona mpango sawa kwa upande wa seva:

Linkerd: ~50 millicore kwa irs-server

Istio/Mjumbe: ~80 millicore kwa irs-server

Kwa upande wa seva, sidecar Istio/Envoy hutumia takriban 60% zaidi ya rasilimali za CPUkuliko Linkerd.

Hitimisho

Wakala wa Istio Mjumbe hutumia 50+% CPU zaidi ya Linkerd kwenye mzigo wetu wa kazi ulioiga. Paneli dhibiti ya Linkerd hutumia rasilimali kidogo zaidi kuliko Istio, haswa kwa vipengee vya msingi.

Bado tunafikiria jinsi ya kupunguza gharama hizi. Ikiwa una mawazo, tafadhali shiriki!

Chanzo: mapenzi.com

Kiwango cha matumizi ya CPU kwa Istio na Linkerd