Танилцуулга
Бид орж байна Istio-г үйлчилгээний тор болгон байрлуулж эхлэв. Зарчмын хувьд бүх зүйл зүгээр, нэг зүйлээс бусад нь: энэ үнэтэй юм.
В Истиогийн хувьд энэ нь:
Istio 1.1-ийн тусламжтайгаар прокси нь секундэд 0,6 хүсэлт тутамд ойролцоогоор 1000 vCPU (виртуал цөм) зарцуулдаг.
Үйлчилгээний сүлжээн дэх эхний бүсийн хувьд (холболтын тал бүр дээр 2 прокси) бид зөвхөн проксид зориулсан 1200 цөмтэй байх бөгөөд секундэд нэг сая хүсэлт илгээх болно. Google-ийн зардлын тооцоолуурын дагуу энэ нь тохируулга хийхэд ойролцоогоор 40 доллар/сар/ цөм байх болно. n1-standard-64, өөрөөр хэлбэл энэ бүс нутаг л гэхэд секундэд 50 сая хүсэлт гаргахад сард 1 мянга гаруй долларын зардал гарах болно.
Иван Сим () Өнгөрсөн жил үйлчилгээний торны саатал гарсан бөгөөд санах ой болон процессорын хувьд ч мөн адил амласан боловч бүтсэнгүй:
values-istio-test.yaml нь CPU-ийн хүсэлтийг ноцтойгоор нэмэгдүүлэх бололтой. Хэрэв би тооцоогоо зөв хийсэн бол хяналтын самбарт ойролцоогоор 24 CPU цөм, прокси тус бүрт 0,5 CPU хэрэгтэй болно. Надад тийм их зүйл байхгүй. Надад илүү их нөөц хуваарилагдах үед би туршилтыг давтах болно.
Istio-ийн гүйцэтгэл нь өөр нэг нээлттэй эхийн үйлчилгээний сүлжээтэй хэр төстэй болохыг би өөрөө харахыг хүссэн: .
Үйлчилгээний тор суурилуулах
Юуны өмнө би үүнийг кластерт суулгасан :
$ 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 |
+---------+--------------+---------+---------------------------+Дараа нь Истио:
$ 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 Automatic Deployment-ийг тохируулж байна
Istio-г Envoy-ийн хажуугийн тэрэг суурилуулахын тулд бид хажуугийн тэрэгний форсункийг ашигладаг MutatingAdmissionWebhook. Энэ нийтлэлд бид энэ тухай ярихгүй. Энэ бол бүх шинэ pods-ийн хандалтыг хянаж, даалгаврыг хариуцдаг хажуугийн тэрэг болон 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 байршуулалтыг тохируулж байна
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: ActiveIstio Fault Tolerance Simulator
Бид Shopify-д зориулсан траффикийг туршихын тулд Istio нэртэй алдааг тэсвэрлэх симулятор бүтээсэн. Манай үйлчилгээний графикийн тодорхой хэсгийг төлөөлөх, тодорхой ажлын ачааллыг загварчлахаар динамикаар тохируулсан өөрчлөн топологийг бий болгох хэрэгсэл бидэнд хэрэгтэй байсан.
Shopify-ийн дэд бүтэц флаш борлуулалтын үеэр ачаалал ихтэй байдаг. Үүний зэрэгцээ, Shopify . Томоохон худалдан авагчид заримдаа төлөвлөсөн флаш хямдралын талаар анхааруулдаг. Бусад нь өдөр, шөнийн аль ч цагт бидний төлөө санаандгүй байдлаар үүнийг хийдэг.
Урьд нь Shopify-ийн дэд бүтцийг дарж байсан топологи болон ажлын ачаалалд тохирсон ажлын урсгалыг загварчлахыг бид уян хатан байдлын симулятораа хүссэн. Үйлчилгээний торыг ашиглах гол зорилго нь бидэнд сүлжээний түвшинд найдвартай байдал, алдааг тэсвэрлэх чадвартай байх шаардлагатай бөгөөд үйлчилгээний тор нь өмнө нь үйлчилгээг тасалдуулж байсан ачааллыг үр дүнтэй даван туулах нь бидний хувьд чухал юм.
Гэмтлийг тэсвэрлэх симуляторын гол цөм нь ажилчны зангилаа бөгөөд энэ нь үйлчилгээний торны зангилааны үүргийг гүйцэтгэдэг. Ажилчны зангилааг эхлүүлэх үед статик байдлаар эсвэл REST API-ээр динамикаар тохируулах боломжтой. Бид регрессийн тест хэлбэрээр ажлын урсгалыг бий болгохын тулд ажилчдын зангилааны динамик тохиргоог ашигладаг.
Ийм үйл явцын жишээ энд байна:
- Бид 10 сервер ажиллуулдаг
barхариу өгдөг үйлчилгээ200/OK100 мс-ийн дараа. - Бид 10 үйлчлүүлэгч ажиллуулдаг бөгөөд тус бүр нь секундэд 100 хүсэлт илгээдэг
bar. - 10 секунд тутамд бид 1 серверийг устгаж, алдааг хянадаг
5xxүйлчлүүлэгч дээр.
Ажлын урсгалын төгсгөлд бид бүртгэл, хэмжигдэхүүнийг шалгаж, шалгалтад тэнцсэн эсэхийг шалгана. Ингэснээр бид үйлчилгээний торны гүйцэтгэлийн талаар суралцаж, алдааны хүлцлийн талаарх таамаглалыг шалгахын тулд регрессийн тестийг ажиллуулдаг.
(Тэмдэглэл: Бид Istio алдааг тэсвэрлэх симуляторыг нээлттэй эх үүсвэртэй болгох талаар бодож байгаа боловч хараахан үүнийг хийхэд бэлэн биш байна.)
Үйлчилгээний торон жишигт зориулсан Istio алдааг тэсвэрлэх симулятор
Бид симуляторын хэд хэдэн ажлын зангилаануудыг суурилуулсан:
irs-client-loadgen: Секундэд 3 хүсэлт илгээдэг 100 хуулбарirs-client.irs-client: Хүсэлтийг хүлээн авсан 3 хуулбар, 100 мс хүлээгээд хүсэлтийг илгээнэ үүirs-server.irs-server: Буцах 3 хуулбар200/OK100 мс-ийн дараа.
Энэхүү тохиргооны тусламжтайгаар бид 9 цэгийн хоорондох тогтвортой хөдөлгөөний урсгалыг хэмжиж чадна. Хажуугийн машинууд irs-client-loadgen и irs-server секундэд 100 хүсэлт хүлээн авах, мөн irs-client — 200 (орж байгаа болон гарах).
Бид нөөцийн ашиглалтыг хянадаг Учир нь бидэнд Prometheus кластер байхгүй.
Результаты
Хяналтын самбар
Эхлээд бид CPU-ийн хэрэглээг шалгасан.
Linkerd хяналтын самбар ~22 миллиcore
Istio хяналтын самбар: ~750 миллиcore
Istio хяналтын самбар нь ойролцоогоор ашигладаг 35 дахин их CPU-ийн нөөцЛинкердээс илүү. Мэдээжийн хэрэг, бүх зүйлийг анхдагчаар суулгасан бөгөөд istio-temetry нь энд процессорын маш их нөөцийг зарцуулдаг (зарим функцийг идэвхгүй болгосноор үүнийг идэвхгүй болгож болно). Хэрэв бид энэ бүрэлдэхүүн хэсгийг хасвал 100 гаруй милликорыг авах болно, өөрөөр хэлбэл 4 дахин ихЛинкердээс илүү.
Хажуугийн прокси
Дараа нь бид прокси ашиглахыг туршиж үзсэн. Хүсэлтийн тоотой шугаман хамаарал байх ёстой, гэхдээ хажуугийн тэрэг бүрийн хувьд муруйд нөлөөлдөг зарим нэмэлт зардал байдаг.
Linkerd: irs-client-д ~100 милликор, irs-client-loadgen-д ~50 милликор
Үйлчлүүлэгчийн прокси нь loadgen прокси-ээс хоёр дахин их траффик хүлээн авдаг тул үр дүн нь логик харагдаж байна: loadgen-аас илгээсэн хүсэлт бүрт үйлчлүүлэгч нэг ирж, нэг гарч байгаа.
Istio/Envoy: irs-client-д ~155 милликор, irs-client-loadgen-д ~75 милликор
Бид Istio хажуу тэрэгний ижил төстэй үр дүнг харж байна.
Гэхдээ ерөнхийдөө Istio/Envoy прокси хэрэглэдэг ойролцоогоор 50% илүү CPU-ийн нөөцЛинкердээс илүү.
Бид серверийн тал дээр ижил схемийг харж байна:
Linkerd: irs серверийн хувьд ~50 миллиcore
Istio/Envoy: irs-серверийн хувьд ~80 миллиcore
Сервер тал дээр хажуугийн тэрэг Istio/Envoy ашигладаг ойролцоогоор 60% илүү CPU-ийн нөөцЛинкердээс илүү.
дүгнэлт
Istio Envoy прокси нь бидний загварчилсан ажлын ачаалал дээр Linkerd-ээс 50+%-иар илүү CPU зарцуулдаг. Linkerd хяналтын самбар нь Istio-ээс хамаагүй бага нөөц зарцуулдаг, ялангуяа үндсэн бүрэлдэхүүн хэсгүүдийн хувьд.
Энэ зардлаа яаж бууруулах вэ гэж бодож байгаа. Хэрэв танд санаа байвал хуваалцаарай!
Эх сурвалж: www.habr.com