אמת מידה לצריכת מעבד עבור Istio ו-Linkerd

מבוא

אנחנו בפנים Shopify החלה לפרוס את Istio כרשת שירות. עקרונית הכל בסדר חוץ מדבר אחד: זה יקר.

В מדדים שפורסמו עבור Istio כתוב:

עם Istio 1.1, ה-proxy צורך כ-0,6 vCPUs (ליבות וירטואליות) לכל 1000 בקשות בשנייה.

עבור האזור הראשון ברשת השירות (2 פרוקסי בכל צד של החיבור), יהיו לנו 1200 ליבות רק עבור ה-proxy, בקצב של מיליון בקשות בשנייה. לפי מחשבון העלויות של גוגל, זה מסתבר להיות כ-$40 לחודש/ליבה עבור תצורה n1-standard-64כלומר, האזור הזה לבדו יעלה לנו יותר מ-50 אלף דולר לחודש עבור מיליון בקשות בשנייה.

איוון סים (איוון סים) השוואה ויזואלית רשת שירות עיכובים בשנה שעברה והבטיחו את אותו הדבר עבור זיכרון ומעבד, אבל זה לא הסתדר:

ככל הנראה, values-istio-test.yaml יגדיל ברצינות את בקשות המעבד. אם ביצעתי את החישוב נכון, אתה צריך כ-24 ליבות מעבד עבור לוח הבקרה ו-0,5 מעבד עבור כל פרוקסי. אין לי כל כך הרבה. אחזור על הבדיקות כאשר יוקצו לי משאבים נוספים.

רציתי לראות בעצמי עד כמה הביצועים של Istio דומים לרשת אחרת של שירות קוד פתוח: לינקרד.

התקנת רשת שירות

קודם כל, התקנתי אותו באשכול SuperGloo:

$ 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 בייצור, אבל הוא אידיאלי למשימה כזו. הייתי צריך להשתמש ממש בכמה פקודות עבור כל רשת שירות. השתמשתי בשני אשכולות לבידוד - אחד כל אחד עבור Istio ו-Linkerd.

הניסוי נערך ב-Google Kubernetes Engine. השתמשתי ב-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, אך לא הבחנתי בהבדל ניכר).

הגדרת פריסה אוטומטית של Istio

כדי לגרום ל-Istio להתקין את הקרון הצדדי Envoy, אנו משתמשים במזרק הקרון הצידי - 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

הגדרת פריסה אוטומטית של Linkerd

