Istio ਅਤੇ Linkerd ਲਈ CPU ਖਪਤ ਬੈਂਚਮਾਰਕ

ਜਾਣ ਪਛਾਣ

ਅਸੀਂ ਅੰਦਰ ਹਾਂ Shopify ਇੱਕ ਸੇਵਾ ਜਾਲ ਦੇ ਤੌਰ ਤੇ Istio ਨੂੰ ਤਾਇਨਾਤ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ. ਸਿਧਾਂਤ ਵਿੱਚ, ਸਭ ਕੁਝ ਠੀਕ ਹੈ, ਇੱਕ ਚੀਜ਼ ਨੂੰ ਛੱਡ ਕੇ: ਇਹ ਮਹਿੰਗਾ ਹੈ.

В ਪ੍ਰਕਾਸ਼ਿਤ ਮਾਪਦੰਡ Istio ਲਈ ਇਹ ਕਹਿੰਦਾ ਹੈ:

Istio 1.1 ਦੇ ਨਾਲ, ਪ੍ਰੌਕਸੀ ਪ੍ਰਤੀ 0,6 ਬੇਨਤੀਆਂ ਪ੍ਰਤੀ ਸਕਿੰਟ ਲਗਭਗ 1000 vCPUs (ਵਰਚੁਅਲ ਕੋਰ) ਦੀ ਖਪਤ ਕਰਦੀ ਹੈ।

ਸੇਵਾ ਜਾਲ ਵਿੱਚ ਪਹਿਲੇ ਖੇਤਰ ਲਈ (ਕੁਨੈਕਸ਼ਨ ਦੇ ਹਰੇਕ ਪਾਸੇ 2 ਪ੍ਰੌਕਸੀ), ਸਾਡੇ ਕੋਲ ਸਿਰਫ਼ ਪ੍ਰੌਕਸੀ ਲਈ 1200 ਕੋਰ ਹੋਣਗੇ, ਪ੍ਰਤੀ ਸਕਿੰਟ ਇੱਕ ਮਿਲੀਅਨ ਬੇਨਤੀਆਂ ਦੀ ਦਰ ਨਾਲ। ਗੂਗਲ ਦੇ ਲਾਗਤ ਕੈਲਕੁਲੇਟਰ ਦੇ ਅਨੁਸਾਰ, ਇਹ ਸੰਰਚਨਾ ਲਈ ਲਗਭਗ $40/ਮਹੀਨਾ/ਕੋਰ ਹੋਣ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ n1-standard-64, ਯਾਨੀ, ਇਕੱਲੇ ਇਸ ਖੇਤਰ ਲਈ ਪ੍ਰਤੀ ਸਕਿੰਟ 50 ਮਿਲੀਅਨ ਬੇਨਤੀਆਂ ਲਈ ਸਾਨੂੰ ਪ੍ਰਤੀ ਮਹੀਨਾ 1 ਹਜ਼ਾਰ ਡਾਲਰ ਤੋਂ ਵੱਧ ਦਾ ਖਰਚਾ ਆਵੇਗਾ।

ਇਵਾਨ ਸਿਮ (ਇਵਾਨ ਸਿਮ) ਦ੍ਰਿਸ਼ਟੀਗਤ ਤੁਲਨਾ ਸੇਵਾ ਜਾਲ ਨੇ ਪਿਛਲੇ ਸਾਲ ਦੇਰੀ ਕੀਤੀ ਅਤੇ ਮੈਮੋਰੀ ਅਤੇ ਪ੍ਰੋਸੈਸਰ ਲਈ ਇਹੀ ਵਾਅਦਾ ਕੀਤਾ, ਪਰ ਇਹ ਕੰਮ ਨਹੀਂ ਹੋਇਆ:

