הערכת ביצועי CNI עבור רשת Kubernetes מעל 10G (אוגוסט 2020)

TL; DR: כל ה-CNIs עובדים כמו שהם צריכים, למעט Kube-Router ו-Kube-OVN, Calico, למעט זיהוי MTU אוטומטי, הוא הטוב ביותר.

עדכון מאמר של בדיקות העבר שלי (2018 и 2019), בזמן הבדיקה אני משתמש ב-Kubernetes 1.19 ב-Ubuntu 18.04 עם CNIs מעודכנים החל מאוגוסט 2020.

לפני שנצלול למדדים...

מה חדש מאז אפריל 2019?

• יכול לבדוק באשכול משלך: אתה יכול להריץ בדיקות באשכול משלך באמצעות הכלי שלנו Benchmark של רשת Kubernetes: knb
• חברים חדשים הופיעו
  • מנה ראשונה מ-VMware Tanzu
  • Kube-OVN מאת alauda.io
• תרחישים חדשים: בדיקות נוכחיות מרצות מבחני ביצועי רשת "Pod-to-Pod", ונוסף סקריפט חדש של "Pod-to-Service" שמריץ בדיקות קרוב יותר לתנאים בעולם האמיתי. בפועל, Pod with API שלך עובד עם הבסיס כשירות, ולא דרך כתובת ה-IP של Pod (כמובן שאנחנו בודקים גם TCP וגם UDP עבור שני התרחישים).
• צריכת משאבים: לכל בדיקה יש כעת השוואת משאבים משלה
• הסרת בדיקות יישומים: איננו מבצעים עוד בדיקות HTTP, FTP ו-SCP מכיוון ששיתוף הפעולה הפורה שלנו עם הקהילה ועם מתחמי ה-CNI גילה פער בין תוצאות iperf על פני TCP לבין תוצאות סלסול עקב עיכוב בהפעלת CNI (השניות הראשונות של Pod הפעלה, שאינה אופיינית בתנאים אמיתיים).
• קוד פתוח: כל מקורות הבדיקה (סקריפטים, הגדרות yml ונתוני "גולמיים" מקוריים) זמינים כאן

פרוטוקול בדיקת התייחסות

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

בחירת CNI להערכה

בדיקה זו נועדה להשוות CNIs המוגדרים עם קובץ yaml אחד (לכן, כל אלה שהותקנו על ידי סקריפטים, כגון VPP ואחרים, אינם נכללים).

ה-CNI שנבחרו להשוואה:

• Antrea v.0.9.1
• Calico v3.16
• Canal v3.16 (מדיניות רשת פלנל + Calico)
• Cilium 1.8.2
• פלנל 0.12.0
• העדכנית ביותר של נתב Kube (2020–08–25)
• WeaveNet 2.7.0

הגדרת MTU עבור CNI

קודם כל, אנו בודקים את ההשפעה של זיהוי MTU אוטומטי על ביצועי TCP:

השפעת MTU על ביצועי TCP

פער גדול עוד יותר נמצא בעת שימוש ב-UDP:

השפעת MTU על ביצועי UDP

בהתחשב בהשפעת הביצועים העצומה שהתגלתה בבדיקות, ברצוננו לשלוח מכתב תקווה לכל מתחזקי ה-CNI: אנא הוסף זיהוי MTU אוטומטי ל-CNI. תוכלו להציל חתלתולים, חדי קרן ואפילו את החמוד ביותר: ה-Devop הקטן.

עם זאת, אם אתה צריך להשתמש ב-CNI ללא תמיכה בזיהוי MTU אוטומטי, אתה יכול להגדיר אותו באופן ידני כדי לקבל ביצועים. שימו לב שזה חל על Calico, Canal ו-WeaveNet.

בקשתי הקטנה ל-CNI הנלווים...

בדיקת CNI: נתונים גולמיים

בחלק זה נשווה את ה-CNI עם ה-MTU הנכון (נקבע אוטומטית או מוגדר ידנית). המטרה העיקרית כאן היא להציג את הנתונים הגולמיים בגרפים.

אגדת צבע:

• אפור - מדגם (כלומר ברזל חשוף)
• ירוק - רוחב פס מעל 9500 Mbps
• צהוב - רוחב פס מעל 9000 Mbps
• כתום - רוחב פס מעל 8000 Mbps
• אדום - רוחב פס מתחת ל-8000 Mbps
• כחול - ניטרלי (לא קשור לרוחב פס)

צריכת משאבים ללא עומס

קודם כל, בדוק את צריכת המשאבים כאשר האשכול "ישן".

צריכת משאבים ללא עומס

תרמיל אל תרמיל

תרחיש זה מניח שה-Pod של הלקוח מתחבר ישירות ל-Pod של השרת באמצעות כתובת ה-IP שלו.

תרחיש של תרמיל

TCP

תוצאות TCP של Pod-to-Pod וצריכת משאבים מתאימה:

