{"id":34366,"date":"2019-10-31T21:57:56","date_gmt":"2019-10-31T18:57:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/benchmark-potrebleniya-tsp-dlya-istio-i-linkerd\/"},"modified":"2019-10-31T21:57:56","modified_gmt":"2019-10-31T18:57:56","slug":"benchmark-potrebleniya-tsp-dlya-istio-i-linkerd","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/benchmark-potrebleniya-tsp-dlya-istio-i-linkerd","title":{"rendered":"Benchmark del consumo della CPU per Istio e Linkerd","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Benchmark<\/p>\n

<\/p>\n

Introduzione<\/h2>\n

<\/p>\n

Noi di Shopify<\/a><\/noindex> ci siamo occupati dell'implementazione di Istio come service mesh. In linea generale, tutto va bene, tranne per una cosa: \u00e8 costoso<\/strong>.<\/p>\n

<\/p>\n

In benchmark pubblicati<\/a><\/noindex> per Istio si dice:<\/p>\n

<\/p>\n

Con Istio 1.1, il proxy consuma circa 0,6 vCPU (core virtuali) per 1000 richieste al secondo.<\/p><\/blockquote>\n

Per la prima regione nel service mesh (2 proxy da ciascun lato della connessione) avremo bisogno di 1200 core solo per i proxy, basandoci su un milione di richieste al secondo. Secondo il calcolatore dei costi di Google, circa $40\/mese\/core per la configurazione n1-standard-64<\/code>, il che significa che questa regione ci coster\u00e0 pi\u00f9 di 50.000 dollari al mese per un milione di richieste al secondo.<\/p>\n

<\/p>\n

Ivan Sim (Ivan Sim<\/a><\/noindex>) ha confrontato visivamente<\/a><\/noindex> le latenza della service mesh dell'anno scorso e ha promesso lo stesso per memoria e CPU, ma non ci \u00e8 riuscito:<\/p>\n

<\/p>\n

Sembra che values-istio-test.yaml aumenter\u00e0 notevolmente le richieste alla CPU. Se ho calcolato correttamente, servono circa 24 core per il pannello di controllo e 0,5 CPU per ogni proxy. Non ho cos\u00ec tante risorse. Ripeter\u00f2 i test quando ricever\u00f2 pi\u00f9 risorse.<\/p><\/blockquote>\n

Volevo vedere di persona quanto i risultati di Istio somigliassero ad un'altra service mesh open source: Linkerd<\/a><\/noindex>.<\/p>\n

<\/a><\/noindex><\/p>\n

Installazione della service mesh<\/h3>\n

<\/p>\n

Per prima cosa, ho installato nel cluster SuperGloo<\/a><\/noindex>:<\/p>\n

<\/p>\n

$ supergloo init\ninstallazione della versione 0.3.12 di supergloo\nutilizzando l'uri del chart https:\/\/storage.googleapis.com\/supergloo-helm\/charts\/supergloo-0.3.12.tgz\nconfigmap\/sidecar-injection-resources creato\nserviceaccount\/supergloo creato\nserviceaccount\/discovery creato\nserviceaccount\/mesh-discovery creato\nclusterrole.rbac.authorization.k8s.io\/discovery creato\nclusterrole.rbac.authorization.k8s.io\/mesh-discovery creato\nclusterrolebinding.rbac.authorization.k8s.io\/supergloo-role-binding creato\nclusterrolebinding.rbac.authorization.k8s.io\/discovery-role-binding creato\nclusterrolebinding.rbac.authorization.k8s.io\/mesh-discovery-role-binding creato\ndeployment.extensions\/supergloo creato\ndeployment.extensions\/discovery creato\ndeployment.extensions\/mesh-discovery creato\ninstallazione riuscita!<\/code><\/pre>\n
<\/p>\n
Ho utilizzato SuperGloo perch\u00e9 semplifica notevolmente il setup iniziale del service mesh. Non ho dovuto fare quasi nulla. In produzione, non usiamo SuperGloo, ma per compiti come questo \u00e8 perfetto. Ho dovuto utilizzare letteralmente un paio di comandi per ogni service mesh. Ho utilizzato due cluster per l'isolamento \u2014 uno per Istio e uno per Linkerd.<\/p>\n
<\/p>\n
L'esperimento \u00e8 stato condotto su Google Kubernetes Engine. Ho utilizzato Kubernetes 1.12.7-gke.7<\/code> e un pool di nodi n1-standard-4<\/code> con scaling automatico dei nodi (minimo 4, massimo 16).<\/p>\n
<\/p>\n
Dopo, ho installato entrambe le service mesh dalla riga di comando.<\/p>\n
<\/p>\n
Prima Linkerd:<\/p>\n
<\/p>\n
$ supergloo install linkerd --name linkerd\n+---------+--------------+---------+---------------------------+\n| INSTALL |     TYPE     | STATUS  |          DETAILS          |\n+---------+--------------+---------+---------------------------+\n| linkerd | Linkerd Mesh | Pending | enabled: true             |\n|         |              |         | version: stable-2.3.0     |\n|         |              |         | namespace: linkerd        |\n|         |              |         | mtls enabled: true        |\n|         |              |         | auto inject enabled: true |\n+---------+--------------+---------+---------------------------+<\/code><\/pre>\n
<\/p>\n
Poi Istio:<\/p>\n
<\/p>\n
$ supergloo install istio --name istio --installation-namespace istio-system --mtls=true --auto-inject=true\n+---------+------------+---------+---------------------------+\n| INSTALL |    TYPE    | STATUS  |          DETAILS          |\n+---------+------------+---------+---------------------------+\n| istio   | Istio Mesh | Pending | enabled: true             |\n|         |            |         | version: 1.0.6            |\n|         |            |         | namespace: istio-system   |\n|         |            |         | mtls enabled: true        |\n|         |            |         | auto inject enabled: true |\n|         |            |         | grafana enabled: true     |\n|         |            |         | prometheus enabled: true  |\n|         |            |         | jaeger enabled: true      |\n+---------+------------+---------+---------------------------+<\/code><\/pre>\n
<\/p>\n
Il crash-loop ha impiegato diversi minuti, poi i pannelli di controllo si sono stabilizzati.<\/p>\n
<\/p>\n
(Nota. SuperGloo attualmente supporta solo Istio 1.0.x. Ho ripetuto l'esperimento con Istio 1.1.3, ma non ho notato alcuna differenza significativa.)<\/em><\/p>\n
<\/p>\n
Impostazione dell'iniezione automatica di Istio<\/h3>\n
<\/p>\n
Perch\u00e9 Istio installi il sidecar Envoy, utilizziamo l'iniettore di sidecar \u2014 MutatingAdmissionWebhook<\/code>. Non ne parleremo in questo articolo. Dico solo che \u00e8 un controller che monitora l'accesso di tutti i nuovi pod e aggiunge dinamicamente sidecar e initContainer, il quale \u00e8 responsabile delle operazioni iptables<\/code>.<\/p>\n
<\/p>\n
Noi di Shopify abbiamo scritto il nostro controller di accesso per l'inserimento dei sidecar, ma in questo benchmark ho utilizzato il controller fornito con Istio. Il controller di default inserisce i sidecar quando nell'namespace c'\u00e8 un'etichetta istio-injection: enabled<\/code>:<\/p>\n
<\/p>\n
$ kubectl label namespace irs-client-dev istio-injection=enabled\nnamespace\/irs-client-dev etichettato\n\n$ kubectl label namespace irs-server-dev istio-injection=enabled\nnamespace\/irs-server-dev etichettato<\/code><\/pre>\n
<\/p>\n
Configurazione dell'inserimento automatico di Linkerd<\/h3>\n
<\/p>\n
Per configurare l'inserimento dei sidecar di Linkerd, utilizziamo le annotazioni (le ho aggiunte manualmente tramite kubectl edit<\/code>):<\/p>\n
<\/p>\n
metadata:\n  annotations:\n    linkerd.io\/inject: enabled<\/code><\/pre>\n
<\/p>\n
$ k edit ns irs-server-dev \nnamespace\/irs-server-dev modificato\n\n$ k get ns irs-server-dev -o yaml\napiVersion: v1\nkind: Namespace\nmetadata:\n  annotations:\n    linkerd.io\/inject: enabled\n  name: irs-server-dev\nspec:\n  finalizers:\n  - kubernetes\nstatus:\n  phase: Active<\/code><\/pre>\n
<\/p>\n
Simulatore di resilienza di Istio<\/h3>\n
<\/p>\n
Abbiamo creato un simulatore di tolleranza ai guasti di Istio per sperimentare con il traffico specifico per Shopify. Avevamo bisogno di uno strumento per creare topologie arbitrarie che rappresentassero una parte specifica del grafo del nostro servizio con configurazioni dinamiche per simulare carichi di lavoro specifici.<\/p>\n
<\/p>\n
L'infrastruttura di Shopify subisce un grande carico durante le vendite flash. In questo contesto, Shopify raccomanda ai venditori di organizzare pi\u00f9 spesso tali vendite<\/a><\/noindex>. Grandi clienti talvolta avvisano di una vendita flash programmata. Altri le organizzano inaspettatamente, in qualsiasi momento della giornata e della notte.<\/p>\n
<\/p>\n
Volevamo che il nostro simulatore di tolleranza ai guasti riproducesse flussi di lavoro che corrispondessero a topologie e carichi di lavoro che in passato avevano causato sovraccarichi all'infrastruttura di Shopify. L'obiettivo principale dell'uso del service mesh \u00e8 garantire la resilienza e la tolleranza ai guasti a livello di rete, ed \u00e8 importante che il service mesh gestisca efficacemente i carichi che in precedenza avevano disturbato il funzionamento dei servizi.<\/p>\n
<\/p>\n
Alla base del simulatore di tolleranza agli errori c'\u00e8 un nodo di lavoro che agisce come nodo di service mesh. Il nodo di lavoro pu\u00f2 essere configurato staticamente all'avvio o dinamicamente tramite API REST. Utilizziamo la configurazione dinamica dei nodi di lavoro per creare flussi di lavoro sotto forma di test regressivi.<\/p>\n
<\/p>\n
Ecco un esempio di questo processo:<\/p>\n
<\/p>\n