🥇Tolok ukur konsumsi CPU kanggo Istio lan Linkerd

Pambuka

Kita mlebu Shopify miwiti deploying Istio minangka bolong layanan. Ing asas, kabeh apik, kajaba mung siji: iku larang.

В pathokan diterbitake kanggo Istio ngandika:

Kanthi Istio 1.1, proxy nggunakake kira-kira 0,6 vCPU (inti virtual) saben 1000 panjalukan saben detik.

Kanggo wilayah pisanan ing bolong layanan (2 proxy ing saben sisih sambungan), kita bakal duwe 1200 intine mung kanggo proxy, ing tingkat siji yuta panjalukan saben detik. Miturut kalkulator biaya Google, kira-kira $40/wulan/inti kanggo konfigurasi. n1-standard-64, yaiku, wilayah iki mung bakal biaya kita luwih saka 50 ewu dolar saben sasi kanggo 1 yuta panjalukan saben detik.

Ivan Sim (Ivan Sim) visual dibandhingake telat layanan bolong pungkasan taun lan janji padha kanggo memori lan prosesor, nanging ora bisa metu:

Ketoke, values-istio-test.yaml bakal nambah panjalukan CPU kanthi serius. Yen aku wis rampung math bener, sampeyan kudu kira-kira 24 intine CPU kanggo panel kontrol lan 0,5 CPU kanggo saben proxy. Aku ora duwe akeh. Aku bakal mbaleni tes nalika sumber daya liyane diparengake kanggo kula.

Aku pengin ndeleng dhewe carane kinerja Istio padha karo bolong layanan open source liyane: Linkerd.

Layanan instalasi jaringan

Kaping pisanan, aku nginstal ing kluster 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!

Aku nggunakake SuperGloo amarga nggawe bootstrap bolong layanan luwih gampang. Aku ora kudu nindakake akeh. Kita ora nggunakake SuperGloo ing produksi, nanging iku becik kanggo tugas kuwi. Aku kudu nggunakake secara harfiah saperangan printah kanggo saben bolong layanan. Aku nggunakake rong klompok kanggo ngisolasi - siji kanggo Istio lan Linkerd.

Eksperimen kasebut ditindakake ing Google Kubernetes Engine. Aku nggunakake Kubernetes 1.12.7-gke.7 lan blumbang kelenjar n1-standard-4 kanthi skala simpul otomatis (minimal 4, maksimal 16).

Banjur aku nginstal loro meshes layanan saka baris printah.

Linkerd pisanan:

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

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

Kacilakan-loop njupuk sawetara menit, banjur panel kontrol stabil.

(Cathetan: SuperGloo mung ndhukung Istio 1.0.x kanggo saiki. Aku mbaleni eksperimen karo Istio 1.1.3, nanging ora weruh prabédan sing katon.)

Nyetel Istio Penyebaran Otomatis

Kanggo nggawe Istio nginstal Utusan sidecar, kita nggunakake injektor sidecar − MutatingAdmissionWebhook. Kita ora bakal ngomong babagan iki ing artikel iki. Ayo kula ujar manawa iki minangka pengontrol sing ngawasi akses kabeh pod anyar lan kanthi dinamis nambah sidecar lan initContainer, sing tanggung jawab kanggo tugas. iptables.

Kita ing Shopify nulis pengontrol akses dhewe kanggo ngetrapake sidecars, nanging kanggo benchmark iki aku nggunakake pengontrol sing dilengkapi karo Istio. Kontroler nyuntikake sidecars minangka standar nalika ana trabasan ing namespace 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

Nyetel panyebaran Linkerd otomatis

