Giriş
İçindəyik Istio-nu xidmət şəbəkəsi kimi yerləşdirməyə başladı. Prinsipcə, bir şey istisna olmaqla, hər şey yaxşıdır: Bu bahadır.
В Istio üçün deyir:
Istio 1.1 ilə proksi saniyədə 0,6 sorğu üçün təxminən 1000 vCPU (virtual nüvələr) istehlak edir.
Xidmət şəbəkəsindəki ilk bölgə üçün (bağlantının hər tərəfində 2 proksi), saniyədə bir milyon sorğu sürəti ilə yalnız proxy üçün 1200 nüvəyə sahib olacağıq. Google-un xərc kalkulyatoruna görə, konfiqurasiya üçün ayda təxminən 40 dollardır. n1-standard-64, yəni təkcə bu bölgə saniyədə 50 milyon sorğu üçün bizə ayda 1 min dollardan çox başa gələcək.
İvan Sim () xidmət şəbəkəsi keçən il gecikmələrə səbəb oldu və yaddaş və prosessor üçün eyni şeyi vəd etdi, lakin alınmadı:
Göründüyü kimi, values-istio-test.yaml CPU sorğularını ciddi şəkildə artıracaq. Riyaziyyatımı düzgün yerinə yetirmişəmsə, sizə idarəetmə paneli üçün təxminən 24 CPU nüvəsi və hər proxy üçün 0,5 CPU lazımdır. Məndə o qədər də yoxdur. Mənə daha çox resurs ayrılanda testləri təkrarlayacağam.
Istio-nun performansının başqa bir açıq mənbəli xidmət şəbəkəsinə nə qədər bənzədiyini özüm görmək istədim: .
Xidmət şəbəkəsinin quraşdırılması
İlk növbədə onu klasterdə quraşdırdım :
$ 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!Mən SuperGloo-dan istifadə etdim, çünki bu, xidmət şəbəkəsini yükləməyi çox asanlaşdırır. Çox şey etməli deyildim. Biz istehsalda SuperGloo-dan istifadə etmirik, lakin belə bir iş üçün idealdır. Hər xidmət şəbəkəsi üçün sözün əsl mənasında bir neçə əmrdən istifadə etməli oldum. İzolyasiya üçün iki klasterdən istifadə etdim - hər biri Istio və Linkerd üçün.
Təcrübə Google Kubernetes Engine-də aparılıb. Kubernetes istifadə etdim 1.12.7-gke.7 və qovşaqlar hovuzu n1-standard-4 avtomatik node miqyası ilə (minimum 4, maksimum 16).
Sonra hər iki xidmət şəbəkəsini komanda xəttindən quraşdırdım.
Birinci Bağlayıcı:
$ 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 |
+---------+--------------+---------+---------------------------+Sonra 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 |
+---------+------------+---------+---------------------------+Qəza-döngə bir neçə dəqiqə çəkdi, sonra idarəetmə panelləri sabitləşdi.
(Qeyd: SuperGloo hələlik yalnız Istio 1.0.x-i dəstəkləyir. Təcrübəni Istio 1.1.3 ilə təkrarladım, lakin nəzərəçarpacaq fərq görmədim.)
Istio Avtomatik Yerləşdirmənin qurulması
Istio-nun yan arabası Envoy quraşdırması üçün biz yan arabanın injektorundan istifadə edirik - MutatingAdmissionWebhook. Bu məqalədə bu barədə danışmayacağıq. Sadəcə onu deyim ki, bu, bütün yeni podların girişinə nəzarət edən və tapşırıqlara cavabdeh olan bir yan araba və initContainer əlavə edən bir nəzarətçidir. iptables.
Biz Shopify-da yan avtomobilləri tətbiq etmək üçün öz giriş nəzarət cihazımızı yazdıq, lakin bu meyar üçün Istio ilə gələn nəzarətçidən istifadə etdim. Adlar sahəsində qısa yol olduqda nəzarətçi defolt olaraq yan arabaları yeridir 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 labeledAvtomatik Linkerd yerləşdirməsinin qurulması
Linkerd yan arabanın yerləşdirilməsini qurmaq üçün annotasiyalardan istifadə edirik (onları əl ilə əlavə etdim 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-a xas olan trafiklə sınaqdan keçirmək üçün Istio adlı xətaya dözümlülük simulyatoru yaratdıq. Xüsusi iş yüklərini modelləşdirmək üçün dinamik şəkildə konfiqurasiya edilmiş xidmət qrafikimizin müəyyən hissəsini təmsil edən fərdi topologiya yaratmaq üçün alətə ehtiyacımız var idi.
Flaş satışları zamanı Shopify infrastrukturu ağır yük altındadır. Eyni zamanda, Shopify . Böyük müştərilər bəzən planlaşdırılan flaş satış barədə xəbərdarlıq edirlər. Digərləri onları bizim üçün gecənin və ya günün istənilən vaxtında gözlənilmədən həyata keçirirlər.
Biz davamlılıq simulyatorumuzun keçmişdə Shopify infrastrukturunu aşmış topologiyalara və iş yüklərinə uyğun gələn iş axınlarını modelləşdirməsini istəyirdik. Xidmət şəbəkəsindən istifadənin əsas məqsədi odur ki, bizə şəbəkə səviyyəsində etibarlılıq və nasazlıqlara dözümlülük lazımdır və bizim üçün xidmət şəbəkəsinin əvvəllər xidmətləri pozan yüklərin öhdəsindən səmərəli şəkildə çıxması vacibdir.
Arızaya dözümlülük simulyatorunun mərkəzində xidmət şəbəkəsi qovşağı kimi çıxış edən işçi qovşağı dayanır. İşçi qovşağı başlanğıcda statik olaraq və ya REST API vasitəsilə dinamik olaraq konfiqurasiya edilə bilər. Reqressiya testləri şəklində iş axınları yaratmaq üçün işçi qovşaqlarının dinamik konfiqurasiyasından istifadə edirik.
Belə bir prosesə bir nümunə:
- 10 server olaraq işə salırıq
barcavab qaytaran xidmət200/OK100 ms sonra. - Biz 10 müştəri işə salırıq - hər biri saniyədə 100 sorğu göndərir
bar. - Hər 10 saniyədən bir biz 1 serveri silir və xətalara nəzarət edirik
5xxmüştəri üzərində.
İş prosesinin sonunda qeydləri və ölçüləri yoxlayırıq və testin keçib-keçmədiyini yoxlayırıq. Bu yolla biz xidmət şəbəkəmizin performansı haqqında öyrənirik və nasazlığa dözümlülük haqqında fərziyyələrimizi yoxlamaq üçün reqressiya testi keçiririk.
(Qeyd: Biz Istio nasazlıqlara dözümlülük simulyatorunun açıq mənbəli olmasını düşünürük, lakin hələ bunu etməyə hazır deyilik.)
Xidmət mesh etalon üçün Istio xətaya dözümlülük simulyatoru
Simulyatorun bir neçə işçi qovşağını qurduq:
irs-client-loadgen: saniyədə 3 sorğu göndərən 100 replikairs-client.irs-client: Sorğunu qəbul edən 3 replika, 100 ms gözləyin və sorğunu göndərinirs-server.irs-server: Qayıdan 3 replika200/OK100 ms sonra.
Bu konfiqurasiya ilə biz 9 son nöqtə arasında sabit trafik axını ölçə bilərik. İçəridə yan avtomobillər irs-client-loadgen и irs-server saniyədə 100 sorğu almaq və irs-client — 200 (gələn və gedən).
Biz vasitəsilə resurs istifadəsini izləyirik çünki bizdə Prometey klasteri yoxdur.
Tapıntılar
İdarə panelləri
Əvvəlcə CPU istehlakını araşdırdıq.
Linkerd idarəetmə paneli ~22 millicore
Istio idarəetmə paneli: ~750 millicore
Istio idarəetmə paneli təxminən istifadə edir 35 dəfə daha çox CPU resurslarıLinkerddən daha çox. Əlbəttə ki, hər şey standart olaraq quraşdırılıb və istio-temetriya burada çoxlu prosessor resurslarını sərf edir (bəzi funksiyaları söndürməklə onu söndürmək olar). Bu komponenti çıxarsaq, yenə də 100-dən çox millikor alırıq, yəni 4 dəfə çoxdurLinkerddən daha çox.
Sidecar proxy
Daha sonra proxy-nin istifadəsini sınaqdan keçirdik. Müraciətlərin sayı ilə xətti əlaqə olmalıdır, lakin hər bir yan vaqon üçün əyriyə təsir edən bir az üst yük var.
Linkerd: irs-müştəri üçün ~100 millicores, irs-client-loadgen üçün ~50 millicores
Nəticələr məntiqli görünür, çünki müştəri proksisi loadgen proksi ilə müqayisədə iki dəfə çox trafik alır: loadgen-dən hər gedən sorğu üçün müştərinin bir gələn və bir çıxışı olur.
Istio/Envoy: irs-client üçün ~155 millicores, ~75 millicores for irs-client-loadgen
Istio yan avtomobilləri üçün də oxşar nəticələri görürük.
Ancaq ümumiyyətlə, Istio/Envoy proksiləri istehlak edir təxminən 50% daha çox CPU resurslarıLinkerddən daha çox.
Eyni sxemi server tərəfində görürük:
Linkerd: irs-server üçün ~50 millicore
Istio/Envoy: irs-server üçün ~80 millicore
Server tərəfində yan araba Istio/Envoy istehlak edir təxminən 60% daha çox CPU resurslarıLinkerddən daha çox.
Nəticə
Istio Envoy proksi simulyasiya edilmiş iş yükümüzdə Linkerd-dən 50+% daha çox CPU istehlak edir. Linkerd idarəetmə paneli xüsusilə əsas komponentlər üçün Istio-dan daha az resurs istehlak edir.
Biz hələ də bu xərcləri necə azaltmaq barədə düşünürük. Fikirləriniz varsa, paylaşın!
Mənbə: www.habr.com