ਜ਼ਾਹਰ ਹੈ, values-istio-test.yaml CPU ਬੇਨਤੀਆਂ ਨੂੰ ਗੰਭੀਰਤਾ ਨਾਲ ਵਧਾਏਗਾ। ਜੇਕਰ ਮੈਂ ਆਪਣਾ ਗਣਿਤ ਸਹੀ ਢੰਗ ਨਾਲ ਕੀਤਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਕੰਟਰੋਲ ਪੈਨਲ ਲਈ ਲਗਭਗ 24 CPU ਕੋਰ ਅਤੇ ਹਰੇਕ ਪ੍ਰੌਕਸੀ ਲਈ 0,5 CPU ਦੀ ਲੋੜ ਹੈ। ਮੇਰੇ ਕੋਲ ਇੰਨਾ ਨਹੀਂ ਹੈ। ਜਦੋਂ ਮੈਨੂੰ ਹੋਰ ਸਰੋਤ ਦਿੱਤੇ ਜਾਣਗੇ ਤਾਂ ਮੈਂ ਟੈਸਟਾਂ ਨੂੰ ਦੁਹਰਾਵਾਂਗਾ।

ਮੈਂ ਆਪਣੇ ਲਈ ਇਹ ਦੇਖਣਾ ਚਾਹੁੰਦਾ ਸੀ ਕਿ ਇਸਟੀਓ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਇੱਕ ਹੋਰ ਓਪਨ ਸੋਰਸ ਸੇਵਾ ਜਾਲ ਨਾਲ ਕਿੰਨੀ ਸਮਾਨ ਹੈ: ਲਿੰਕਰਡ.

ਸੇਵਾ ਜਾਲ ਇੰਸਟਾਲੇਸ਼ਨ

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਮੈਂ ਇਸਨੂੰ ਇੱਕ ਕਲੱਸਟਰ ਵਿੱਚ ਸਥਾਪਿਤ ਕੀਤਾ ਸੁਪਰਗਲੂ:

$ 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!

ਮੈਂ ਸੁਪਰਗਲੂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਕਿਉਂਕਿ ਇਹ ਸੇਵਾ ਜਾਲ ਨੂੰ ਬੂਟਸਟਰੈਪ ਕਰਨਾ ਬਹੁਤ ਸੌਖਾ ਬਣਾਉਂਦਾ ਹੈ. ਮੈਨੂੰ ਬਹੁਤਾ ਕੁਝ ਨਹੀਂ ਕਰਨਾ ਪਿਆ। ਅਸੀਂ ਉਤਪਾਦਨ ਵਿੱਚ ਸੁਪਰਗਲੂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ ਹਾਂ, ਪਰ ਇਹ ਅਜਿਹੇ ਕੰਮ ਲਈ ਆਦਰਸ਼ ਹੈ। ਮੈਨੂੰ ਹਰੇਕ ਸੇਵਾ ਜਾਲ ਲਈ ਸ਼ਾਬਦਿਕ ਤੌਰ 'ਤੇ ਕੁਝ ਕਮਾਂਡਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਪਈ. ਮੈਂ ਅਲੱਗ-ਥਲੱਗ ਕਰਨ ਲਈ ਦੋ ਕਲੱਸਟਰਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ - ਇਸਟੀਓ ਅਤੇ ਲਿੰਕਰਡ ਲਈ ਹਰੇਕ.

ਇਹ ਪ੍ਰਯੋਗ ਗੂਗਲ ਕੁਬਰਨੇਟਸ ਇੰਜਣ 'ਤੇ ਕੀਤਾ ਗਿਆ ਸੀ। ਮੈਂ ਕੁਬਰਨੇਟਸ ਦੀ ਵਰਤੋਂ ਕੀਤੀ 1.12.7-gke.7 ਅਤੇ ਨੋਡਸ ਦਾ ਇੱਕ ਪੂਲ n1-standard-4 ਆਟੋਮੈਟਿਕ ਨੋਡ ਸਕੇਲਿੰਗ ਦੇ ਨਾਲ (ਘੱਟੋ ਘੱਟ 4, ਅਧਿਕਤਮ 16)।

ਫਿਰ ਮੈਂ ਕਮਾਂਡ ਲਾਈਨ ਤੋਂ ਦੋਵੇਂ ਸੇਵਾ ਜਾਲਾਂ ਨੂੰ ਸਥਾਪਿਤ ਕੀਤਾ.

ਪਹਿਲਾ ਲਿੰਕਰਡ:

$ 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 |
+---------+--------------+---------+---------------------------+

