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

\"Benchmark<\/p>\n

<\/p>\n

Introducci\u00f3n<\/h2>\n

<\/p>\n

En Shopify<\/a><\/noindex> comenzamos a implementar Istio como un service mesh. En general, todo funciona bien, excepto por una cosa: es caro<\/strong>.<\/p>\n

<\/p>\n

En en los benchmarks publicados<\/a><\/noindex> para Istio se dice:<\/p>\n

<\/p>\n

Con Istio 1.1, el proxy consume aproximadamente 0,6 vCPU (n\u00facleos virtuales) por cada 1000 solicitudes por segundo.<\/p><\/blockquote>\n

Para la primera regi\u00f3n en el service mesh (con 2 proxies en cada lado de la conexi\u00f3n), necesitaremos 1200 n\u00facleos solo para los proxies, calculando un mill\u00f3n de solicitudes por segundo. Seg\u00fan la calculadora de costos de Google, esto suma aproximadamente $40\/mes\/n\u00facleo para la configuraci\u00f3n n1-standard-64<\/code>, lo que significa que solo esta regi\u00f3n nos costar\u00e1 m\u00e1s de 50 mil d\u00f3lares al mes por 1 mill\u00f3n de solicitudes por segundo.<\/p>\n

<\/p>\n

Aiven Sim (Ivan Sim<\/a><\/noindex>) compar\u00f3 visualmente<\/a><\/noindex> las latencias del service mesh del a\u00f1o pasado y prometi\u00f3 lo mismo para memoria y CPU, pero no pudo hacerlo:<\/p>\n

<\/p>\n

Parece que values-istio-test.yaml aumentar\u00e1 significativamente las solicitudes a la CPU. Si he hecho los c\u00e1lculos correctamente, se necesitan alrededor de 24 n\u00facleos de CPU para el panel de control y 0,5 CPU para cada proxy. No tengo suficientes. Repetir\u00e9 las pruebas cuando me asignen m\u00e1s recursos.<\/p><\/blockquote>\n

Quer\u00eda comprobar por m\u00ed mismo cu\u00e1n similares son las m\u00e9tricas de Istio a las de otro service mesh de c\u00f3digo abierto: Linkerd<\/a><\/noindex>.<\/p>\n

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

Instalaci\u00f3n del service mesh<\/h3>\n

<\/p>\n

Primero, instal\u00e9 en el cl\u00faster SuperGloo<\/a><\/noindex>:<\/p>\n

<\/p>\n

