🥇CPU ಬಳಕೆಯ ಮಾನದಂಡ ಇಸ್ಟಿಯೊ ಮತ್ತು ಲಿಂಕರ್ಡ್

ಪರಿಚಯ

ನಾವು ಇದ್ದೇವೆ shopify ಇಸ್ಟಿಯೊವನ್ನು ಸೇವಾ ಜಾಲರಿಯಾಗಿ ನಿಯೋಜಿಸಲು ಪ್ರಾರಂಭಿಸಿದರು. ತಾತ್ವಿಕವಾಗಿ, ಒಂದು ವಿಷಯವನ್ನು ಹೊರತುಪಡಿಸಿ ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ: ಇದು ದುಬಾರಿಯಾಗಿದೆ.

В ಪ್ರಕಟಿಸಿದ ಮಾನದಂಡಗಳು ಇಸ್ಟಿಯೊಗೆ ಇದು ಹೇಳುತ್ತದೆ:

Istio 1.1 ನೊಂದಿಗೆ, ಪ್ರಾಕ್ಸಿಯು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 0,6 ವಿನಂತಿಗಳಿಗೆ ಸರಿಸುಮಾರು 1000 vCPU ಗಳನ್ನು (ವರ್ಚುವಲ್ ಕೋರ್‌ಗಳು) ಬಳಸುತ್ತದೆ.

ಸೇವಾ ಜಾಲರಿಯಲ್ಲಿನ ಮೊದಲ ಪ್ರದೇಶಕ್ಕಾಗಿ (ಸಂಪರ್ಕದ ಪ್ರತಿ ಬದಿಯಲ್ಲಿ 2 ಪ್ರಾಕ್ಸಿಗಳು), ನಾವು ಕೇವಲ ಪ್ರಾಕ್ಸಿಗಾಗಿ 1200 ಕೋರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಒಂದು ಮಿಲಿಯನ್ ವಿನಂತಿಗಳ ದರದಲ್ಲಿ. Google ನ ವೆಚ್ಚ ಕ್ಯಾಲ್ಕುಲೇಟರ್ ಪ್ರಕಾರ, ಕಾನ್ಫಿಗರೇಶನ್‌ಗಾಗಿ ಇದು ಸರಿಸುಮಾರು $40/ತಿಂಗಳು/ಕೋರ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ n1-standard-64, ಅಂದರೆ, ಈ ಪ್ರದೇಶವು ಸೆಕೆಂಡಿಗೆ 50 ಮಿಲಿಯನ್ ವಿನಂತಿಗಳಿಗೆ ತಿಂಗಳಿಗೆ 1 ಸಾವಿರ ಡಾಲರ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚು ವೆಚ್ಚವಾಗುತ್ತದೆ.

ಇವಾನ್ ಸಿಮ್ (ಇವಾನ್ ಸಿಮ್) ದೃಷ್ಟಿ ಹೋಲಿಸಲಾಗಿದೆ ಸೇವಾ ಜಾಲರಿಯು ಕಳೆದ ವರ್ಷ ವಿಳಂಬವಾಯಿತು ಮತ್ತು ಮೆಮೊರಿ ಮತ್ತು ಪ್ರೊಸೆಸರ್‌ಗೆ ಅದೇ ಭರವಸೆ ನೀಡಿತು, ಆದರೆ ಅದು ಕಾರ್ಯರೂಪಕ್ಕೆ ಬರಲಿಲ್ಲ:

ಸ್ಪಷ್ಟವಾಗಿ, values-istio-test.yaml CPU ವಿನಂತಿಗಳನ್ನು ಗಂಭೀರವಾಗಿ ಹೆಚ್ಚಿಸುತ್ತದೆ. ನಾನು ನನ್ನ ಗಣಿತವನ್ನು ಸರಿಯಾಗಿ ಮಾಡಿದ್ದರೆ, ನಿಯಂತ್ರಣ ಫಲಕಕ್ಕಾಗಿ ನಿಮಗೆ ಸರಿಸುಮಾರು 24 CPU ಕೋರ್‌ಗಳು ಮತ್ತು ಪ್ರತಿ ಪ್ರಾಕ್ಸಿಗೆ 0,5 CPU ಅಗತ್ಯವಿದೆ. ನನ್ನ ಬಳಿ ಅಷ್ಟು ಇಲ್ಲ. ನನಗೆ ಹೆಚ್ಚಿನ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹಂಚಿದಾಗ ನಾನು ಪರೀಕ್ಷೆಗಳನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತೇನೆ.