Kanggo nyiyapake linkerd sidecar embedding, kita nggunakake anotasi (aku nambahake kanthi manual liwat 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

Simulator Toleransi Istio Fault

Kita nggawe simulator toleransi kesalahan sing diarani Istio kanggo eksperimen karo lalu lintas sing unik kanggo Shopify. Kita butuh alat kanggo nggawe topologi khusus sing bakal makili bagean tartamtu saka grafik layanan, kanthi dinamis dikonfigurasi kanggo model beban kerja tartamtu.

Infrastruktur Shopify ngalami beban abot sajrone adol lampu kilat. Ing wektu sing padha, Shopify nyaranake para penjual supaya luwih kerep nindakake penjualan kasebut. Pelanggan gedhe kadhangkala ngelingake babagan adol lampu kilat sing direncanakake. Wong liya nindakake kanthi ora sengaja kanggo kita ing wayah awan utawa wengi.

Kita pengin simulator ketahanan kanggo model alur kerja sing cocog karo topologi lan beban kerja sing wis ngatasi infrastruktur Shopify ing jaman kepungkur. Tujuan utama nggunakake bolong layanan yaiku kita butuh linuwih lan toleransi kesalahan ing tingkat jaringan, lan penting kanggo kita yen bolong layanan bisa ngatasi beban sing sadurunge ngganggu layanan.

Ing jantung simulator toleransi kesalahan yaiku simpul pekerja, sing tumindak minangka simpul bolong layanan. Node pekerja bisa dikonfigurasi kanthi statis nalika wiwitan utawa kanthi dinamis liwat REST API. Kita nggunakake konfigurasi dinamis simpul pekerja kanggo nggawe alur kerja ing bentuk tes kemunduran.

Punika conto proses kasebut:

We miwiti 10 server minangka bar layanan sing ngasilake respon 200/OK sawise 100 ms.
We miwiti 10 klien - saben ngirim 100 panjalukan saben detik kanggo bar.
Saben 10 detik kita mbusak 1 server lan ngawasi kasalahan 5xx ing klien.

Ing pungkasan alur kerja, kita mriksa log lan metrik lan mriksa manawa tes kasebut lulus. Kanthi cara iki kita sinau babagan kinerja bolong layanan lan nganakake tes kemunduran kanggo nyoba asumsi babagan toleransi kesalahan.

(Cathetan: Kita nimbang mbukak sumber simulator toleransi kesalahan Istio, nanging durung siyap.)

Simulator toleransi kesalahan Istio kanggo patokan bolong layanan

Kita nyiyapake sawetara simpul sing digunakake ing simulator:

irs-client-loadgen: 3 replika sing ngirim 100 panjalukan saben detik irs-client.
irs-client: 3 replika sing nampa panjalukan, ngenteni 100ms lan nerusake panjalukan kanggo irs-server.
irs-server: 3 replika sing bali 200/OK sawise 100 ms.

Kanthi konfigurasi iki, kita bisa ngukur arus lalu lintas sing stabil ing antarane 9 titik pungkasan. Sidecar ing irs-client-loadgen и irs-server nampa 100 panjalukan saben detik, lan irs-client - 200 (mlebu lan metu).

Kita nglacak panggunaan sumber daya liwat DataDogamarga kita ora duwe klompok Prometheus.

Результаты

Panel kontrol

Kaping pisanan, kita mriksa konsumsi CPU.

Panel kontrol Linkerd ~22 milicore

Panel kontrol Istio: ~750 milicore

Panel kontrol Istio nggunakake kira-kira 35 kaping luwih sumber daya CPUtinimbang Linkerd. Mesthine, kabeh wis diinstal kanthi gawan, lan istio-telemetri nggunakake akeh sumber daya prosesor ing kene (bisa dipateni kanthi mateni sawetara fungsi). Yen kita mbusak komponen iki, kita isih entuk luwih saka 100 millicores, iku 4 kaping luwihtinimbang Linkerd.

Sidecar proxy

Kita banjur nyoba nggunakake proxy. Mesthi ana hubungan linear karo jumlah panjalukan, nanging kanggo saben sidecar ana sawetara overhead sing mengaruhi kurva.

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

Asil katon logis, amarga proxy klien nampa lalu lintas kaping pindho minangka proxy loadgen: kanggo saben panjalukan metu saka loadgen, klien duwe siji mlebu lan siji metu.

Istio/Envoy: ~155 milicores kanggo irs-klien, ~75 milicores kanggo irs-klien-loadgen

Kita ndeleng asil sing padha kanggo sidecars Istio.

Nanging umume, proxy Istio / Utusan nganggo kira-kira 50% sumber daya CPU liyanetinimbang Linkerd.

Kita ndeleng skema sing padha ing sisih server:

Linkerd: ~ 50 millicore kanggo irs-server

Istio / Utusan: ~ 80 millicore kanggo irs-server

Ing sisih server, sidecar Istio / Utusan nganggo kira-kira 60% sumber daya CPU liyanetinimbang Linkerd.

kesimpulan

Proksi Istio Envoy nggunakake CPU 50+% luwih akeh tinimbang Linkerd ing beban kerja simulasi kita. Panel kontrol Linkerd nggunakake sumber daya luwih sithik tinimbang Istio, utamane kanggo komponen inti.

Kita isih mikir babagan carane nyuda biaya kasebut. Yen sampeyan duwe gagasan, mangga bareng!

Source: www.habr.com

benchmark konsumsi CPU kanggo Istio lan Linkerd