ਫਿਰ 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      |
+---------+------------+---------+---------------------------+

ਕਰੈਸ਼-ਲੂਪ ਨੂੰ ਕੁਝ ਮਿੰਟ ਲੱਗੇ, ਅਤੇ ਫਿਰ ਕੰਟਰੋਲ ਪੈਨਲ ਸਥਿਰ ਹੋ ਗਏ।

(ਨੋਟ: ਸੁਪਰਗਲੂ ਹੁਣੇ ਲਈ ਸਿਰਫ Istio 1.0.x ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਮੈਂ Istio 1.1.3 ਨਾਲ ਪ੍ਰਯੋਗ ਦੁਹਰਾਇਆ, ਪਰ ਕੋਈ ਧਿਆਨ ਦੇਣ ਯੋਗ ਅੰਤਰ ਨਹੀਂ ਦੇਖਿਆ।)

Istio ਆਟੋਮੈਟਿਕ ਡਿਪਲਾਇਮੈਂਟ ਸੈਟ ਅਪ ਕਰਨਾ

Istio ਨੂੰ ਸਾਈਡਕਾਰ ਦੂਤ ਸਥਾਪਿਤ ਕਰਨ ਲਈ, ਅਸੀਂ ਸਾਈਡਕਾਰ ਇੰਜੈਕਟਰ - ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ MutatingAdmissionWebhook. ਅਸੀਂ ਇਸ ਲੇਖ ਵਿਚ ਇਸ ਬਾਰੇ ਗੱਲ ਨਹੀਂ ਕਰਾਂਗੇ. ਮੈਨੂੰ ਸਿਰਫ ਇਹ ਕਹਿਣ ਦਿਓ ਕਿ ਇਹ ਇੱਕ ਕੰਟਰੋਲਰ ਹੈ ਜੋ ਸਾਰੇ ਨਵੇਂ ਪੌਡਾਂ ਦੀ ਪਹੁੰਚ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦਾ ਹੈ ਅਤੇ ਗਤੀਸ਼ੀਲ ਤੌਰ 'ਤੇ ਇੱਕ ਸਾਈਡਕਾਰ ਅਤੇ initContainer ਜੋੜਦਾ ਹੈ, ਜੋ ਕੰਮਾਂ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ। iptables.

ਅਸੀਂ Shopify 'ਤੇ ਸਾਈਡਕਾਰਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਆਪਣਾ ਐਕਸੈਸ ਕੰਟਰੋਲਰ ਲਿਖਿਆ, ਪਰ ਇਸ ਬੈਂਚਮਾਰਕ ਲਈ ਮੈਂ ਕੰਟਰੋਲਰ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜੋ Istio ਦੇ ਨਾਲ ਆਉਂਦਾ ਹੈ. ਜਦੋਂ ਨੇਮਸਪੇਸ ਵਿੱਚ ਇੱਕ ਸ਼ਾਰਟਕੱਟ ਹੁੰਦਾ ਹੈ ਤਾਂ ਕੰਟਰੋਲਰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਸਾਈਡਕਾਰਸ ਨੂੰ ਇੰਜੈਕਟ ਕਰਦਾ ਹੈ 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 labeled

ਆਟੋਮੈਟਿਕ ਲਿੰਕਰਡ ਡਿਪਲਾਇਮੈਂਟ ਸੈੱਟਅੱਪ ਕਰਨਾ