Istio ನ ಕಾರ್ಯಕ್ಷಮತೆಯು ಮತ್ತೊಂದು ತೆರೆದ ಮೂಲ ಸೇವಾ ಜಾಲರಿಯೊಂದಿಗೆ ಹೇಗೆ ಹೋಲುತ್ತದೆ ಎಂಬುದನ್ನು ನಾನೇ ನೋಡಲು ಬಯಸುತ್ತೇನೆ: ಲಿಂಕರ್ಡ್.

ಸೇವಾ ಜಾಲರಿ ಸ್ಥಾಪನೆ

ಮೊದಲನೆಯದಾಗಿ, ನಾನು ಅದನ್ನು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಸ್ಥಾಪಿಸಿದೆ ಸೂಪರ್ ಗ್ಲೂ:

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

ನಾನು SuperGloo ಅನ್ನು ಬಳಸಿದ್ದೇನೆ ಏಕೆಂದರೆ ಇದು ಸೇವಾ ಜಾಲರಿಯನ್ನು ಬೂಟ್‌ಸ್ಟ್ರ್ಯಾಪ್ ಮಾಡುವುದನ್ನು ಹೆಚ್ಚು ಸುಲಭಗೊಳಿಸುತ್ತದೆ. ನಾನು ಹೆಚ್ಚು ಮಾಡಬೇಕಾಗಿಲ್ಲ. ನಾವು ಉತ್ಪಾದನೆಯಲ್ಲಿ SuperGloo ಅನ್ನು ಬಳಸುವುದಿಲ್ಲ, ಆದರೆ ಅಂತಹ ಕಾರ್ಯಕ್ಕೆ ಇದು ಸೂಕ್ತವಾಗಿದೆ. ಪ್ರತಿ ಸೇವಾ ಜಾಲರಿಗಾಗಿ ನಾನು ಅಕ್ಷರಶಃ ಒಂದೆರಡು ಆಜ್ಞೆಗಳನ್ನು ಬಳಸಬೇಕಾಗಿತ್ತು. ನಾನು ಪ್ರತ್ಯೇಕತೆಗಾಗಿ ಎರಡು ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಬಳಸಿದ್ದೇನೆ - ಇಸ್ಟಿಯೊ ಮತ್ತು ಲಿಂಕರ್ಡ್‌ಗೆ ಪ್ರತಿಯೊಂದೂ.

Google Kubernetes ಎಂಜಿನ್‌ನಲ್ಲಿ ಪ್ರಯೋಗವನ್ನು ನಡೆಸಲಾಯಿತು. ನಾನು ಕುಬರ್ನೆಟ್ಸ್ ಬಳಸಿದ್ದೇನೆ 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 |
+---------+--------------+---------+---------------------------+

ನಂತರ ಇಸ್ಟಿಯೊ:

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

ಕ್ರ್ಯಾಶ್-ಲೂಪ್ ಕೆಲವು ನಿಮಿಷಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು, ಮತ್ತು ನಂತರ ನಿಯಂತ್ರಣ ಫಲಕಗಳನ್ನು ಸ್ಥಿರಗೊಳಿಸಲಾಯಿತು.

(ಗಮನಿಸಿ: SuperGloo ಸದ್ಯಕ್ಕೆ Istio 1.0.x ಅನ್ನು ಮಾತ್ರ ಬೆಂಬಲಿಸುತ್ತದೆ. Istio 1.1.3 ನೊಂದಿಗೆ ನಾನು ಪ್ರಯೋಗವನ್ನು ಪುನರಾವರ್ತಿಸಿದೆ, ಆದರೆ ಯಾವುದೇ ಗಮನಾರ್ಹ ವ್ಯತ್ಯಾಸವನ್ನು ಗಮನಿಸಲಿಲ್ಲ.)

