{"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\/pt\/blog\/administrirovanie\/benchmark-potrebleniya-tsp-dlya-istio-i-linkerd","title":{"rendered":"Benchmark de consumo de CPU para Istio e Linkerd","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Benchmark<\/p>\n

<\/p>\n

Introdu\u00e7\u00e3o<\/h2>\n

<\/p>\n

N\u00f3s na Shopify<\/a><\/noindex> come\u00e7amos a implementar o Istio como service mesh. No geral, estamos satisfeitos, exceto por uma coisa: isso \u00e9 caro<\/strong>.<\/p>\n

<\/p>\n

Em nos benchmarks publicados<\/a><\/noindex> para Istio \u00e9 mencionado:<\/p>\n

<\/p>\n

Com o Istio 1.1, o proxy consome cerca de 0,6 vCPU (n\u00facleos virtuais) para 1000 requisi\u00e7\u00f5es por segundo.<\/p><\/blockquote>\n

Para a primeira regi\u00e3o no service mesh (com 2 proxies de cada lado da conex\u00e3o), teremos 1200 n\u00facleos apenas para o proxy, considerando um milh\u00e3o de requisi\u00e7\u00f5es por segundo. De acordo com a calculadora de custos do Google, isso resulta em cerca de $40\/m\u00eas\/n\u00facleo para a configura\u00e7\u00e3o n1-standard-64<\/code>, portanto, apenas esta regi\u00e3o custar\u00e1 mais de 50 mil d\u00f3lares por m\u00eas para 1 milh\u00e3o de requisi\u00e7\u00f5es por segundo.<\/p>\n

<\/p>\n

Ivan Sim (Ivan Sim<\/a><\/noindex>) comparou claramente<\/a><\/noindex> as lat\u00eancias do service mesh no ano passado e prometeu o mesmo para mem\u00f3ria e CPU, mas n\u00e3o conseguiu:<\/p>\n

<\/p>\n

Aparentemente, values-istio-test.yaml aumentar\u00e1 bastante as requisi\u00e7\u00f5es para a CPU. Se eu calculei corretamente, ser\u00e3o necess\u00e1rios cerca de 24 n\u00facleos de CPU para o painel de controle e 0,5 CPU para cada proxy. Eu n\u00e3o tenho tantos. Repetirei os testes quando mais recursos forem alocados para mim.<\/p><\/blockquote>\n

Queria me certificar de qu\u00e3o pr\u00f3ximos os resultados do Istio est\u00e3o de outro service mesh de c\u00f3digo aberto: Linkerd<\/a><\/noindex>.<\/p>\n

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

Instala\u00e7\u00e3o do service mesh<\/h3>\n

<\/p>\n

Primeiro, instalei no cluster SuperGloo<\/a><\/noindex>:<\/p>\n

<\/p>\n

$ supergloo init\ninstalando a vers\u00e3o 0.3.12 do supergloo\nusando o URI do gr\u00e1fico https:\/\/storage.googleapis.com\/supergloo-helm\/charts\/supergloo-0.3.12.tgz\nconfigmap\/sidecar-injection-resources criado\nserviceaccount\/supergloo criado\nserviceaccount\/discovery criado\nserviceaccount\/mesh-discovery criado\nclusterrole.rbac.authorization.k8s.io\/discovery criado\nclusterrole.rbac.authorization.k8s.io\/mesh-discovery criado\nclusterrolebinding.rbac.authorization.k8s.io\/supergloo-role-binding criado\nclusterrolebinding.rbac.authorization.k8s.io\/discovery-role-binding criado\nclusterrolebinding.rbac.authorization.k8s.io\/mesh-discovery-role-binding criado\ndeployment.extensions\/supergloo criado\ndeployment.extensions\/discovery criado\ndeployment.extensions\/mesh-discovery criado\ninstala\u00e7\u00e3o bem-sucedida!<\/code><\/pre>\n
<\/p>\n
Usei o SuperGloo porque ele simplifica bastante a instala\u00e7\u00e3o inicial do service mesh. Eu quase n\u00e3o precisei fazer nada. Em produ\u00e7\u00e3o, n\u00e3o usamos o SuperGloo, mas para uma tarefa como esta, ele \u00e9 ideal. Tive que executar literalmente apenas alguns comandos para cada service mesh. Usei dois clusters para isolamento \u2014 um para Istio e outro para Linkerd.<\/p>\n
<\/p>\n
O experimento foi realizado no Google Kubernetes Engine. Usei Kubernetes 1.12.7-gke.7<\/code> e um pool de n\u00f3s n1-standard-4<\/code> com escalonamento autom\u00e1tico de n\u00f3s (m\u00ednimo 4, m\u00e1ximo 16).<\/p>\n
<\/p>\n
Depois, instalei ambos os service mesh atrav\u00e9s da linha de comando.<\/p>\n
<\/p>\n
Primeiro o 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
Depois, 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
O crash-loop levou alguns minutos, e ent\u00e3o os pain\u00e9is de controle estabilizaram.<\/p>\n
<\/p>\n
(Nota. O SuperGloo atualmente suporta apenas Istio 1.0.x. Eu repeti o experimento com Istio 1.1.3, mas n\u00e3o percebi diferen\u00e7a significativa.)<\/em><\/p>\n
<\/p>\n
Configura\u00e7\u00e3o da inje\u00e7\u00e3o autom\u00e1tica do Istio<\/h3>\n
<\/p>\n
Para que o Istio instale o sidecar Envoy, usamos o injetor de sidecar \u2014 MutatingAdmissionWebhook<\/code>. N\u00e3o vamos falar sobre isso neste artigo. Apenas direi que \u00e9 um controlador que monitoriza o acesso de todos os novos pods e adiciona dinamicamente o sidecar e o initContainer, que \u00e9 respons\u00e1vel por tarefas iptables<\/code>.<\/p>\n
<\/p>\n
N\u00f3s, da Shopify, escrevemos nosso pr\u00f3prio controlador de acesso para inje\u00e7\u00e3o de sidecars, mas neste benchmark eu utilizei o controlador que vem com o Istio. O controlador padr\u00e3o injeta sidecars quando h\u00e1 um r\u00f3tulo no namespace istio-injection: enabled<\/code>:<\/p>\n
<\/p>\n
$ kubectl label namespace irs-client-dev istio-injection=enabled\nnamespace\/irs-client-dev labeled\n\n$ kubectl label namespace irs-server-dev istio-injection=enabled\nnamespace\/irs-server-dev labeled<\/code><\/pre>\n
<\/p>\n
Configura\u00e7\u00e3o da inje\u00e7\u00e3o autom\u00e1tica do Linkerd<\/h3>\n
<\/p>\n
Para configurar a inje\u00e7\u00e3o de sidecars do Linkerd, usamos anota\u00e7\u00f5es (eu as adicionei manualmente atrav\u00e9s de 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 edited\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
Simulador de toler\u00e2ncia a falhas do Istio<\/h3>\n
<\/p>\n
Criamos um simulador de resili\u00eancia do Istio para experimentar o tr\u00e1fego exclusivo da Shopify. Precis\u00e1vamos de uma ferramenta para criar uma topologia arbitr\u00e1ria que representasse uma parte espec\u00edfica do grafo do nosso servi\u00e7o com configura\u00e7\u00f5es din\u00e2micas para modelar cargas de trabalho espec\u00edficas.<\/p>\n
<\/p>\n
A infraestrutura da Shopify enfrenta grande carga durante vendas rel\u00e2mpago. Nesse contexto, a Shopify recomenda que os vendedores realizem essas vendas com mais frequ\u00eancia<\/a><\/noindex>. Grandes clientes \u00e0s vezes nos avisam sobre uma venda rel\u00e2mpago agendada. Outros a realizam de forma inesperada a qualquer hora do dia e da noite.<\/p>\n
<\/p>\n
Quer\u00edamos que nosso simulador de resili\u00eancia modelasse os fluxos de trabalho que correspondem \u00e0s topologias e cargas de trabalho que anteriormente causaram sobrecarga na infraestrutura da Shopify. O principal objetivo do uso de service mesh \u00e9 garantir a confiabilidade e a resili\u00eancia em n\u00edvel de rede, e \u00e9 importante que a service mesh lide de forma eficaz com as cargas que anteriormente prejudicaram os servi\u00e7os.<\/p>\n
<\/p>\n
No n\u00facleo do simulador de resili\u00eancia est\u00e1 um n\u00f3 de trabalho que atua como um n\u00f3 de service mesh. O n\u00f3 de trabalho pode ser configurado estaticamente na inicializa\u00e7\u00e3o ou dinamicamente por meio da API REST. Usamos a configura\u00e7\u00e3o din\u00e2mica dos n\u00f3s de trabalho para criar fluxos de trabalho na forma de testes regressivos.<\/p>\n
<\/p>\n
Aqui est\u00e1 um exemplo desse processo:<\/p>\n
<\/p>\n