CPU consummatio Probatio Istio et Linkerd

introduction

Nos sumus in Shopify incepit disponere Istio quasi reticulum muneris. In principio, omnia denique sunt praeter unum; est pretiosa.

В published benchmarks pro Istio inquit;

Cum Istio 1.1, procurator circiter 0,6 vCPUs (coros virtualis) per 1000 petitiones secundas consumit.

Primae enim regionis in ministerio reticuli (2 proxies in utraque parte nexus), tantum pro procuratorio habebimus 1200 coros, ad ratem unius miliones petitionum per secundam. Secundum calculatorem Google sumptus, operatur ut circiter $40/mense/core pro configuratione n1-standard-64hoc est, haec sola regio nobis plus quam 50 milia dollariorum per mensem pro 1 decies petitionibus secundorum constabit.

Ivan Sim (Ivan Sim) uisum comparari reticulum muneris anno praeterito moras promittens idem pro memoria et processu, sed non elaboravit:

Ut videtur, valores-istio-test.yaml petitiones CPU serio augebunt. Si mathematicam meam recte feci, circiter 24 CPU coros debes pro panelli potestate et 0,5 CPU pro quolibet procuratorio. Non multum habeo. Experimenta repetam cum plures facultates mihi partita sunt.

Volui mihi videre quam similis Istio agendi ratio sit ad alium fontem apertum muneris reticuli; Linkerd.

Service reticulum institutionem

Imprimis illud in botro institui 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 usus sum, quia multo facilius reticulum ad ministerium facit Bootstrapping. Multum non habeo. SuperGloo in productione non utimur, sed talis negotii ratio est. Habui ad litteram in duobus praeceptis pro singulis servitiis reticulum. Duobus racemis solitarii usus sum, alter pro Istio et Linkerd.

Experimentum in Google Kubernetes Engine gestum est. Ego Kubernetes 1.12.7-gke.7 et stagnum lymphaticorum n1-standard-4 nodi scalae latae (minimum 4, maximum 16).

Tum ego utrumque officium retibus ex mandato versus institui.

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

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

Fragor-loop pauca minuta cepit ac deinde imperium tabulae confirmatae sunt.

(Nota: SuperGloo nunc tantum sustinet Istio 1.0.x. Experimentum repetivi cum Istio 1.1.3, sed differentiam notabilem non observavit).

Istio automatic instruere

Ut Istio institutionem sidecaram Internuntius efficiat, injector sidecar utimur MutatingAdmissionWebhook. Nolumus de ea in hoc articulo loqui. Modo dicam hoc esse moderatorem monitorem accessum omnium siliquarum novarum et dynamice addito sidecaro et initContainer, quod est officiorum officiorum. iptables.

Nos apud Shopify scripsimus nostrum accessum moderatoris ad latera efficiendi, sed ad hoc probatorium usus sum moderatoris qui cum Istio venit. Moderator sidecars defaltam inicit cum brevis in spatio nominali 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

Profecti sunt automatic Linkerd deployment

Ut in Linkerd sidecar embedding erigatur, annotationes utimur (illas manually per addidi 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 Grand Tolerantia simulator

Simulator appellatus Istio ad experimentum cum negotiationis singulare ad Shopify culpam tolerantiae aedificavimus. Opus nobis est instrumentum ad conficiendam topologiam consuetudinem, quae certa portio graphi servitii nostri repraesentaret, dynamice conformatus ad operas specificas conformandas.

Shopify's infrastructure sub gravi onere sub mico venditio est. Simul, Shopify commendat venditores ad tales venditiones saepius. Magnae clientes interdum de mico vendito meditato monent. Alii de improviso unquam diei noctisve nobis deducunt.

Simulatorem invictum nostrum voluimus fingere operas quae sunt topologiae et laboribus quae in praeterito tempore infrastructuram Shopify obruerunt. Praecipuum propositum usus reticuli servitii est quod fidem et culpam tolerantiae in retis gradu egimus, et interest nobis efficaciter reticulum obsequium cum oneribus quae antea officia turbaverant.

In corde culpae tolerantiae nodi est operarius operarius, qui quasi reticulum nodi agit. Nodus operarius in satus vel dynamice per quietem API figurari potest. Configuratione nodis laborantis dynamica utimur ad workflus creandos in forma regressionis probat.

Hic est talis processus exemplum.

• Dedimus X servers ut bar ministerium quod refert responsionem 200/OK poft C ma.
• X clientes deducunt - C per singula petitiones mittit secundo to bar.
• Omnis X seconds removemus 10 server et monitor errores 5xx in clientelam.

In fine operis, trabes et metricas examinamus et inspicimus an experimentum factum sit. Hoc modo discimus circa reticulum servitutis nostrae perficiendum et currendum regressionis experimentum ad probationes nostras suppositiones de culpa tolerantiae.

(Nota: Nos de Istio culpa tolerantiae simulatoris in aperto transnacente cogitamus, sed nondum parati sumus).

Istitio culpae tolerantiae simulator pro reticulum officii Probatio

Plures nodos simulatoris operantes instituimus;

• irs-client-loadgen: 3 replicas quae 100 petitiones per secundo per . miserunt irs-client.
• irs-client: 3 replicas quae petuntur, 100ms expecta et instantiam propone irs-server.
• irs-server: 3 replicas quae reditus 200/OK poft C ma.

Hac configuratione, metiri possumus stabilitatem negotiationis inter 9 terminos fluere. Sidecars in irs-client-loadgen и irs-server petitiones recipere C secundo per, et irs-client — 200 (venientis et exitu).

Nos resource usus per track DataDogquia Prometheum botrum non habemus.

Результаты

imperium tabulata

Primum investigavimus CPU consummationem.

Linkerd imperium panel ~22 millicore

Istio imperium panel: ~ 750 millicore

Istio imperium panel utitur circiter 35 plus CPU opibusquam Linkerd. Utique, omnia per defaltam instituuntur, et istio-telemetria multum processuum facultates hic consumit (potest debilitari quaedam functiones inactivare). Hoc componente removemus, adhuc plus quam 100 millicores obtinemus, hoc est 4 temporibusquam Linkerd.

Sidecar procuratorem

Nos igitur procuratorem usum probavimus. Cum numero petitionum sit relatio linearis, sed pro quolibet sidere est aliquod caput quod curvam afficit.

Linkerd: ~100 millicores pro clientis

Eventus logicos respiciunt, quia client procurator bis tantum negotiationem accipit quam procuratorem oneris: nam omnis petitio ab onere exitu, client unum ineuntes et exitu habet.

Istio / Internuntius: ~155 millicores pro clientium, ~ 75 millicores pro clientium

Similes proventus pro Istio sidecaro videmus.

At generaliter Istio/Procuratores procuratores consumunt circiter L% plus opibus CPUquam Linkerd.

Eundem ordinem in servo latere videmus:

Linkerd: ~ L millicore pro irs-servo

Istio / Internuntius: ~ 80 millicore pro irs-servo

In calculonis servi, sidecar Istio / Legatus consumit circiter L% plus opibus CPUquam Linkerd.

conclusio,

Istio Legatus procuratorem plus CPU consumit 50+% quam Linkerd in nostro quod inposuit simulatum. Linkerd decuriae imperium multo minus facultates quam Istio, praesertim nucleorum partium consumit.

Nos adhuc cogitamus quomodo istae impensae minuendae sint. Si notiones habes, communica quaeso!

Source: www.habr.com