ಇಸ್ಟಿಯೊ ಸ್ವಯಂಚಾಲಿತ ನಿಯೋಜನೆಯನ್ನು ಹೊಂದಿಸಲಾಗುತ್ತಿದೆ

ಇಸ್ಟಿಯೊ ಸೈಡ್‌ಕಾರ್ ಎನ್ವಾಯ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲು, ನಾವು ಸೈಡ್‌ಕಾರ್ ಇಂಜೆಕ್ಟರ್ - ಅನ್ನು ಬಳಸುತ್ತೇವೆ MutatingAdmissionWebhook. ಈ ಲೇಖನದಲ್ಲಿ ನಾವು ಅದರ ಬಗ್ಗೆ ಮಾತನಾಡುವುದಿಲ್ಲ. ಇದು ಎಲ್ಲಾ ಹೊಸ ಪಾಡ್‌ಗಳ ಪ್ರವೇಶವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ನಿಯಂತ್ರಕವಾಗಿದೆ ಮತ್ತು ಕಾರ್ಯಗಳಿಗೆ ಜವಾಬ್ದಾರರಾಗಿರುವ ಸೈಡ್‌ಕಾರ್ ಮತ್ತು initContainer ಅನ್ನು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಸೇರಿಸುತ್ತದೆ ಎಂದು ನಾನು ಹೇಳುತ್ತೇನೆ. iptables.

Shopify ನಲ್ಲಿ ನಾವು ಸೈಡ್‌ಕಾರ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಮ್ಮದೇ ಆದ ಪ್ರವೇಶ ನಿಯಂತ್ರಕವನ್ನು ಬರೆದಿದ್ದೇವೆ, ಆದರೆ ಈ ಮಾನದಂಡಕ್ಕಾಗಿ ನಾನು ಇಸ್ಟಿಯೊದೊಂದಿಗೆ ಬರುವ ನಿಯಂತ್ರಕವನ್ನು ಬಳಸಿದ್ದೇನೆ. ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಶಾರ್ಟ್‌ಕಟ್ ಇದ್ದಾಗ ನಿಯಂತ್ರಕವು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಸೈಡ್‌ಕಾರ್‌ಗಳನ್ನು ಇಂಜೆಕ್ಟ್ ಮಾಡುತ್ತದೆ 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

ಇಸ್ಟಿಯೊ ಫಾಲ್ಟ್ ಟಾಲರೆನ್ಸ್ ಸಿಮ್ಯುಲೇಟರ್

Shopify ಗೆ ವಿಶಿಷ್ಟವಾದ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಪ್ರಯೋಗಿಸಲು ನಾವು ಇಸ್ಟಿಯೊ ಎಂಬ ದೋಷ ಸಹಿಷ್ಣುತೆಯ ಸಿಮ್ಯುಲೇಟರ್ ಅನ್ನು ನಿರ್ಮಿಸಿದ್ದೇವೆ. ನಮ್ಮ ಸೇವಾ ಗ್ರಾಫ್‌ನ ನಿರ್ದಿಷ್ಟ ಭಾಗವನ್ನು ಪ್ರತಿನಿಧಿಸುವ ಕಸ್ಟಮ್ ಟೋಪೋಲಜಿಯನ್ನು ರಚಿಸಲು ನಮಗೆ ಉಪಕರಣದ ಅಗತ್ಯವಿದೆ, ನಿರ್ದಿಷ್ಟ ಕೆಲಸದ ಹೊರೆಗಳನ್ನು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ.

