{"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\/sv\/blog\/administrirovanie\/benchmark-potrebleniya-tsp-dlya-istio-i-linkerd","title":{"rendered":"Benchmarking av CPU-anv\u00e4ndning f\u00f6r Istio och Linkerd","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Benchmarking<\/p>\n

<\/p>\n

Introduktion<\/h2>\n

<\/p>\n

En kort historia om containrar: fr\u00e5n chroot till Kubernetes Shopify<\/a><\/noindex> Vi har p\u00e5b\u00f6rjat implementeringen av Istio som en service mesh. I princip \u00e4r allt bra, f\u00f6rutom en sak: det \u00e4r dyrt<\/strong>.<\/p>\n

<\/p>\n

I offentliggjorda benchmarkar<\/a><\/noindex> f\u00f6r Istio s\u00e4gs det:<\/p>\n

<\/p>\n

Med Istio 1.1 anv\u00e4nder proxyn ungef\u00e4r 0,6 vCPU (virtuella k\u00e4rnor) per 1000 f\u00f6rfr\u00e5gningar per sekund.<\/p><\/blockquote>\n

F\u00f6r den f\u00f6rsta regionen i service mesh (med 2 proxys p\u00e5 varje sida av anslutningen) kommer vi att beh\u00f6va 1200 k\u00e4rnor bara f\u00f6r proxys, baserat p\u00e5 en miljon f\u00f6rfr\u00e5gningar per sekund. Enligt Googles kostnadskalkylator blir det ungef\u00e4r $40\/m\u00e5nad\/k\u00e4rna f\u00f6r konfigurationen n1-standard-64<\/code>, vilket betyder att denna region kommer att kosta oss mer \u00e4n 50 000 dollar per m\u00e5nad f\u00f6r 1 miljon f\u00f6rfr\u00e5gningar per sekund.<\/p>\n

<\/p>\n

Ivan Sim (Ivan Sim<\/a><\/noindex>) illustrerade tydligt<\/a><\/noindex> f\u00f6rdr\u00f6jningarna i service mesh f\u00f6rra \u00e5ret och lovade samma sak f\u00f6r minne och CPU, men det blev inte s\u00e5:<\/p>\n

<\/p>\n

Till synes kommer values-istio-test.yaml att kraftigt \u00f6ka belastningen p\u00e5 processorn. Om jag r\u00e4knat r\u00e4tt, beh\u00f6vs ungef\u00e4r 24 CPU-k\u00e4rnor f\u00f6r kontrollpanelen och 0,5 CPU f\u00f6r varje proxy. Jag har inte s\u00e5 m\u00e5nga. Jag kommer att upprepa testerna n\u00e4r jag f\u00e5r fler resurser.<\/p><\/blockquote>\n

Jag ville sj\u00e4lv se hur Istios prestanda j\u00e4mf\u00f6rs med en annan open-source service mesh: Linkerd<\/a><\/noindex>.<\/p>\n

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

Installation av service mesh<\/h3>\n

<\/p>\n

F\u00f6rst installerade jag i klustret SuperGloo<\/a><\/noindex>:<\/p>\n

<\/p>\n

$ supergloo init\ninstalling supergloo version 0.3.12\nusing chart uri https:\/\/storage.googleapis.com\/supergloo-helm\/charts\/supergloo-0.3.12.tgz\nconfigmap\/sidecar-injection-resources created\nserviceaccount\/supergloo created\nserviceaccount\/discovery created\nserviceaccount\/mesh-discovery created\nclusterrole.rbac.authorization.k8s.io\/discovery created\nclusterrole.rbac.authorization.k8s.io\/mesh-discovery created\nclusterrolebinding.rbac.authorization.k8s.io\/supergloo-role-binding created\nclusterrolebinding.rbac.authorization.k8s.io\/discovery-role-binding created\nclusterrolebinding.rbac.authorization.k8s.io\/mesh-discovery-role-binding created\ndeployment.extensions\/supergloo created\ndeployment.extensions\/discovery created\ndeployment.extensions\/mesh-discovery created\ninstall successful!<\/code><\/pre>\n
<\/p>\n
Jag anv\u00e4nde SuperGloo eftersom det f\u00f6renklar initialiseringen av service mesh avsev\u00e4rt. Jag beh\u00f6vde knappt g\u00f6ra n\u00e5gonting. I produktion anv\u00e4nder vi inte SuperGloo, men f\u00f6r en s\u00e5dan uppgift passar det perfekt. Jag var tvungen att k\u00f6ra bokstavligt talat ett par kommandon f\u00f6r varje service mesh. Jag anv\u00e4nde tv\u00e5 kluster f\u00f6r isolering \u2013 ett f\u00f6r Istio och ett f\u00f6r Linkerd.<\/p>\n
<\/p>\n
Experimentet genomf\u00f6rdes p\u00e5 Google Kubernetes Engine. Jag anv\u00e4nde Kubernetes 1.12.7-gke.7<\/code> och en nodpool n1-standard-4<\/code> med automatisk skalning av noder (minimum 4, maximum 16).<\/p>\n
<\/p>\n
Sedan installerade jag b\u00e5da service mesh fr\u00e5n kommandoraden.<\/p>\n
<\/p>\n
F\u00f6rst 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
Sedan 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
Crash-loop tog en minut, men kontrolpanelet stabiliserede sig efterf\u00f8lgende.<\/p>\n
<\/p>\n
(Bem\u00e6rk: SuperGloo underst\u00f8tter kun Istio 1.0.x i \u00f8jeblikket. Jeg gentog eksperimentet med Istio 1.1.3, men s\u00e5 ingen m\u00e6rkbar forskel.)<\/em><\/p>\n
<\/p>\n
Konfiguration af automatisk injektion af Istio<\/h3>\n
<\/p>\n
For at f\u00e5 Istio til at installere sidecar Envoy bruger vi en sidecar-injektor \u2014 MutatingAdmissionWebhook<\/code>. Vi vil ikke diskutere dette i denne artikel. Jeg vil blot sige, at det er en controller, der overv\u00e5ger adgangen for alle nye pod'e og dynamisk tilf\u00f8jer sidecar og initContainer, der er ansvarlig for opgaverne iptables<\/code>.<\/p>\n
<\/p>\n
Vi i Shopify har skrevet vores egen adgangscontroller til injektion af sidecar, men i denne benchmark brugte jeg den controller, der f\u00f8lger med Istio. Standardcontrolleren injicerer sidecar, n\u00e5r der er et label i navnerummet 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
Konfiguration af automatisk injektion af Linkerd<\/h3>\n
<\/p>\n
For at konfigurere injektion af sidecar i Linkerd bruger vi annoteringer (jeg tilf\u00f8jede dem manuelt via 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
Simulator for fejltolerance med Istio<\/h3>\n
<\/p>\n
Vi har skapat en simuleringsmodell f\u00f6r tillf\u00f6rlitlighet med Istio f\u00f6r att experimentera med trafik unik f\u00f6r Shopify. Vi beh\u00f6vde ett verktyg f\u00f6r att skapa en godtycklig topologi som skulle representera en viss del av grafen av v\u00e5r tj\u00e4nst med dynamisk konfiguration f\u00f6r att modellera specifika arbetsbelastningar.<\/p>\n
<\/p>\n
Shopifys infrastruktur st\u00e5r inf\u00f6r h\u00f6g belastning under flash-f\u00f6rs\u00e4ljningar. Under dessa perioder rekommenderar Shopify att s\u00e4ljare ofta genomf\u00f6r s\u00e5dana f\u00f6rs\u00e4ljningar<\/a><\/noindex>. Stora kunder informerar ibland i f\u00f6rv\u00e4g om en planerad flash-f\u00f6rs\u00e4ljning. Andra genomf\u00f6r dem ov\u00e4ntat f\u00f6r oss n\u00e4r som helst p\u00e5 dygnet.<\/p>\n
<\/p>\n
Vi ville att v\u00e5r simuleringsmodell f\u00f6r tillf\u00f6rlitlighet skulle modellera arbetsfl\u00f6den som matchar de topologier och arbetsbelastningar som tidigare lett till \u00f6verbelastning av Shopifys infrastruktur. Huvudsyftet med att anv\u00e4nda service mesh \u00e4r att vi beh\u00f6ver tillf\u00f6rlitlighet och redundans p\u00e5 n\u00e4tverksniv\u00e5, och det \u00e4r viktigt f\u00f6r oss att service mesh hanterar belastningar som tidigare har p\u00e5verkat tj\u00e4nsternas drift.<\/p>\n
<\/p>\n
I grunden f\u00f6r simuleringsmodellen f\u00f6r tillf\u00f6rlitlighet finns en arbetsnod som fungerar som en nod i service mesh. Arbetsnoden kan st\u00e4llas in statiskt vid start eller dynamiskt via REST API. Vi anv\u00e4nder dynamisk konfiguration av arbetsnoder f\u00f6r att skapa arbetsfl\u00f6den i form av regressiva tester.<\/p>\n
<\/p>\n
H\u00e4r \u00e4r ett exempel p\u00e5 en s\u00e5dan process:<\/p>\n
<\/p>\n