Introdución
Estamos dentro comezou a implantar Istio como unha malla de servizo. En principio, todo está ben, agás unha cousa: é caro.
В para Istio di:
Con Istio 1.1, o proxy consume aproximadamente 0,6 vCPU (núcleos virtuais) por cada 1000 solicitudes por segundo.
Para a primeira rexión da malla de servizo (2 proxies a cada lado da conexión), teremos 1200 núcleos só para o proxy, a un ritmo dun millón de solicitudes por segundo. Segundo a calculadora de custos de Google, a configuración é de aproximadamente $ 40/mes/núcleo n1-standard-64, é dicir, só esta rexión custaranos máis de 50 mil dólares ao mes por 1 millón de solicitudes por segundo.
Iván Sim () atrasos na malla de servizo o ano pasado e prometeu o mesmo para a memoria e o procesador, pero non funcionou:
Ao parecer, values-istio-test.yaml aumentará seriamente as solicitudes de CPU. Se fixen os cálculos correctamente, necesitas aproximadamente 24 núcleos de CPU para o panel de control e 0,5 CPU para cada proxy. Non teño tanto. Repetirei as probas cando se me asignen máis recursos.
Quería ver por min mesmo o parecido que é o rendemento de Istio con outra malla de servizos de código aberto: .
Instalación de malla de servizo
Primeiro de todo, instaleino nun clúster :
$ supergloo init
installing supergloo version 0.3.12
using chart uri https://storage.googleapis.com/supergloo-helm/charts/supergloo-0.3.12.tgz
configmap/sidecar-injection-resources created
serviceaccount/supergloo created
serviceaccount/discovery created
serviceaccount/mesh-discovery created
clusterrole.rbac.authorization.k8s.io/discovery created
clusterrole.rbac.authorization.k8s.io/mesh-discovery created
clusterrolebinding.rbac.authorization.k8s.io/supergloo-role-binding created
clusterrolebinding.rbac.authorization.k8s.io/discovery-role-binding created
clusterrolebinding.rbac.authorization.k8s.io/mesh-discovery-role-binding created
deployment.extensions/supergloo created
deployment.extensions/discovery created
deployment.extensions/mesh-discovery created
install successful!Usei SuperGloo porque facilita moito o arranque da malla de servizo. Non tiven que facer moito. Non usamos SuperGloo na produción, pero é ideal para tal tarefa. Tiven que usar literalmente un par de comandos para cada malla de servizo. Usei dous clusters para o illamento: un para Istio e Linkerd.
O experimento realizouse en Google Kubernetes Engine. Eu usei Kubernetes 1.12.7-gke.7 e un conxunto de nodos n1-standard-4 con escalado automático de nodos (mínimo 4, máximo 16).
Despois instalei as dúas mallas de servizo desde a liña de comandos.
Primeiro ligado:
$ supergloo install linkerd --name linkerd
+---------+--------------+---------+---------------------------+
| INSTALL | TYPE | STATUS | DETAILS |
+---------+--------------+---------+---------------------------+
| linkerd | Linkerd Mesh | Pending | enabled: true |
| | | | version: stable-2.3.0 |
| | | | namespace: linkerd |
| | | | mtls enabled: true |
| | | | auto inject enabled: true |
+---------+--------------+---------+---------------------------+Entón Istio:
$ supergloo install istio --name istio --installation-namespace istio-system --mtls=true --auto-inject=true
+---------+------------+---------+---------------------------+
| INSTALL | TYPE | STATUS | DETAILS |
+---------+------------+---------+---------------------------+
| istio | Istio Mesh | Pending | enabled: true |
| | | | version: 1.0.6 |
| | | | namespace: istio-system |
| | | | mtls enabled: true |
| | | | auto inject enabled: true |
| | | | grafana enabled: true |
| | | | prometheus enabled: true |
| | | | jaeger enabled: true |
+---------+------------+---------+---------------------------+O ciclo de accidente durou uns minutos e despois os paneis de control estabilizaron.
(Nota: SuperGloo só admite Istio 1.0.x polo momento. Repetín o experimento con Istio 1.1.3, pero non notei ningunha diferenza notable.)
Configurando a implantación automática de Istio
Para facer que Istio instale o sidecar Envoy, usamos o inxector sidecar − MutatingAdmissionWebhook. Non falaremos diso neste artigo. Permítanme dicir que este é un controlador que supervisa o acceso de todos os novos pods e engade de forma dinámica un sidecar e initContainer, que é responsable das tarefas. iptables.
En Shopify escribimos o noso propio controlador de acceso para implementar sidecars, pero para este punto de referencia usei o controlador que vén con Istio. O controlador inxecta sidecars por defecto cando hai un atallo no espazo de nomes istio-injection: enabled:
$ kubectl label namespace irs-client-dev istio-injection=enabled
namespace/irs-client-dev labeled
$ kubectl label namespace irs-server-dev istio-injection=enabled
namespace/irs-server-dev labeledConfigurando a implantación automática de Linkerd
Para configurar a incorporación de sidecar de Linkerd, usamos anotacións (engadínas manualmente mediante kubectl edit):
metadata:
annotations:
linkerd.io/inject: enabled$ k edit ns irs-server-dev
namespace/irs-server-dev edited
$ k get ns irs-server-dev -o yaml
apiVersion: v1
kind: Namespace
metadata:
annotations:
linkerd.io/inject: enabled
name: irs-server-dev
spec:
finalizers:
- kubernetes
status:
phase: ActiveSimulador de tolerancia a fallos de Istio
Creamos un simulador de tolerancia a fallos chamado Istio para experimentar co tráfico exclusivo de Shopify. Necesitabamos unha ferramenta para crear unha topoloxía personalizada que representase unha parte específica do noso gráfico de servizo, configurada de forma dinámica para modelar cargas de traballo específicas.
A infraestrutura de Shopify está sometida a unha gran carga durante as vendas flash. Ao mesmo tempo, Shopify . Os grandes clientes ás veces advirten sobre unha venda flash planificada. Outros lévanos a cabo de forma inesperada para nós a calquera hora do día ou da noite.
Queriamos que o noso simulador de resiliencia modelase fluxos de traballo que coincidan coas topoloxías e cargas de traballo que desbordaron a infraestrutura de Shopify no pasado. O propósito principal do uso dunha malla de servizo é que necesitamos fiabilidade e tolerancia a fallos a nivel de rede, e é importante para nós que a malla de servizo faga efectivamente fronte ás cargas que anteriormente interrompían os servizos.
No núcleo do simulador de tolerancia a fallos hai un nodo de traballo, que actúa como un nodo de malla de servizo. O nodo de traballo pódese configurar de forma estática ao inicio ou de forma dinámica mediante unha API REST. Usamos a configuración dinámica dos nodos de traballo para crear fluxos de traballo en forma de probas de regresión.
Aquí tes un exemplo dese proceso:
- Lanzamos 10 servidores como
barservizo que devolve unha resposta200/OKdespois de 100 ms. - Lanzamos 10 clientes, cada un envía 100 solicitudes por segundo
bar. - Cada 10 segundos eliminamos 1 servidor e monitorizamos os erros
5xxsobre o cliente.
Ao final do fluxo de traballo, examinamos os rexistros e as métricas e comprobamos se a proba pasou. Deste xeito, coñecemos o rendemento da nosa malla de servizo e realizamos unha proba de regresión para probar as nosas suposicións sobre a tolerancia a fallos.
(Nota: estamos pensando en obter o simulador de tolerancia a fallos de Istio, pero aínda non estamos preparados para facelo).
Simulador de tolerancia a fallos de Istio para o punto de referencia de malla de servizo
Estamos configurando varios nodos de traballo do simulador:
irs-client-loadgen: 3 réplicas que envían 100 solicitudes por segundo porirs-client.irs-client: 3 réplicas que reciben a solicitude, agardan 100 ms e reenvían a solicitude airs-server.irs-server: 3 réplicas que regresan200/OKdespois de 100 ms.
Con esta configuración, podemos medir un fluxo de tráfico estable entre 9 puntos finais. Sidecars dentro irs-client-loadgen и irs-server recibir 100 solicitudes por segundo, e irs-client — 200 (entrada e saída).
Seguimos o uso dos recursos porque non temos un clúster de Prometeo.
Descubrimentos
Paneles de control
En primeiro lugar, examinamos o consumo de CPU.
Panel de control de Linkerd ~ 22 milicores
Panel de control Istio: ~750 milicores
O panel de control de Istio usa aproximadamente 35 veces máis recursos de CPUque Linkerd. Por suposto, todo está instalado por defecto, e istio-telemetry consume moitos recursos da CPU aquí (pódese desactivar desactivando algunhas funcións). Se eliminamos este compoñente, aínda obtemos máis de 100 milinúcleos, é dicir 4 veces máisque Linkerd.
Proxy Sidecar
Despois probamos o uso dun proxy. Debería haber unha relación lineal co número de solicitudes, pero para cada sidecar hai algunha sobrecarga que afecta á curva.
Linkerd: ~100 milinúcleos para irs-client, ~50 milinúcleos para irs-client-loadgen
Os resultados parecen lóxicos, porque o proxy cliente recibe o dobre de tráfico que o proxy loadgen: por cada solicitude de saída de loadgen, o cliente ten unha entrada e outra saínte.
Istio/Envoy: ~155 milinúcleos para irs-client, ~75 milinúcleos para irs-client-loadgen
Vemos resultados similares para os sidecars Istio.
Pero, en xeral, os proxies Istio/Envoy consomen aproximadamente un 50% máis de recursos de CPUque Linkerd.
Vemos o mesmo esquema no lado do servidor:
Linkerd: ~50 milicores para irs-server
Istio/Envoy: ~80 milinúcleos para irs-server
No lado do servidor, o sidecar Istio/Envoy consome aproximadamente un 60% máis de recursos de CPUque Linkerd.
Conclusión
O proxy Istio Envoy consome un 50 % máis de CPU que Linkerd na nosa carga de traballo simulada. O panel de control de Linkerd consome moito menos recursos que Istio, especialmente para os compoñentes principais.
Aínda estamos pensando en como reducir estes custos. Se tes ideas, comparte!
Fonte: www.habr.com