ಫ್ಲಾಶ್ ಮಾರಾಟದ ಸಮಯದಲ್ಲಿ Shopify ಮೂಲಸೌಕರ್ಯವು ಭಾರೀ ಹೊರೆಯಲ್ಲಿದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, Shopify ಅಂತಹ ಮಾರಾಟವನ್ನು ಹೆಚ್ಚಾಗಿ ಹಿಡಿದಿಡಲು ಮಾರಾಟಗಾರರಿಗೆ ಶಿಫಾರಸು ಮಾಡುತ್ತದೆ. ದೊಡ್ಡ ಗ್ರಾಹಕರು ಕೆಲವೊಮ್ಮೆ ಯೋಜಿತ ಫ್ಲಾಶ್ ಮಾರಾಟದ ಬಗ್ಗೆ ಎಚ್ಚರಿಸುತ್ತಾರೆ. ಇತರರು ಹಗಲು ಅಥವಾ ರಾತ್ರಿಯ ಯಾವುದೇ ಸಮಯದಲ್ಲಿ ನಮಗೆ ಅನಿರೀಕ್ಷಿತವಾಗಿ ಅವುಗಳನ್ನು ನಡೆಸುತ್ತಾರೆ.

ಹಿಂದೆ Shopify ಮೂಲಸೌಕರ್ಯವನ್ನು ಅತಿಕ್ರಮಿಸಿದ ಟೊಪೊಲಾಜಿಗಳು ಮತ್ತು ಕೆಲಸದ ಹೊರೆಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗುವ ಮಾದರಿಯ ವರ್ಕ್‌ಫ್ಲೋಗಳಿಗೆ ನಮ್ಮ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವ ಸಿಮ್ಯುಲೇಟರ್ ಅನ್ನು ನಾವು ಬಯಸುತ್ತೇವೆ. ಸೇವಾ ಜಾಲರಿಯನ್ನು ಬಳಸುವ ಮುಖ್ಯ ಉದ್ದೇಶವೆಂದರೆ ನಮಗೆ ನೆಟ್‌ವರ್ಕ್ ಮಟ್ಟದಲ್ಲಿ ವಿಶ್ವಾಸಾರ್ಹತೆ ಮತ್ತು ದೋಷ ಸಹಿಷ್ಣುತೆಯ ಅಗತ್ಯವಿರುತ್ತದೆ ಮತ್ತು ಈ ಹಿಂದೆ ಸೇವೆಗಳನ್ನು ಅಡ್ಡಿಪಡಿಸಿದ ಲೋಡ್‌ಗಳನ್ನು ಸೇವಾ ಜಾಲರಿಯು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ನಿಭಾಯಿಸುತ್ತದೆ ಎಂಬುದು ನಮಗೆ ಮುಖ್ಯವಾಗಿದೆ.

ದೋಷ ಸಹಿಷ್ಣುತೆಯ ಸಿಮ್ಯುಲೇಟರ್‌ನ ಹೃದಯಭಾಗದಲ್ಲಿ ವರ್ಕರ್ ನೋಡ್ ಇದೆ, ಇದು ಸೇವಾ ಜಾಲರಿ ನೋಡ್‌ನಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ವರ್ಕರ್ ನೋಡ್ ಅನ್ನು ಪ್ರಾರಂಭದಲ್ಲಿ ಸ್ಥಿರವಾಗಿ ಅಥವಾ REST API ಮೂಲಕ ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು. ರಿಗ್ರೆಶನ್ ಪರೀಕ್ಷೆಗಳ ರೂಪದಲ್ಲಿ ವರ್ಕ್‌ಫ್ಲೋಗಳನ್ನು ರಚಿಸಲು ನಾವು ವರ್ಕರ್ ನೋಡ್‌ಗಳ ಡೈನಾಮಿಕ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ.

ಅಂತಹ ಪ್ರಕ್ರಿಯೆಯ ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ:

