ມາດຕະຖານການບໍລິໂພກ CPU ສໍາລັບ Istio ແລະ Linkerd

ການນໍາສະເຫນີ

ພວກເຮົາຢູ່ໃນ Shopify ເລີ່ມນຳໃຊ້ Istio ເປັນຕາໜ່າງບໍລິການ. ໃນຫຼັກການ, ທຸກສິ່ງທຸກຢ່າງແມ່ນດີ, ຍົກເວັ້ນສິ່ງດຽວ: ມັນແມ່ນລາຄາແພງ.

В ດັດຊະນີທີ່ເຜີຍແຜ່ ສໍາລັບ Istio ມັນເວົ້າວ່າ:

ດ້ວຍ Istio 1.1, ຕົວແທນຈະບໍລິໂພກປະມານ 0,6 vCPUs (ແກນ virtual) ຕໍ່ 1000 ຄໍາຮ້ອງຂໍຕໍ່ວິນາທີ.

ສໍາລັບພາກພື້ນທໍາອິດໃນຕາຫນ່າງການບໍລິການ (2 proxies ໃນແຕ່ລະດ້ານຂອງການເຊື່ອມຕໍ່), ພວກເຮົາຈະມີ 1200 cores ພຽງແຕ່ສໍາລັບຕົວແທນ, ໃນອັດຕາຫນຶ່ງລ້ານຄໍາຮ້ອງຂໍຕໍ່ວິນາທີ. ອີງ​ຕາມ​ການ​ຄິດ​ໄລ່​ຄ່າ​ໃຊ້​ຈ່າຍ​ຂອງ​ກູ​ໂກ​, ມັນ​ເຮັດ​ວຽກ​ອອກ​ເປັນ​ປະ​ມານ $40 / ເດືອນ / ຫຼັກ​ສໍາ​ລັບ​ການ​ຕັ້ງ​ຄ່າ​. n1-standard-64, ນັ້ນແມ່ນ, ພາກພື້ນນີ້ພຽງແຕ່ຈະເສຍຄ່າໃຊ້ຈ່າຍຫຼາຍກວ່າ 50 ພັນໂດລາຕໍ່ເດືອນສໍາລັບ 1 ລ້ານຄໍາຮ້ອງຂໍຕໍ່ວິນາທີ.

Ivan Sim (Ivan Sim) ປຽບທຽບສາຍຕາ service mesh ຊັກຊ້າໃນປີກາຍນີ້ແລະສັນຍາດຽວກັນສໍາລັບຫນ່ວຍຄວາມຈໍາແລະໂປເຊດເຊີ, ແຕ່ມັນບໍ່ໄດ້ຜົນ:

ປາກົດຂື້ນ, values-istio-test.yaml ຈະເພີ່ມການຮ້ອງຂໍ CPU ຢ່າງຈິງຈັງ. ຖ້າຂ້ອຍເຮັດຄະນິດສາດຢ່າງຖືກຕ້ອງ, ທ່ານຕ້ອງການປະມານ 24 CPU cores ສໍາລັບແຜງຄວບຄຸມແລະ 0,5 CPU ສໍາລັບແຕ່ລະຕົວແທນ. ຂ້ອຍບໍ່ມີຫຼາຍ. ຂ້ອຍຈະເຮັດການທົດສອບຄືນອີກເມື່ອຊັບພະຍາກອນເພີ່ມເຕີມຖືກຈັດສັນໃຫ້ຂ້ອຍ.

ຂ້ອຍຢາກເຫັນຕົວເອງວ່າປະສິດທິພາບຂອງ Istio ຄ້າຍຄືກັນກັບຕາໜ່າງບໍລິການແຫຼ່ງເປີດອື່ນແນວໃດ: Linkerd.

ການຕິດຕັ້ງຕາຫນ່າງການບໍລິການ

ກ່ອນອື່ນ ໝົດ, ຂ້ອຍຕິດຕັ້ງມັນຢູ່ໃນກຸ່ມ 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 Engine. ຂ້ອຍໃຊ້ 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 |
+---------+--------------+---------+---------------------------+

ຫຼັງ​ຈາກ​ນັ້ນ​, 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      |
+---------+------------+---------+---------------------------+

ການຂັດຂ້ອງໃຊ້ເວລາສອງສາມນາທີ, ແລະຫຼັງຈາກນັ້ນແຜງຄວບຄຸມໄດ້ສະຖຽນລະພາບ.

(ໝາຍເຫດ: SuperGloo ຮອງຮັບສະເພາະ Istio 1.0.x ເທົ່ານັ້ນ. ຂ້ອຍໄດ້ເຮັດການທົດລອງອີກຄັ້ງກັບ Istio 1.1.3, ແຕ່ບໍ່ໄດ້ສັງເກດເຫັນຄວາມແຕກຕ່າງທີ່ເຫັນໄດ້ຊັດເຈນ.)