ਲਿੰਕਰਡ ਸਾਈਡਕਾਰ ਏਮਬੈਡਿੰਗ ਨੂੰ ਸਥਾਪਤ ਕਰਨ ਲਈ, ਅਸੀਂ ਐਨੋਟੇਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ (ਮੈਂ ਉਹਨਾਂ ਨੂੰ ਹੱਥੀਂ ਜੋੜਿਆ ਹੈ 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: Active

Istio ਫਾਲਟ ਸਹਿਣਸ਼ੀਲਤਾ ਸਿਮੂਲੇਟਰ

ਅਸੀਂ Shopify ਲਈ ਵਿਲੱਖਣ ਟ੍ਰੈਫਿਕ ਨਾਲ ਪ੍ਰਯੋਗ ਕਰਨ ਲਈ Istio ਨਾਮਕ ਇੱਕ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਸਿਮੂਲੇਟਰ ਬਣਾਇਆ ਹੈ। ਸਾਨੂੰ ਇੱਕ ਕਸਟਮ ਟੌਪੋਲੋਜੀ ਬਣਾਉਣ ਲਈ ਇੱਕ ਟੂਲ ਦੀ ਲੋੜ ਸੀ ਜੋ ਸਾਡੇ ਸੇਵਾ ਗ੍ਰਾਫ ਦੇ ਇੱਕ ਖਾਸ ਹਿੱਸੇ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਖਾਸ ਵਰਕਲੋਡ ਨੂੰ ਮਾਡਲ ਬਣਾਉਣ ਲਈ ਗਤੀਸ਼ੀਲ ਰੂਪ ਵਿੱਚ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ।

ਫਲੈਸ਼ ਵਿਕਰੀ ਦੌਰਾਨ Shopify ਦਾ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਭਾਰੀ ਬੋਝ ਹੇਠ ਹੈ। ਉਸੇ ਸਮੇਂ, Shopify ਵਿਕਰੇਤਾਵਾਂ ਨੂੰ ਅਜਿਹੀ ਵਿਕਰੀ ਨੂੰ ਜ਼ਿਆਦਾ ਵਾਰ ਰੱਖਣ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰਦਾ ਹੈ. ਵੱਡੇ ਗਾਹਕ ਕਈ ਵਾਰ ਯੋਜਨਾਬੱਧ ਫਲੈਸ਼ ਵਿਕਰੀ ਬਾਰੇ ਚੇਤਾਵਨੀ ਦਿੰਦੇ ਹਨ। ਦੂਸਰੇ ਦਿਨ ਜਾਂ ਰਾਤ ਦੇ ਕਿਸੇ ਵੀ ਸਮੇਂ ਸਾਡੇ ਲਈ ਅਚਾਨਕ ਉਹਨਾਂ ਦਾ ਸੰਚਾਲਨ ਕਰਦੇ ਹਨ।

ਅਸੀਂ ਚਾਹੁੰਦੇ ਸੀ ਕਿ ਸਾਡਾ ਲਚਕਤਾ ਸਿਮੂਲੇਟਰ ਵਰਕਫਲੋਜ਼ ਨੂੰ ਮਾਡਲ ਬਣਾਵੇ ਜੋ ਟੌਪੋਲੋਜੀਜ਼ ਅਤੇ ਵਰਕਲੋਡਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਜੋ ਅਤੀਤ ਵਿੱਚ Shopify ਦੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਹਾਵੀ ਕਰ ਚੁੱਕੇ ਹਨ। ਸੇਵਾ ਜਾਲ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਮੁੱਖ ਉਦੇਸ਼ ਇਹ ਹੈ ਕਿ ਸਾਨੂੰ ਨੈੱਟਵਰਕ ਪੱਧਰ 'ਤੇ ਭਰੋਸੇਯੋਗਤਾ ਅਤੇ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਇਹ ਸਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਸੇਵਾ ਜਾਲ ਉਹਨਾਂ ਲੋਡਾਂ ਦਾ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰੇ ਜੋ ਪਹਿਲਾਂ ਸੇਵਾਵਾਂ ਵਿੱਚ ਵਿਘਨ ਪਾਉਂਦੇ ਸਨ।

ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਸਿਮੂਲੇਟਰ ਦੇ ਦਿਲ ਵਿੱਚ ਇੱਕ ਵਰਕਰ ਨੋਡ ਹੈ, ਜੋ ਕਿ ਇੱਕ ਸੇਵਾ ਜਾਲ ਨੋਡ ਦੇ ਤੌਰ ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ. ਵਰਕਰ ਨੋਡ ਨੂੰ ਸਟਾਰਟਅੱਪ 'ਤੇ ਸਥਿਰ ਤੌਰ 'ਤੇ ਸੰਰਚਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜਾਂ ਇੱਕ REST API ਦੁਆਰਾ ਗਤੀਸ਼ੀਲ ਰੂਪ ਵਿੱਚ ਸੰਰਚਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਅਸੀਂ ਰਿਗਰੈਸ਼ਨ ਟੈਸਟਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਵਰਕਫਲੋ ਬਣਾਉਣ ਲਈ ਵਰਕਰ ਨੋਡਾਂ ਦੀ ਗਤੀਸ਼ੀਲ ਸੰਰਚਨਾ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ।

ਇੱਥੇ ਅਜਿਹੀ ਪ੍ਰਕਿਰਿਆ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਹੈ:

• ਅਸੀਂ ਇਸ ਤਰ੍ਹਾਂ 10 ਸਰਵਰ ਲਾਂਚ ਕਰਦੇ ਹਾਂ bar ਸੇਵਾ ਜੋ ਜਵਾਬ ਵਾਪਸ ਕਰਦੀ ਹੈ 200/OK 100 ms ਬਾਅਦ.
• ਅਸੀਂ 10 ਗਾਹਕਾਂ ਨੂੰ ਲਾਂਚ ਕਰਦੇ ਹਾਂ - ਹਰ ਇੱਕ ਨੂੰ ਪ੍ਰਤੀ ਸਕਿੰਟ 100 ਬੇਨਤੀਆਂ ਭੇਜਦਾ ਹੈ bar.
• ਹਰ 10 ਸਕਿੰਟਾਂ ਵਿੱਚ ਅਸੀਂ 1 ਸਰਵਰ ਨੂੰ ਹਟਾਉਂਦੇ ਹਾਂ ਅਤੇ ਗਲਤੀਆਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦੇ ਹਾਂ 5xx ਗਾਹਕ 'ਤੇ.

ਵਰਕਫਲੋ ਦੇ ਅੰਤ 'ਤੇ, ਅਸੀਂ ਲੌਗਸ ਅਤੇ ਮੈਟ੍ਰਿਕਸ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਾਂ ਅਤੇ ਜਾਂਚ ਕਰਦੇ ਹਾਂ ਕਿ ਕੀ ਟੈਸਟ ਪਾਸ ਹੋਇਆ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ ਅਸੀਂ ਆਪਣੇ ਸੇਵਾ ਜਾਲ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਬਾਰੇ ਸਿੱਖਦੇ ਹਾਂ ਅਤੇ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਬਾਰੇ ਸਾਡੀਆਂ ਧਾਰਨਾਵਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਇੱਕ ਰੀਗਰੈਸ਼ਨ ਟੈਸਟ ਚਲਾਉਂਦੇ ਹਾਂ।

(ਨੋਟ: ਅਸੀਂ Istio ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਸਿਮੂਲੇਟਰ ਦੀ ਓਪਨ ਸੋਰਸਿੰਗ ਬਾਰੇ ਸੋਚ ਰਹੇ ਹਾਂ, ਪਰ ਅਜੇ ਤੱਕ ਅਜਿਹਾ ਕਰਨ ਲਈ ਤਿਆਰ ਨਹੀਂ ਹਾਂ।)

ਸੇਵਾ ਜਾਲ ਬੈਂਚਮਾਰਕ ਲਈ Istio ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਸਿਮੂਲੇਟਰ

ਅਸੀਂ ਸਿਮੂਲੇਟਰ ਦੇ ਕਈ ਕੰਮ ਕਰਨ ਵਾਲੇ ਨੋਡ ਸਥਾਪਤ ਕੀਤੇ:

• irs-client-loadgen: 3 ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਜੋ ਪ੍ਰਤੀ ਸਕਿੰਟ ਪ੍ਰਤੀ 100 ਬੇਨਤੀਆਂ ਭੇਜਦੀਆਂ ਹਨ irs-client.
• irs-client: 3 ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਜੋ ਬੇਨਤੀ ਪ੍ਰਾਪਤ ਕਰਦੀਆਂ ਹਨ, 100ms ਉਡੀਕ ਕਰੋ ਅਤੇ ਬੇਨਤੀ ਨੂੰ ਅੱਗੇ ਭੇਜੋ irs-server.
• irs-server: 3 ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਜੋ ਵਾਪਸ ਆਉਂਦੀਆਂ ਹਨ 200/OK 100 ms ਬਾਅਦ.

ਇਸ ਸੰਰਚਨਾ ਦੇ ਨਾਲ, ਅਸੀਂ 9 ਅੰਤ ਬਿੰਦੂਆਂ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਸਥਿਰ ਟ੍ਰੈਫਿਕ ਪ੍ਰਵਾਹ ਨੂੰ ਮਾਪ ਸਕਦੇ ਹਾਂ। ਵਿੱਚ Sidecars irs-client-loadgen и irs-server ਪ੍ਰਤੀ ਸਕਿੰਟ 100 ਬੇਨਤੀਆਂ ਪ੍ਰਾਪਤ ਕਰੋ, ਅਤੇ irs-client - 200 (ਇਨਕਮਿੰਗ ਅਤੇ ਆਊਟਗੋਇੰਗ)

ਅਸੀਂ ਦੁਆਰਾ ਸਰੋਤ ਦੀ ਵਰਤੋਂ ਨੂੰ ਟਰੈਕ ਕਰਦੇ ਹਾਂ ਡਾਟਾਡੌਗਕਿਉਂਕਿ ਸਾਡੇ ਕੋਲ ਪ੍ਰੋਮੀਥੀਅਸ ਕਲੱਸਟਰ ਨਹੀਂ ਹੈ।

Результаты

ਕੰਟਰੋਲ ਪੈਨਲ

ਪਹਿਲਾਂ, ਅਸੀਂ CPU ਦੀ ਖਪਤ ਦੀ ਜਾਂਚ ਕੀਤੀ।

ਲਿੰਕਰਡ ਕੰਟਰੋਲ ਪੈਨਲ ~22 ਮਿਲੀਕੋਰ

ਇਸਟੀਓ ਕੰਟਰੋਲ ਪੈਨਲ: ~ 750 ਮਿਲੀਕੋਰ

Istio ਕੰਟਰੋਲ ਪੈਨਲ ਲਗਭਗ ਵਰਤਦਾ ਹੈ 35 ਗੁਣਾ ਵੱਧ CPU ਸਰੋਤਲਿੰਕਰਡ ਨਾਲੋਂ. ਬੇਸ਼ੱਕ, ਸਭ ਕੁਝ ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਸਥਾਪਿਤ ਹੁੰਦਾ ਹੈ, ਅਤੇ istio-telemetry ਇੱਥੇ ਬਹੁਤ ਸਾਰੇ ਪ੍ਰੋਸੈਸਰ ਸਰੋਤਾਂ ਦੀ ਖਪਤ ਕਰਦਾ ਹੈ (ਇਸ ਨੂੰ ਕੁਝ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਅਸਮਰੱਥ ਬਣਾ ਕੇ ਅਯੋਗ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ). ਜੇਕਰ ਅਸੀਂ ਇਸ ਕੰਪੋਨੈਂਟ ਨੂੰ ਹਟਾ ਦਿੰਦੇ ਹਾਂ, ਤਾਂ ਸਾਨੂੰ ਅਜੇ ਵੀ 100 ਤੋਂ ਵੱਧ ਮਿਲਿਕੋਰ ਮਿਲਦੇ ਹਨ, ਯਾਨੀ 4 ਗੁਣਾ ਵਧੇਰੇਲਿੰਕਰਡ ਨਾਲੋਂ.

ਸਾਈਡਕਾਰ ਪ੍ਰੌਕਸੀ

ਅਸੀਂ ਫਿਰ ਇੱਕ ਪ੍ਰੌਕਸੀ ਦੀ ਵਰਤੋਂ ਦੀ ਜਾਂਚ ਕੀਤੀ। ਬੇਨਤੀਆਂ ਦੀ ਸੰਖਿਆ ਦੇ ਨਾਲ ਇੱਕ ਰੇਖਿਕ ਸਬੰਧ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਪਰ ਹਰੇਕ ਸਾਈਡਕਾਰ ਲਈ ਕੁਝ ਓਵਰਹੈੱਡ ਹੁੰਦਾ ਹੈ ਜੋ ਕਰਵ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ।

ਲਿੰਕਰਡ: ਆਈਆਰਐਸ-ਕਲਾਇੰਟ ਲਈ ~100 ਮਿਲੀਕੋਰ, ਆਈਆਰਐਸ-ਕਲਾਇੰਟ-ਲੋਡਜਨ ਲਈ ~50 ਮਿਲੀਕੋਰ

ਨਤੀਜੇ ਤਰਕਪੂਰਨ ਲੱਗਦੇ ਹਨ, ਕਿਉਂਕਿ ਕਲਾਇੰਟ ਪ੍ਰੌਕਸੀ ਲੋਡਜਨ ਪ੍ਰੌਕਸੀ ਨਾਲੋਂ ਦੁੱਗਣਾ ਟ੍ਰੈਫਿਕ ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ: ਲੋਡਜਨ ਤੋਂ ਹਰ ਬਾਹਰ ਜਾਣ ਦੀ ਬੇਨਤੀ ਲਈ, ਕਲਾਇੰਟ ਕੋਲ ਇੱਕ ਇਨਕਮਿੰਗ ਅਤੇ ਇੱਕ ਆਊਟਗੋਇੰਗ ਹੁੰਦਾ ਹੈ।

Istio/ਦੂਤ: IRs-ਕਲਾਇੰਟ ਲਈ ~155 ਮਿਲੀਕੋਰ, irs-client-loadgen ਲਈ ~75 ਮਿਲੀਕੋਰ

ਅਸੀਂ Istio sidecars ਲਈ ਸਮਾਨ ਨਤੀਜੇ ਦੇਖਦੇ ਹਾਂ।

ਪਰ ਆਮ ਤੌਰ 'ਤੇ, Istio/ਦੂਤ ਪ੍ਰੌਕਸੀ ਖਪਤ ਕਰਦੇ ਹਨ ਲਗਭਗ 50% ਹੋਰ CPU ਸਰੋਤਲਿੰਕਰਡ ਨਾਲੋਂ.

ਅਸੀਂ ਸਰਵਰ ਸਾਈਡ 'ਤੇ ਉਹੀ ਸਕੀਮ ਦੇਖਦੇ ਹਾਂ:

ਲਿੰਕਰਡ: ਆਈਆਰਐਸ-ਸਰਵਰ ਲਈ ~50 ਮਿਲੀਕੋਰ

Istio/ਦੂਤ: irs-ਸਰਵਰ ਲਈ ~80 ਮਿਲੀਕੋਰ

ਸਰਵਰ ਸਾਈਡ 'ਤੇ, ਸਾਈਡਕਾਰ ਇਸਟੀਓ/ਦੂਤ ਦੀ ਖਪਤ ਹੁੰਦੀ ਹੈ ਲਗਭਗ 60% ਹੋਰ CPU ਸਰੋਤਲਿੰਕਰਡ ਨਾਲੋਂ.

ਸਿੱਟਾ

Istio Envoy ਪ੍ਰੌਕਸੀ ਸਾਡੇ ਸਿਮੂਲੇਟਿਡ ਵਰਕਲੋਡ 'ਤੇ Linkerd ਨਾਲੋਂ 50+% ਜ਼ਿਆਦਾ CPU ਦੀ ਖਪਤ ਕਰਦੀ ਹੈ। ਲਿੰਕਰਡ ਕੰਟਰੋਲ ਪੈਨਲ Istio ਨਾਲੋਂ ਬਹੁਤ ਘੱਟ ਸਰੋਤਾਂ ਦੀ ਖਪਤ ਕਰਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਕੋਰ ਕੰਪੋਨੈਂਟਸ ਲਈ।

ਅਸੀਂ ਅਜੇ ਵੀ ਇਸ ਬਾਰੇ ਸੋਚ ਰਹੇ ਹਾਂ ਕਿ ਇਹਨਾਂ ਖਰਚਿਆਂ ਨੂੰ ਕਿਵੇਂ ਘੱਟ ਕੀਤਾ ਜਾਵੇ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਕੋਈ ਵਿਚਾਰ ਹੈ, ਤਾਂ ਕਿਰਪਾ ਕਰਕੇ ਸਾਂਝਾ ਕਰੋ!

ਸਰੋਤ: www.habr.com