כדי להגדיר הטבעה צדדית של Linkerd, אנו משתמשים בהערות (הוספתי אותן ידנית באמצעות 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

בנינו סימולטור סובלנות תקלות בשם Istio כדי להתנסות בתנועה ייחודית ל- Shopify. היינו צריכים כלי ליצירת טופולוגיה מותאמת אישית שתייצג חלק מסוים מגרף השירות שלנו, המוגדר באופן דינמי למודל של עומסי עבודה ספציפיים.

התשתית של Shopify נמצאת תחת עומס כבד במהלך מכירות הבזק. במקביל, Shopify ממליץ למוכרים לקיים מכירות כאלה לעתים קרובות יותר. לקוחות גדולים מתריעים לפעמים על מכירה בזק מתוכננת. אחרים מנהלים אותם באופן בלתי צפוי עבורנו בכל שעה של היום או הלילה.

רצינו שסימולטור החוסן שלנו ידגמן זרימות עבודה התואמות את הטופולוגיות ועומסי העבודה שהכריעו את התשתית של Shopify בעבר. המטרה העיקרית של שימוש ברשת שירות היא שאנו זקוקים לאמינות וסובלנות תקלות ברמת הרשת, וחשוב לנו שרשת השירות תתמודד ביעילות עם עומסים שבעבר שיבשו שירותים.

בליבו של סימולטור סובלנות תקלות נמצא צומת עובד, הפועל כצומת רשת שירות. ניתן להגדיר את צומת העובד באופן סטטי בעת ההפעלה או באופן דינמי באמצעות REST API. אנו משתמשים בתצורה דינמית של צמתי עובדים כדי ליצור זרימות עבודה בצורה של מבחני רגרסיה.

הנה דוגמה לתהליך כזה:

• אנו משיקים 10 שרתים כ bar שירות שמחזיר תגובה 200/OK לאחר 100 אלפיות השנייה
• אנו משיקים 10 לקוחות - כל אחד שולח אליהם 100 בקשות בשנייה bar.
• כל 10 שניות אנו מסירים שרת אחד ומנטרים שגיאות 5xx על הלקוח.

בסיום תהליך העבודה אנו בוחנים את היומנים והמדדים ובודקים האם המבחן עבר. בדרך זו אנו לומדים על הביצועים של רשת השירות שלנו ומריצים מבחן רגרסיה כדי לבחון את ההנחות שלנו לגבי סובלנות תקלות.

(הערה: אנחנו חושבים על מקורות פתוחים לסימולטור סובלנות התקלות של Istio, אבל עדיין לא מוכנים לעשות זאת.)

סימולטור סובלנות תקלות של Istio למבחן רשת שירות

הגדרנו מספר צמתים עבודה של הסימולטור:

• irs-client-loadgen: 3 העתקים ששולחים 100 בקשות בשנייה לכל irs-client.
• irs-client: 3 העתקים שמקבלים את הבקשה, ממתינים 100ms ומעבירים את הבקשה ל irs-server.
• irs-server: 3 העתקים שחוזרים 200/OK לאחר 100 אלפיות השנייה

עם תצורה זו, אנו יכולים למדוד זרימת תנועה יציבה בין 9 נקודות קצה. קרונות צד פנימה irs-client-loadgen и irs-server לקבל 100 בקשות בשנייה, וכן irs-client - 200 (נכנסים ויוצאים).

אנו עוקבים אחר השימוש במשאבים באמצעות נתוניםכי אין לנו אשכול פרומתאוס.

ממצאים

לוחות בקרה

ראשית, בדקנו את צריכת המעבד.

לוח בקרה Linkerd ~22 מילי ליבות

לוח הבקרה של Istio: ~750 מיליליקור

לוח הבקרה של Istio משתמש בערך פי 35 משאבי מעבדמאשר לינקרד. כמובן, הכל מותקן כברירת מחדל, וה-istio-telemetry צורכת כאן משאבי מעבד רבים (ניתן לנטרל אותה על ידי השבתת פונקציות מסוימות). אם נסיר את הרכיב הזה, עדיין נקבל יותר מ-100 מיליקורים, כלומר 4 פעמים נוספותמאשר לינקרד.

Proxy Sidecar

לאחר מכן בדקנו את השימוש בפרוקסי. צריך להיות קשר ליניארי עם מספר הבקשות, אבל עבור כל צדדי יש תקורה כלשהי שמשפיעה על העקומה.

Linkerd: ~100 מילילייבות עבור irs-client, ~50 מילילייבות עבור irs-client-loadgen

התוצאות נראות הגיוניות, מכיוון שפרוקסי הלקוח מקבל תעבורה כפולה מזו של פרוקסי ה-loadgen: עבור כל בקשה יוצאת מ-loadgen, ללקוח יש אחד נכנס ואחד יוצא.

Istio/Envoy: ~155 מילילייבות עבור irs-client, ~75 מילילייבות עבור irs-client-loadgen

אנו רואים תוצאות דומות עבור מכוניות צד של Istio.

אבל באופן כללי, פרוקסי Istio/Envoy צורכים כ-50% יותר משאבי מעבדמאשר לינקרד.

אנו רואים את אותה סכימה בצד השרת:

Linkerd: ~50 מילי-קורות עבור שרת irs

Istio/Envoy: ~80 מילי-קורות עבור irs-server

בצד השרת, Sidecar Istio/Envoy צורך כ-60% יותר משאבי מעבדמאשר לינקרד.

מסקנה

ה-proxy של Istio Envoy צורך 50+% יותר מעבד מ-Linkerd בעומס העבודה המדומה שלנו. לוח הבקרה של Linkerd צורך הרבה פחות משאבים מאשר Istio, במיוחד עבור רכיבי הליבה.

אנחנו עדיין חושבים כיצד להפחית את העלויות הללו. אם יש לכם רעיונות, אנא שתפו!

מקור: www.habr.com