ການຕັ້ງຄ່າ Istio ການນຳໃຊ້ອັດຕະໂນມັດ

ເພື່ອເຮັດໃຫ້ Istio ຕິດຕັ້ງ sidecar Envoy, ພວກເຮົາໃຊ້ sidecar injector − MutatingAdmissionWebhook. ພວກເຮົາຈະບໍ່ເວົ້າກ່ຽວກັບມັນໃນບົດຄວາມນີ້. ໃຫ້ຂ້າພະເຈົ້າພຽງແຕ່ເວົ້າວ່ານີ້ແມ່ນຕົວຄວບຄຸມທີ່ຕິດຕາມກວດກາການເຂົ້າເຖິງຂອງຝັກໃຫມ່ທັງຫມົດແລະແບບເຄື່ອນໄຫວເພີ່ມ sidecar ແລະ initContainer, ເຊິ່ງຮັບຜິດຊອບສໍາລັບວຽກງານ. iptables.

ພວກເຮົາຢູ່ Shopify ໄດ້ຂຽນຕົວຄວບຄຸມການເຂົ້າເຖິງຂອງພວກເຮົາເອງເພື່ອປະຕິບັດລົດຂ້າງ, ແຕ່ສໍາລັບມາດຕະຖານນີ້ຂ້າພະເຈົ້າໄດ້ໃຊ້ຕົວຄວບຄຸມທີ່ມາພ້ອມກັບ Istio. ຕົວຄວບຄຸມຈະໃສ່ລົດ sidecars ໂດຍຄ່າເລີ່ມຕົ້ນເມື່ອມີທາງລັດຢູ່ໃນ 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

ຕັ້ງຄ່າການຕິດຕັ້ງ Linkerd ອັດຕະໂນມັດ

ເພື່ອຕັ້ງຄ່າການຝັງ sidecar 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 Fault Tolerance Simulator

ພວກເຮົາໄດ້ສ້າງເຄື່ອງຈຳລອງຄວາມທົນທານຕໍ່ຄວາມຜິດທີ່ເອີ້ນວ່າ Istio ເພື່ອທົດລອງກັບການຈະລາຈອນທີ່ເປັນເອກະລັກຂອງ Shopify. ພວກ​ເຮົາ​ຕ້ອງ​ການ​ເຄື່ອງ​ມື​ໃນ​ການ​ສ້າງ topology ແບບ​ກໍາ​ນົດ​ເອງ​ທີ່​ຈະ​ເປັນ​ຕົວ​ແທນ​ຂອງ​ບາງ​ສ່ວນ​ສະ​ເພາະ​ຂອງ​ກ​ຣາ​ຟ​ການ​ບໍ​ລິ​ການ​ຂອງ​ພວກ​ເຮົາ​, ການ​ຕັ້ງ​ຄ່າ​ແບບ​ເຄື່ອນ​ໄຫວ​ເພື່ອ​ສ້າງ​ແບບ​ຈໍາ​ລອງ​ວຽກ​ງານ​ສະ​ເພາະ​ໃດ​ຫນຶ່ງ​.

ໂຄງສ້າງພື້ນຖານຂອງ Shopify ແມ່ນຢູ່ພາຍໃຕ້ການໂຫຼດຫນັກໃນລະຫວ່າງການຂາຍແຟດ. ໃນເວລາດຽວກັນ, Shopify ແນະນໍາໃຫ້ຜູ້ຂາຍຖືການຂາຍດັ່ງກ່າວເລື້ອຍໆ. ບາງຄັ້ງລູກຄ້າຂະຫນາດໃຫຍ່ເຕືອນກ່ຽວກັບການຂາຍແຟດທີ່ວາງແຜນໄວ້. ຄົນອື່ນປະຕິບັດພວກມັນໂດຍບໍ່ຄາດຄິດສໍາລັບພວກເຮົາທຸກເວລາຂອງມື້ຫຼືກາງຄືນ.

ພວກເຮົາຕ້ອງການເຄື່ອງຈຳລອງຄວາມຢືດຢຸ່ນຂອງພວກເຮົາເພື່ອສ້າງແບບຈໍາລອງຂັ້ນຕອນການເຮັດວຽກທີ່ກົງກັບ topologies ແລະ workloads ທີ່ overwhelmed ໂຄງລ່າງຂອງ Shopify ໃນໄລຍະຜ່ານມາ. ຈຸດປະສົງຕົ້ນຕໍຂອງການນໍາໃຊ້ຕາຫນ່າງການບໍລິການແມ່ນພວກເຮົາຕ້ອງການຄວາມຫນ້າເຊື່ອຖືແລະຄວາມທົນທານຕໍ່ຄວາມຜິດໃນລະດັບເຄືອຂ່າຍ, ແລະມັນເປັນສິ່ງສໍາຄັນສໍາລັບພວກເຮົາທີ່ຕາຫນ່າງການບໍລິການສາມາດຮັບມືກັບການໂຫຼດທີ່ຂັດຂວາງການບໍລິການກ່ອນຫນ້ານີ້.