ನಾವು 10 ಸರ್ವರ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ bar ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಹಿಂದಿರುಗಿಸುವ ಸೇವೆ 200/OK 100 ms ನಂತರ
ನಾವು 10 ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ - ಪ್ರತಿಯೊಂದೂ ಸೆಕೆಂಡಿಗೆ 100 ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುತ್ತದೆ bar.
ಪ್ರತಿ 10 ಸೆಕೆಂಡುಗಳು ನಾವು 1 ಸರ್ವರ್ ಅನ್ನು ತೆಗೆದುಹಾಕುತ್ತೇವೆ ಮತ್ತು ದೋಷಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತೇವೆ 5xx ಕ್ಲೈಂಟ್ ಮೇಲೆ.

ಕೆಲಸದ ಹರಿವಿನ ಕೊನೆಯಲ್ಲಿ, ನಾವು ಲಾಗ್‌ಗಳು ಮತ್ತು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇವೆ ಮತ್ತು ಪರೀಕ್ಷೆಯು ಉತ್ತೀರ್ಣವಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತೇವೆ. ಈ ರೀತಿಯಾಗಿ ನಾವು ನಮ್ಮ ಸೇವಾ ಮೆಶ್‌ನ ಕಾರ್ಯಕ್ಷಮತೆಯ ಬಗ್ಗೆ ಕಲಿಯುತ್ತೇವೆ ಮತ್ತು ದೋಷ ಸಹಿಷ್ಣುತೆಯ ಬಗ್ಗೆ ನಮ್ಮ ಊಹೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ರಿಗ್ರೆಷನ್ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸುತ್ತೇವೆ.

(ಗಮನಿಸಿ: ನಾವು ಇಸ್ಟಿಯೊ ದೋಷ ಸಹಿಷ್ಣುತೆಯ ಸಿಮ್ಯುಲೇಟರ್ ಅನ್ನು ತೆರೆದ ಸೋರ್ಸಿಂಗ್ ಮಾಡುವ ಬಗ್ಗೆ ಯೋಚಿಸುತ್ತಿದ್ದೇವೆ, ಆದರೆ ಇನ್ನೂ ಹಾಗೆ ಮಾಡಲು ಸಿದ್ಧವಾಗಿಲ್ಲ.)

ಸೇವಾ ಜಾಲರಿ ಮಾನದಂಡಕ್ಕಾಗಿ ಇಸ್ಟಿಯೊ ದೋಷ ಸಹಿಷ್ಣುತೆ ಸಿಮ್ಯುಲೇಟರ್

ನಾವು ಸಿಮ್ಯುಲೇಟರ್‌ನ ಹಲವಾರು ವರ್ಕಿಂಗ್ ನೋಡ್‌ಗಳನ್ನು ಹೊಂದಿಸಿದ್ದೇವೆ:

irs-client-loadgen: ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 3 ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುವ 100 ಪ್ರತಿಕೃತಿಗಳು irs-client.
irs-client: ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸುವ 3 ಪ್ರತಿಗಳು, 100ms ನಿರೀಕ್ಷಿಸಿ ಮತ್ತು ವಿನಂತಿಯನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಿ irs-server.
irs-server: ಹಿಂತಿರುಗಿಸುವ 3 ಪ್ರತಿಕೃತಿಗಳು 200/OK 100 ms ನಂತರ

ಈ ಸಂರಚನೆಯೊಂದಿಗೆ, ನಾವು 9 ಅಂತಿಮ ಬಿಂದುಗಳ ನಡುವೆ ಸ್ಥಿರವಾದ ಸಂಚಾರ ಹರಿವನ್ನು ಅಳೆಯಬಹುದು. ಸೈಡ್‌ಕಾರ್‌ಗಳು ಒಳಗೆ irs-client-loadgen и irs-server ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 100 ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸಿ, ಮತ್ತು irs-client - 200 (ಒಳಬರುವ ಮತ್ತು ಹೊರಹೋಗುವ).

ನಾವು ಸಂಪನ್ಮೂಲ ಬಳಕೆಯನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುತ್ತೇವೆ ಡೇಟಾಡಾಗ್ಏಕೆಂದರೆ ನಮ್ಮಲ್ಲಿ ಪ್ರಮೀತಿಯಸ್ ಕ್ಲಸ್ಟರ್ ಇಲ್ಲ.