$ supergloo init\ninstalando supergloo versi\u00f3n 0.3.12\nusando uri de gr\u00e1fico https:\/\/storage.googleapis.com\/supergloo-helm\/charts\/supergloo-0.3.12.tgz\nconfigmap\/sidecar-injection-resources creado\nserviceaccount\/supergloo creado\nserviceaccount\/discovery creado\nserviceaccount\/mesh-discovery creado\nclusterrole.rbac.authorization.k8s.io\/discovery creado\nclusterrole.rbac.authorization.k8s.io\/mesh-discovery creado\nclusterrolebinding.rbac.authorization.k8s.io\/supergloo-role-binding creado\nclusterrolebinding.rbac.authorization.k8s.io\/discovery-role-binding creado\nclusterrolebinding.rbac.authorization.k8s.io\/mesh-discovery-role-binding creado\ndeployment.extensions\/supergloo creado\ndeployment.extensions\/discovery creado\ndeployment.extensions\/mesh-discovery creado\n\u00a1instalaci\u00f3n exitosa!<\/code><\/pre>\n
<\/p>\n
Us\u00e9 SuperGloo porque simplifica significativamente la carga inicial del service mesh. Pr\u00e1cticamente no tuve que hacer nada. En producci\u00f3n no usamos SuperGloo, pero para esta tarea es perfecto. Solo tuve que ejecutar un par de comandos para cada service mesh. Us\u00e9 dos cl\u00fasteres para aislacion \u2014 uno para Istio y otro para Linkerd.<\/p>\n
<\/p>\n
El experimento se realiz\u00f3 en Google Kubernetes Engine. Us\u00e9 Kubernetes 1.12.7-gke.7<\/code> y un grupo de nodos n1-standard-4<\/code> con escalado autom\u00e1tico de nodos (m\u00ednimo 4, m\u00e1ximo 16).<\/p>\n
<\/p>\n
Luego instal\u00e9 ambos service meshes desde la l\u00ednea de comandos.<\/p>\n
<\/p>\n
Primero 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
Luego 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
El crash-loop tom\u00f3 unos minutos y luego los paneles de control se estabilizaron.<\/p>\n
<\/p>\n
(Nota. SuperGloo solo soporta Istio 1.0.x por ahora. Repet\u00ed el experimento con Istio 1.1.3, pero no not\u00e9 ninguna diferencia significativa.)<\/em><\/p>\n
<\/p>\n
Configuraci\u00f3n de la inyecci\u00f3n autom\u00e1tica de Istio<\/h3>\n
<\/p>\n
Para que Istio instale el sidecar Envoy, utilizamos un inyectador de sidecar \u2014 MutatingAdmissionWebhook<\/code>. No hablaremos de \u00e9l en este art\u00edculo. Solo dir\u00e9 que es un controlador que supervisa el acceso de todos los nuevos pods y agrega din\u00e1micamente un sidecar y un initContainer que se encarga de las tareas iptables<\/code>.<\/p>\n
<\/p>\n
En Shopify, escribimos nuestro controlador de acceso para la inyecci\u00f3n de sidecars, pero en este benchmark utilic\u00e9 el controlador que viene con Istio. El controlador por defecto inyecta sidecars cuando hay una etiqueta en el espacio de nombres 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
Configuraci\u00f3n de la inyecci\u00f3n autom\u00e1tica de Linkerd<\/h3>\n
<\/p>\n
Para configurar la inyecci\u00f3n de sidecars de Linkerd, utilizamos anotaciones (las a\u00f1ad\u00ed manualmente a trav\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 tolerancia a fallos de Istio<\/h3>\n
<\/p>\n
Hemos creado un simulador de resistencia a fallos de Istio para experimentar con el tr\u00e1fico exclusivo de Shopify. Necesit\u00e1bamos una herramienta para crear una topolog\u00eda arbitraria que representara una parte espec\u00edfica del grafo de nuestro servicio con una configuraci\u00f3n din\u00e1mica para modelar cargas de trabajo concretas.<\/p>\n
<\/p>\n
La infraestructura de Shopify enfrenta una gran carga durante las ventas flash. En este contexto, Shopify recomienda a los vendedores llevar a cabo tales ventas m\u00e1s a menudo<\/a><\/noindex>. Algunos clientes grandes a veces avisan sobre una venta flash planificada. Otros las realizan de forma inesperada para nosotros en cualquier momento del d\u00eda y de la noche.<\/p>\n
<\/p>\n
Quer\u00edamos que nuestro simulador de resistencia a fallos modelara flujos de trabajo que correspondieran a las topolog\u00edas y cargas de trabajo que hab\u00edan causado la sobrecarga de la infraestructura de Shopify en el pasado. El objetivo principal de usar un service mesh es que necesitamos fiabilidad y resistencia a fallos a nivel de red, y es importante para nosotros que el service mesh maneje eficazmente las cargas que anteriormente interrump\u00edan el funcionamiento de los servicios.<\/p>\n
<\/p>\n
En la base del simulador de resistencia a fallos se encuentra un nodo de trabajo que act\u00faa como nodo de service mesh. El nodo de trabajo puede configurarse de manera est\u00e1tica al iniciar o din\u00e1micamente a trav\u00e9s de la API REST. Usamos la configuraci\u00f3n din\u00e1mica de nodos de trabajo para crear flujos de trabajo en forma de pruebas regresivas.<\/p>\n
<\/p>\n
Aqu\u00ed hay un ejemplo de tal proceso:<\/p>\n
<\/p>\n