UDP

תוצאות UDP של Pod-to-Pod וצריכת משאבים מתאימה:

Pod-to-Service

סעיף זה רלוונטי למקרי שימוש אמיתיים, Pod הלקוח מתחבר לפוד השרת באמצעות שירות ClusterIP.

סקריפט Pod-to-Service

TCP

תוצאות TCP של Pod-to-Service וצריכת משאבים מתאימה:

UDP

תוצאות UDP של Pod-to-Service וצריכת משאבים מתאימה:

תמיכה במדיניות רשת

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

הצפנת CNI

בין ה-CNIs שנבדקו יש כאלה שיכולים להצפין חילופי רשת בין Pods:

• Antrea באמצעות IPsec
• Calico באמצעות מגן תיל
• Cilium באמצעות IPsec
• WeaveNet באמצעות IPsec

תפוקה

מכיוון שנותרו פחות CNIs, בואו נשים את כל התרחישים בגרף אחד:

צריכת משאבים

בסעיף זה, נעריך את המשאבים המשמשים בעת עיבוד תקשורת Pod-to-Pod ב-TCP ו-UDP. אין טעם לצייר גרף Pod-to-Service מכיוון שהוא אינו מספק מידע נוסף.

מחברים את הכל ביחד

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

מסקנה ומסקנות שלי

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

אני שמח שהופיעו CNIs חדשים, Antrea ביצעה היטב, פונקציות רבות יושמו אפילו בגרסאות מוקדמות: זיהוי MTU אוטומטי, הצפנה והתקנה קלה.

אם נשווה ביצועים, כל ה-CNI פועלים היטב, מלבד Kube-OVN ו-Kube-Router. Kube-Router גם לא הצליח לזהות את ה-MTU, לא מצאתי דרך להגדיר אותו בשום מקום בתיעוד (כאן בקשה בנושא זה פתוחה).

במונחים של צריכת משאבים, Cilium עדיין משתמש יותר ב-RAM מאחרים, אבל היצרן מכוון בבירור לאשכולות גדולים, וזה בבירור לא זהה לבדיקה על אשכול בעל שלושה צמתים. Kube-OVN גם צורך הרבה משאבי CPU ו-RAM, אבל זה CNI צעיר המבוסס על Open vSwitch (כמו Antrea, הוא מתפקד טוב יותר וצורך פחות).

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

כמו כן, בין היתר, ביצועי ההצפנה מדהימים. Calico הוא אחד ה-CNIs הוותיקים ביותר, אך הצפנה נוספה רק לפני שבועיים. הם בחרו ב-wireguard במקום ב-IPsec, ובפשטות, זה עובד נהדר ומדהים, מאפיל לחלוטין על CNIs אחרים בחלק הזה של הבדיקה. כמובן שצריכת המשאבים עולה בגלל ההצפנה, אבל התפוקה שהושגה שווה את זה (Calico הציגה שיפור של פי שישה במבחן ההצפנה לעומת Cilium שנמצא במקום השני). יתרה מכך, אתה יכול להפעיל wireguard בכל עת לאחר פריסת Calico לאשכול, ותוכל גם להשבית אותו לזמן קצר או לצמיתות אם תרצה. עם זאת, זה נוח להפליא! אנו מזכירים לכם ש-Calico לא מזהה כעת MTU באופן אוטומטי (תכונה זו מתוכננת לגרסאות עתידיות), לכן הקפידו להגדיר את ה-MTU אם הרשת שלכם תומכת במסגרות Jumbo (MTU 9000).

בין היתר, שימו לב ש-Cilium יכול להצפין תעבורה בין צמתי אשכולות (ולא רק בין Pods), מה שיכול להיות חשוב מאוד לצמתי אשכול ציבורי.

לסיכום, אני מציע את מקרי השימוש הבאים:

• צריך CNI לאשכול קטן מאוד או שאני לא צריך אבטחה: לעבוד עם פלָנֶל, ה-CNI הקל והיציב ביותר (הוא גם אחד העתיקים ביותר, לפי האגדה הוא הומצא על ידי Homo Kubernautus או Homo Contaitorus). אולי יעניין אותך גם בפרויקט הגאוני ביותר k3, חשבון!
• צריך CNI לאשכול רגיל: קאליקו - בחירתך, אך אל תשכח להגדיר את ה-MTU במידת הצורך. אתה יכול בקלות ובאופן טבעי לשחק עם מדיניות רשת, להפעיל ולכבות הצפנה וכו'.
• צריך CNI עבור אשכול בקנה מידה גדול (מאוד).: ובכן, הבדיקה לא מראה את ההתנהגות של אשכולות גדולים, אני אשמח לערוך בדיקות, אבל אין לנו מאות שרתים עם חיבור של 10Gbps. אז האפשרות הטובה ביותר היא להריץ בדיקה שונה על הצמתים שלך, לפחות עם Calico ו-Cilium.

מקור: www.habr.com