ರೆಸೆಲ್ಯೂಟ್ಸ್

ನಿಯಂತ್ರಣ ಫಲಕಗಳು

ಮೊದಲಿಗೆ, ನಾವು CPU ಬಳಕೆಯನ್ನು ಪರಿಶೀಲಿಸಿದ್ದೇವೆ.

ಲಿಂಕರ್ಡ್ ನಿಯಂತ್ರಣ ಫಲಕ ~22 ಮಿಲಿಕೋರ್

ಇಸ್ಟಿಯೊ ನಿಯಂತ್ರಣ ಫಲಕ: ~ 750 ಮಿಲಿಕೋರ್

ಇಸ್ಟಿಯೊ ನಿಯಂತ್ರಣ ಫಲಕವು ಸರಿಸುಮಾರು ಬಳಸುತ್ತದೆ 35 ಪಟ್ಟು ಹೆಚ್ಚು CPU ಸಂಪನ್ಮೂಲಗಳುಲಿಂಕರ್ಡ್ ಗಿಂತ. ಸಹಜವಾಗಿ, ಎಲ್ಲವನ್ನೂ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಸ್ಥಾಪಿಸಲಾಗಿದೆ, ಮತ್ತು istio-ಟೆಲಿಮೆಟ್ರಿ ಇಲ್ಲಿ ಬಹಳಷ್ಟು ಪ್ರೊಸೆಸರ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುತ್ತದೆ (ಕೆಲವು ಕಾರ್ಯಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವ ಮೂಲಕ ಇದನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬಹುದು). ನಾವು ಈ ಘಟಕವನ್ನು ತೆಗೆದುಹಾಕಿದರೆ, ನಾವು ಇನ್ನೂ 100 ಮಿಲಿಕೋರ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚು ಪಡೆಯುತ್ತೇವೆ, ಅಂದರೆ 4 ಪಟ್ಟು ಹೆಚ್ಚುಲಿಂಕರ್ಡ್ ಗಿಂತ.

ಸೈಡ್‌ಕಾರ್ ಪ್ರಾಕ್ಸಿ

ನಾವು ನಂತರ ಪ್ರಾಕ್ಸಿಯ ಬಳಕೆಯನ್ನು ಪರೀಕ್ಷಿಸಿದ್ದೇವೆ. ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯೊಂದಿಗೆ ರೇಖಾತ್ಮಕ ಸಂಬಂಧವಿರಬೇಕು, ಆದರೆ ಪ್ರತಿ ಸೈಡ್‌ಕಾರ್‌ಗೆ ಕರ್ವ್‌ನ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ ಕೆಲವು ಓವರ್‌ಹೆಡ್ ಇರುತ್ತದೆ.

ಲಿಂಕರ್ಡ್: ಐಆರ್ಎಸ್-ಕ್ಲೈಂಟ್‌ಗೆ ~100 ಮಿಲಿಕೋರ್‌ಗಳು, ಐಆರ್‌ಎಸ್-ಕ್ಲೈಂಟ್-ಲೋಡ್‌ಜೆನ್‌ಗಾಗಿ ~50 ಮಿಲಿಕೋರ್‌ಗಳು

ಫಲಿತಾಂಶಗಳು ತಾರ್ಕಿಕವಾಗಿ ಕಾಣುತ್ತವೆ, ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್ ಪ್ರಾಕ್ಸಿಯು ಲೋಡ್‌ಜೆನ್ ಪ್ರಾಕ್ಸಿಗಿಂತ ಎರಡು ಪಟ್ಟು ಹೆಚ್ಚು ಟ್ರಾಫಿಕ್ ಅನ್ನು ಪಡೆಯುತ್ತದೆ: ಲೋಡ್‌ಜೆನ್‌ನಿಂದ ಹೊರಹೋಗುವ ಪ್ರತಿಯೊಂದು ವಿನಂತಿಗೆ, ಕ್ಲೈಂಟ್‌ಗೆ ಒಂದು ಒಳಬರುವ ಮತ್ತು ಹೊರಹೋಗುವ ಒಂದು ಇರುತ್ತದೆ.