ຫົວໃຈຂອງເຄື່ອງຈຳລອງຄວາມທົນທານຕໍ່ຄວາມຜິດແມ່ນໂຫນດຂອງຜູ້ອອກແຮງງານ, ເຊິ່ງເຮັດໜ້າທີ່ເປັນແຖບຕາໜ່າງບໍລິການ. ໂນດຜູ້ເຮັດວຽກສາມາດຖືກຕັ້ງຄ່າແບບຄົງທີ່ໃນຕອນເລີ່ມຕົ້ນ ຫຼືແບບເຄື່ອນໄຫວຜ່ານ REST API. ພວກເຮົາໃຊ້ການຕັ້ງຄ່າແບບເຄື່ອນໄຫວຂອງ nodes ພະນັກງານເພື່ອສ້າງຂະບວນການເຮັດວຽກໃນຮູບແບບຂອງການທົດສອບການຖົດຖອຍ.

ນີ້ແມ່ນຕົວຢ່າງຂອງຂະບວນການດັ່ງກ່າວ:

• ພວກເຮົາເປີດຕົວ 10 ເຄື່ອງແມ່ຂ່າຍເປັນ bar ການບໍລິການທີ່ໃຫ້ຄໍາຕອບ 200/OK ຫຼັງຈາກ 100 ms.
• ພວກເຮົາເປີດຕົວລູກຄ້າ 10 ຄົນ - ແຕ່ລະຄົນສົ່ງ 100 ຄໍາຮ້ອງຂໍຕໍ່ວິນາທີໄປຫາ bar.
• ທຸກໆ 10 ວິນາທີພວກເຮົາເອົາ 1 ເຊີບເວີແລະກວດສອບຂໍ້ຜິດພາດ 5xx ກ່ຽວກັບລູກຄ້າ.

ໃນຕອນທ້າຍຂອງຂະບວນການເຮັດວຽກ, ພວກເຮົາກວດເບິ່ງບັນທຶກແລະການວັດແທກແລະກວດເບິ່ງວ່າການທົດສອບຜ່ານ. ວິທີນີ້ພວກເຮົາຮຽນຮູ້ກ່ຽວກັບການປະຕິບັດຂອງຕາຫນ່າງການບໍລິການຂອງພວກເຮົາແລະດໍາເນີນການທົດສອບການຖົດຖອຍເພື່ອທົດສອບສົມມຸດຕິຖານຂອງພວກເຮົາກ່ຽວກັບຄວາມທົນທານຕໍ່ຄວາມຜິດ.

(ໝາຍເຫດ: ພວກເຮົາກຳລັງຄິດກ່ຽວກັບການເປີດແຫຼ່ງທີ່ມາຂອງເຄື່ອງຈຳລອງຄວາມທົນທານຄວາມຜິດ Istio, ແຕ່ຍັງບໍ່ພ້ອມທີ່ຈະເຮັດເທື່ອ.)

ເຄື່ອງຈຳລອງຄວາມທົນທານຕໍ່ຄວາມຜິດ Istio ສໍາລັບມາດຕະຖານຕາໜ່າງການບໍລິການ

ພວກເຮົາຕັ້ງຄ່າຫຼາຍຂໍ້ເຮັດວຽກຂອງ simulator:

• irs-client-loadgen: 3 replicas ທີ່ສົ່ງ 100 ຄໍາຮ້ອງຂໍຕໍ່ວິນາທີຕໍ່ irs-client.
• irs-client: 3 replicas ທີ່ໄດ້ຮັບຄໍາຮ້ອງຂໍ, ລໍຖ້າ 100ms ແລະສົ່ງຕໍ່ຄໍາຮ້ອງຂໍໃຫ້ irs-server.
• irs-server: 3 replicas ທີ່ກັບຄືນມາ 200/OK ຫຼັງຈາກ 100 ms.

ດ້ວຍການຕັ້ງຄ່ານີ້, ພວກເຮົາສາມາດວັດແທກການໄຫຼວຽນຂອງການຈະລາຈອນທີ່ຫມັ້ນຄົງລະຫວ່າງ 9 ຈຸດສິ້ນສຸດ. Sidecars ໃນ irs-client-loadgen и irs-server ໄດ້ຮັບ 100 ຄໍາຮ້ອງຂໍຕໍ່ວິນາທີ, ແລະ irs-client — 200 (ຂາ​ເຂົ້າ​ແລະ​ຂາ​ອອກ​)​.

