Istio ve Linkerd için CPU tüketimi karşılaştırması

Giriş

Biz Shopify Istio'yu bir hizmet ağı olarak dağıtmaya başladı. Prensip olarak, bir şey dışında her şey yolunda: Bu pahalı.

В yayınlanan kıyaslamalar Istio için şöyle diyor:

Istio 1.1 ile proxy, saniyede 0,6 istek başına yaklaşık 1000 vCPU (sanal çekirdek) tüketir.

Hizmet ağındaki ilk bölge için (bağlantının her iki tarafında 2 proxy), saniyede bir milyon istek hızında, yalnızca proxy için 1200 çekirdeğe sahip olacağız. Google'ın maliyet hesaplayıcısına göre, yapılandırma için yaklaşık 40$/ay/çekirdek çıkıyor n1-standard-64yani tek başına bu bölge bize saniyede 50 milyon istek için ayda 1 bin dolardan fazlaya mal olacak.

Ivan Sim (Ivan Sim) görsel olarak karşılaştırıldı Service Mesh geçen yıl gecikme yaşadı ve bellek ve işlemci için de aynısını vaat etti ancak işe yaramadı:

Görünüşe göre, value-istio-test.yaml CPU isteklerini ciddi şekilde artıracak. Eğer matematiğimi doğru yaptıysam, kontrol paneli için yaklaşık 24 CPU çekirdeğine ve her proxy için 0,5 CPU'ya ihtiyacınız var. Bende o kadar yok. Bana daha fazla kaynak tahsis edildiğinde testleri tekrarlayacağım.

Istio'nun performansının başka bir açık kaynak hizmet ağına ne kadar benzer olduğunu kendim görmek istedim: Bağlayıcı.

Servis ağı kurulumu

Öncelikle onu bir kümeye kurdum SüperGloo:

$ 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'yu kullandım çünkü servis ağını önyüklemeyi çok daha kolay hale getiriyor. Fazla bir şey yapmama gerek yoktu. SuperGloo'yu üretimde kullanmıyoruz ancak bu tür bir görev için idealdir. Her hizmet ağı için kelimenin tam anlamıyla birkaç komut kullanmak zorunda kaldım. Yalıtım için iki küme kullandım - her biri Istio ve Linkerd için.

Deney Google Kubernetes Engine'de gerçekleştirildi. Kubernetes'i kullandım 1.12.7-gke.7 ve bir düğüm havuzu n1-standard-4 otomatik düğüm ölçeklendirme ile (minimum 4, maksimum 16).

Daha sonra her iki servis ağını da komut satırından kurdum.

İlk Linkerd:

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

Kilitlenme döngüsü birkaç dakika sürdü ve ardından kontrol panelleri stabil hale geldi.