ಇಸ್ಟಿಯೊ/ರಾಯಭಾರಿ: ಐಆರ್‌ಎಸ್-ಕ್ಲೈಂಟ್‌ಗಾಗಿ ~155 ಮಿಲಿಕೋರ್‌ಗಳು, ಐಆರ್‌ಎಸ್-ಕ್ಲೈಂಟ್-ಲೋಡ್‌ಜೆನ್‌ಗಾಗಿ ~75 ಮಿಲಿಕೋರ್‌ಗಳು

ಇಸ್ಟಿಯೊ ಸೈಡ್‌ಕಾರ್‌ಗಳಿಗೆ ನಾವು ಇದೇ ರೀತಿಯ ಫಲಿತಾಂಶಗಳನ್ನು ನೋಡುತ್ತೇವೆ.

ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ, Istio/Envoy ಪ್ರಾಕ್ಸಿಗಳು ಸೇವಿಸುತ್ತವೆ ಸರಿಸುಮಾರು 50% ಹೆಚ್ಚು CPU ಸಂಪನ್ಮೂಲಗಳುಲಿಂಕರ್ಡ್ ಗಿಂತ.

ನಾವು ಸರ್ವರ್ ಬದಿಯಲ್ಲಿ ಅದೇ ಯೋಜನೆಯನ್ನು ನೋಡುತ್ತೇವೆ:

ಲಿಂಕರ್ಡ್: ಐಆರ್ಎಸ್-ಸರ್ವರ್‌ಗಾಗಿ ~50 ಮಿಲಿಕೋರ್

ಇಸ್ಟಿಯೊ/ರಾಯಭಾರಿ: ಐಆರ್ಎಸ್-ಸರ್ವರ್‌ಗಾಗಿ ~80 ಮಿಲಿಕೋರ್

ಸರ್ವರ್ ಬದಿಯಲ್ಲಿ, ಸೈಡ್‌ಕಾರ್ ಇಸ್ಟಿಯೊ/ರಾಯಭಾರಿ ಬಳಸುತ್ತಾರೆ ಸರಿಸುಮಾರು 60% ಹೆಚ್ಚು CPU ಸಂಪನ್ಮೂಲಗಳುಲಿಂಕರ್ಡ್ ಗಿಂತ.

ತೀರ್ಮಾನಕ್ಕೆ

ಇಸ್ಟಿಯೊ ಎನ್ವಾಯ್ ಪ್ರಾಕ್ಸಿಯು ನಮ್ಮ ಸಿಮ್ಯುಲೇಟೆಡ್ ವರ್ಕ್‌ಲೋಡ್‌ನಲ್ಲಿ ಲಿಂಕರ್ಡ್‌ಗಿಂತ 50+% ಹೆಚ್ಚು CPU ಅನ್ನು ಬಳಸುತ್ತದೆ. ಲಿಂಕರ್ಡ್ ನಿಯಂತ್ರಣ ಫಲಕವು ಇಸ್ಟಿಯೊಗಿಂತ ಕಡಿಮೆ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುತ್ತದೆ, ವಿಶೇಷವಾಗಿ ಪ್ರಮುಖ ಘಟಕಗಳಿಗೆ.

ಈ ವೆಚ್ಚವನ್ನು ಹೇಗೆ ಕಡಿಮೆ ಮಾಡುವುದು ಎಂಬುದರ ಕುರಿತು ನಾವು ಇನ್ನೂ ಯೋಚಿಸುತ್ತಿದ್ದೇವೆ. ನೀವು ಆಲೋಚನೆಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ದಯವಿಟ್ಟು ಹಂಚಿಕೊಳ್ಳಿ!

ಮೂಲ: www.habr.com

Istio ಮತ್ತು Linkerd ಗಾಗಿ CPU ಬಳಕೆಯ ಮಾನದಂಡ