ພວກເຮົາຕິດຕາມການນໍາໃຊ້ຊັບພະຍາກອນໂດຍຜ່ານ DataDogເພາະວ່າພວກເຮົາບໍ່ມີກຸ່ມ Prometheus.

Результаты

ແຜງຄວບຄຸມ

ກ່ອນອື່ນ ໝົດ, ພວກເຮົາກວດເບິ່ງການບໍລິໂພກ CPU.

ແຜງຄວບຄຸມ Linkerd ~22 millicore

ແຜງຄວບຄຸມ Istio: ~750 millicore

ແຜງຄວບຄຸມ Istio ໃຊ້ປະມານ ຊັບພະຍາກອນ CPU ຫຼາຍກວ່າ 35 ເທົ່າກ່ວາ Linkerd. ແນ່ນອນ, ທຸກສິ່ງທຸກຢ່າງຖືກຕິດຕັ້ງໂດຍຄ່າເລີ່ມຕົ້ນ, ແລະ istio-telemetry ບໍລິໂພກຊັບພະຍາກອນຂອງໂປເຊດເຊີຫຼາຍຢູ່ທີ່ນີ້ (ມັນສາມາດປິດການໃຊ້ງານໄດ້ໂດຍການປິດການທໍາງານບາງຢ່າງ). ຖ້າພວກເຮົາເອົາອົງປະກອບນີ້ອອກ, ພວກເຮົາຍັງໄດ້ຮັບຫຼາຍກ່ວາ 100 millicores, ນັ້ນແມ່ນ 4 ເທື່ອຂື້ນໄປກ່ວາ Linkerd.

Sidecar proxy

ຫຼັງຈາກນັ້ນ, ພວກເຮົາທົດສອບການນໍາໃຊ້ຕົວແທນ. ຄວນຈະມີຄວາມສໍາພັນທາງເສັ້ນກັບຈໍານວນຄໍາຮ້ອງຂໍ, ແຕ່ສໍາລັບແຕ່ລະ sidecar ມີບາງສ່ວນເກີນທີ່ມີຜົນກະທົບຕໍ່ເສັ້ນໂຄ້ງ.

Linkerd: ~100 millicores ສໍາລັບ irs-client, ~50 millicores ສໍາລັບ irs-client-loadgen

ຜົນໄດ້ຮັບເບິ່ງຄືວ່າມີເຫດຜົນ, ເພາະວ່າຕົວແທນລູກຄ້າໄດ້ຮັບການຈະລາຈອນສອງເທົ່າຂອງ proxy loadgen: ສໍາລັບທຸກໆຄໍາຮ້ອງຂໍທີ່ອອກມາຈາກ loadgen, ລູກຄ້າມີຫນຶ່ງຂາເຂົ້າແລະຫນຶ່ງຂາອອກ.

Istio/Envoy: ~155 millicores ສໍາລັບ irs-client, ~75 millicores ສໍາລັບ irs-client-loadgen

ພວກເຮົາເຫັນຜົນໄດ້ຮັບທີ່ຄ້າຍຄືກັນສໍາລັບລົດຂ້າງ Istio.

ແຕ່ໂດຍທົ່ວໄປ, Istio/Envoy proxies ບໍລິໂພກ ປະມານ 50% ຊັບພະຍາກອນ CPU ຫຼາຍກ່ວາ Linkerd.

ພວກເຮົາເຫັນໂຄງການດຽວກັນຢູ່ຂ້າງເຊີບເວີ:

Linkerd: ~50 millicore ສໍາລັບ irs-server

Istio/Envoy: ~80 millicore ສໍາລັບ irs-server

ໃນດ້ານເຊີບເວີ, ຂ້າງລົດ Istio/Envoy ບໍລິໂພກ ປະມານ 60% ຊັບພະຍາກອນ CPU ຫຼາຍກ່ວາ Linkerd.

ສະຫລຸບ

ຕົວແທນ Istio Envoy ໃຊ້ CPU ຫຼາຍກວ່າ Linkerd 50+% ໃນວຽກທີ່ຈຳລອງຂອງພວກເຮົາ. ແຜງຄວບຄຸມ Linkerd ໃຊ້ຊັບພະຍາກອນຫນ້ອຍກວ່າ Istio, ໂດຍສະເພາະສໍາລັບອົງປະກອບຫຼັກ.

ພວກເຮົາຍັງຄິດກ່ຽວກັບວິທີການຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍເຫຼົ່ານີ້. ຖ້າທ່ານມີຄວາມຄິດ, ກະລຸນາແບ່ງປັນ!

ແຫຼ່ງຂໍ້ມູນ: www.habr.com