(Not: SuperGloo şimdilik yalnızca Istio 1.0.x'i desteklemektedir. Deneyi Istio 1.1.3 ile tekrarladım ancak gözle görülür bir fark fark etmedim.)

Istio Otomatik Dağıtımı Ayarlama

Istio'nun sepet Elçisini kurmasını sağlamak için sepet enjektörünü kullanıyoruz - MutatingAdmissionWebhook. Bu yazıda bundan bahsetmeyeceğiz. Bunun, tüm yeni bölmelerin erişimini izleyen ve görevlerden sorumlu olan bir sepet ve initContainer'ı dinamik olarak ekleyen bir denetleyici olduğunu söylememe izin verin. iptables.

Biz Shopify olarak sepetleri uygulamak için kendi erişim denetleyicimizi yazdık, ancak bu karşılaştırma için Istio ile birlikte gelen denetleyiciyi kullandım. Ad alanında bir kısayol olduğunda denetleyici varsayılan olarak sepetleri enjekte eder 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

Otomatik Linkerd dağıtımını ayarlama

Linkerd sepet yerleştirmeyi ayarlamak için ek açıklamalar kullanıyoruz (bunları manuel olarak ekledim) 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 Arıza Toleransı Simülatörü

Shopify'a özgü trafiği denemek için Istio adında bir hata toleransı simülatörü oluşturduk. Hizmet grafiğimizin belirli bir bölümünü temsil edecek, belirli iş yüklerini modellemek üzere dinamik olarak yapılandırılmış özel bir topoloji oluşturmak için bir araca ihtiyacımız vardı.

Shopify'ın altyapısı flaş satışlar sırasında ağır yük altındadır. Aynı zamanda Shopify'da satıcılara bu tür satışları daha sık yapmalarını tavsiye ediyor. Büyük müşteriler bazen planlı bir flaş satış konusunda uyarıda bulunur. Diğerleri bunları bizim için beklenmedik bir şekilde günün veya gecenin herhangi bir saatinde gerçekleştirir.

Dayanıklılık simülatörümüzün, geçmişte Shopify'ın altyapısını zorlayan topolojiler ve iş yükleriyle eşleşen iş akışlarını modellemesini istedik. Hizmet ağını kullanmanın temel amacı, ağ düzeyinde güvenilirliğe ve hata toleransına ihtiyaç duymamızdır ve hizmet ağının daha önce hizmetleri kesintiye uğratan yüklerle etkili bir şekilde başa çıkabilmesi bizim için önemlidir.

Hata toleransı simülatörünün kalbinde, hizmet ağ düğümü görevi gören bir çalışan düğüm bulunur. Çalışan düğüm, başlangıçta statik olarak veya bir REST API aracılığıyla dinamik olarak yapılandırılabilir. Regresyon testleri biçiminde iş akışları oluşturmak için çalışan düğümlerin dinamik yapılandırmasını kullanıyoruz.

İşte böyle bir sürecin bir örneği:

• 10 sunucuyu şu şekilde başlatıyoruz: bar yanıt döndüren hizmet 200/OK 100 ms sonra.
• 10 istemci başlatıyoruz - her biri saniyede 100 istek gönderiyor bar.
• Her 10 saniyede bir 1 sunucuyu kaldırıyoruz ve hataları izliyoruz 5xx istemcide.

İş akışının sonunda logları ve metrikleri inceleyerek testin başarılı olup olmadığını kontrol ediyoruz. Bu şekilde hizmet ağımızın performansı hakkında bilgi edinir ve hata toleransına ilişkin varsayımlarımızı test etmek için bir regresyon testi gerçekleştiririz.

(Not: Istio hata toleransı simülatörünü açık kaynak olarak kullanmayı düşünüyoruz ancak bunu yapmaya henüz hazır değiliz.)

Servis ağı karşılaştırması için Istio hata toleransı simülatörü

Simülatörün birkaç çalışma düğümünü kurduk:

• irs-client-loadgen: Saniyede 3 istek gönderen 100 kopya irs-client.
• irs-client: İsteği alan 3 kopya, 100 ms bekleyip isteği iletin irs-server.
• irs-server: Geri dönen 3 kopya 200/OK 100 ms sonra.

Bu konfigürasyonla 9 uç nokta arasında stabil bir trafik akışını ölçebiliyoruz. Sepetler irs-client-loadgen и irs-server saniyede 100 istek alır ve irs-client — 200 (gelen ve giden).

Kaynak kullanımını şu şekilde takip ediyoruz: DataDogçünkü bir Prometheus kümemiz yok.

Bulgular

Kontrol panelleri

İlk olarak CPU tüketimini inceledik.

Linkerd kontrol paneli ~22 milicore

Istio kontrol paneli: ~750 milicore

Istio kontrol paneli yaklaşık olarak 35 kat daha fazla CPU kaynağıLinkerd'den daha. Elbette her şey varsayılan olarak kurulur ve istio-telemetry burada çok fazla işlemci kaynağı tüketir (bazı işlevler devre dışı bırakılarak devre dışı bırakılabilir). Bu bileşeni kaldırırsak yine 100 milicoredan fazlasını elde ederiz, yani 4 kat daha fazlaLinkerd'den daha.

Sepet proxy'si

Daha sonra proxy kullanımını test ettik. İsteklerin sayısıyla doğrusal bir ilişki olmalıdır, ancak her sepet için eğriyi etkileyen bir miktar ek yük vardır.

Linkerd: irs-client için ~100 milicore, irs-client-loadgen için ~50 milicore

Sonuçlar mantıklı görünüyor, çünkü istemci proxy'si loadgen proxy'sinden iki kat daha fazla trafik alıyor: loadgen'den giden her istek için istemcinin bir gelen ve bir giden isteği var.

Istio/Elçi: irs-client için ~155 milicore, irs-client-loadgen için ~75 millicore

Istio sepetleri için de benzer sonuçlar görüyoruz.

Ancak genel olarak Istio/Elçi proxy'leri tüketiyor yaklaşık %50 daha fazla CPU kaynağıLinkerd'den daha.

Aynı şemayı sunucu tarafında da görüyoruz:

Linkerd: ~50 milicore kendi sunucusu için

Istio/Elçi: kendi sunucusu için ~80 milicore

Sunucu tarafında sepet Istio/Elçi tüketir yaklaşık %60 daha fazla CPU kaynağıLinkerd'den daha.

Sonuç

Istio Elçi proxy'si, simüle edilmiş iş yükümüzde Linkerd'den %50'den fazla CPU tüketir. Linkerd kontrol paneli, özellikle temel bileşenler açısından Istio'ya göre çok daha az kaynak tüketir.

Halen bu maliyetleri nasıl düşürürüz diye düşünüyoruz. Fikirleriniz varsa lütfen paylaşın!

Kaynak: habr.com