{"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 di 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> abbiamo iniziato a implementare Istio come service mesh. In linea di principio, siamo soddisfatti, 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 (nuclei virtuali) ogni 1000 richieste al secondo.<\/p><\/blockquote>\n

Per la prima regione nella service mesh (due proxy per ogni lato della connessione), avremo 1200 nuclei solo per i proxy, calcolando un milione di richieste al secondo. Secondo il calcolatore dei costi di Google, il costo \u00e8 di circa $40\/al mese\/per nucleo per la configurazione n1-standard-64<\/code>, quindi questa regione ci coster\u00e0 oltre 50 mila dollari al mese per 1 milione di richieste al secondo.<\/p>\n

<\/p>\n

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

<\/p>\n

A quanto pare, il file values-istio-test.yaml aumenter\u00e0 notevolmente le richieste alla CPU. Se ho calcolato bene, servono circa 24 nuclei di CPU per il pannello di controllo e 0,5 CPU per ogni proxy. Non ne ho cos\u00ec tanti. Ripeter\u00f2 i test quando mi verranno dati pi\u00f9 risorse.<\/p><\/blockquote>\n

Volevo verificare di persona quanto siano simili le prestazioni di Istio rispetto a 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\ninstallando la versione supergloo 0.3.12\nusando 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 usato SuperGloo perch\u00e9 semplifica notevolmente l'impostazione iniziale della service mesh. Non ho dovuto fare quasi nulla. In produzione non usiamo SuperGloo, ma per un compito simile \u00e8 perfetto. Ho dovuto eseguire solo un paio di comandi su ciascuna service mesh. Ho utilizzato due cluster per l'isolamento: uno per Istio e l'altro per Linkerd.<\/p>\n
<\/p>\n
L'esperimento \u00e8 stato condotto su Google Kubernetes Engine. Ho usato Kubernetes 1.12.7-gke.7<\/code> e un pool di nodi n1-standard-4<\/code> con ridimensionamento automatico dei nodi (minimo 4, massimo 16).<\/p>\n
<\/p>\n
Poi ho installato entrambe le service mesh dalla riga di comando.<\/p>\n
<\/p>\n
Per prima cosa Linkerd:<\/p>\n
<\/p>\n
$ supergloo install linkerd --name linkerd\n+---------+--------------+---------+---------------------------+\n| INSTALL |     TYPE     | STATUS  |          DETAILS          |\n+---------+--------------+---------+---------------------------+\n| linkerd | Linkerd Mesh | In attesa | abilitato: vero            |\n|         |              |         | versione: stable-2.3.0     |\n|         |              |         | namespace: linkerd        |\n|         |              |         | mtls abilitato: vero      |\n|         |              |         | auto inject abilitato: vero |\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 | In attesa | abilitato: vero            |\n|         |            |         | versione: 1.0.6            |\n|         |            |         | namespace: istio-system   |\n|         |            |         | mtls abilitato: vero      |\n|         |            |         | auto inject abilitato: vero |\n|         |            |         | grafana abilitato: vero   |\n|         |            |         | prometheus abilitato: vero |\n|         |            |         | jaeger abilitato: vero    |\n+---------+------------+---------+---------------------------+<\/code><\/pre>\n
<\/p>\n
Il crash-loop ha preso alcuni minuti, e poi i pannelli di controllo si sono stabilizzati.<\/p>\n
<\/p>\n
(Nota. SuperGloo supporta attualmente 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
Per far s\u00ec che Istio installi il sidecar Envoy, utilizziamo il sidecar-injector \u2014 MutatingAdmissionWebhook<\/code>. Non ne parleremo in questo articolo. Dir\u00f2 solo che \u00e8 un controllore che monitora l'accesso di tutti i nuovi pod e aggiunge dinamicamente sidecar e initContainer, che si occupa dei compiti iptables<\/code>.<\/p>\n
<\/p>\n
In Shopify abbiamo scritto il nostro controllore di accesso per l'iniezione dei sidecar, ma in questo benchmark ho utilizzato il controllore fornito con Istio. Il controllore di default inietta i sidecar quando nel namespace \u00e8 presente l'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
Impostazione dell'iniezione automatica di Linkerd<\/h3>\n
<\/p>\n
Per configurare l'iniezione 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: Attivo<\/code><\/pre>\n
<\/p>\n
Simulatore di tolleranza ai guasti di Istio<\/h3>\n
<\/p>\n
Abbiamo sviluppato un simulatore di resilienza di Istio per sperimentare traffico specifico per Shopify. Avevamo bisogno di uno strumento per creare una topologia arbitraria che rappresentasse una parte specifica del grafo del nostro servizio, con impostazioni dinamiche per modellare carichi di lavoro specifici.<\/p>\n
<\/p>\n
L'infrastruttura di Shopify subisce una grande pressione durante le vendite lampo. In questo contesto, Shopify consiglia ai venditori di effettuare vendite lampo pi\u00f9 spesso<\/a><\/noindex>. I grandi clienti a volte avvisano in anticipo riguardo a vendite lampo programmati. Altri le effettuano inaspettatamente, a qualsiasi ora del giorno e della notte.<\/p>\n
<\/p>\n
Volevamo che il nostro simulatore di resilienza modellasse i flussi di lavoro che corrispondevano a topologie e carichi di lavoro che in passato avevano causato sovraccarichi all'infrastruttura di Shopify. L'obiettivo principale nell'utilizzare un service mesh \u00e8 che abbiamo bisogno di affidabilit\u00e0 e resilienza a livello di rete, ed \u00e8 importante per noi che il service mesh gestisca efficacemente i carichi che in passato hanno compromesso il funzionamento dei servizi.<\/p>\n
<\/p>\n
Al centro del simulatore di resilienza c'\u00e8 un nodo di lavoro che funge da nodo del service mesh. Il nodo di lavoro pu\u00f2 essere configurato staticamente all'avvio o dinamicamente tramite REST API. Utilizziamo la configurazione dinamica dei nodi di lavoro per creare flussi di lavoro come test di regressione.<\/p>\n
<\/p>\n
Ecco un esempio di tale processo:<\/p>\n
<\/p>\n