Kubernetes Network Plugin (CNI) תוצאות benchmark מעל 10 Gbps רשת (עדכון: אפריל 2019)

זה העדכון שלי אמת מידה קודם, שפועל כעת על Kubernetes 1.14 עם גרסת ה-CNI העדכנית ביותר לאפריל 2019.

קודם כל, אני רוצה להודות לצוות Cilium: החבר'ה עזרו לי לבדוק ולתקן את התסריטים לניטור מדדים.

מה השתנה מאז נובמבר 2018

הנה מה שהשתנה מאז (אם אתה מעוניין):

פלנל נותר ממשק ה-CNI המהיר והפשוט ביותר, אך עדיין אינו תומך במדיניות רשת והצפנה.

רומנה כבר לא נתמכת, אז הסרנו אותה מהמדד.

WeaveNet תומך כעת במדיניות רשת עבור Ingress ו-Egress! אבל הפריון ירד.

ב-Calico, אתה עדיין צריך להגדיר באופן ידני את גודל המנות המרבי (MTU) לביצועים הטובים ביותר. Calico מציעה שתי אפשרויות להתקנת CNI, כך שתוכל להסתדר בלי מאגר ETCD נפרד:

• מצב אחסון בממשק ה-API של Kubernetes כמאגר נתונים (גודל אשכול < 50 צמתים);
• מצב אחסון ב-Kubernetes API כמאגר נתונים עם פרוקסי Typha כדי להקל על העומס על K8S API (גודל אשכול > 50 צמתים).

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

Cilium תומך כעת בהצפנה! Cilium מספקת הצפנה עם מנהרות IPSec ומציעה חלופה לרשת WeaveNet המוצפנת. אבל WeaveNet מהירה יותר מ-Cilium כשההצפנה מופעלת.

כעת קל יותר לפריסה של Cilium הודות לאופרטור ETCD המובנה.

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

הקשר בנצ'מרק

ההשוואה מופעלת על שלושה שרתי Supermicro שאינם וירטואליים עם מתג Supermicro של 10 ג'יגה-בייט. השרתים מחוברים ישירות למתג באמצעות כבלי DAC SFP+ פסיביים ומוגדרים על אותו VLAN עם מסגרות ג'מבו (MTU 9000).

Kubernetes 1.14.0 מותקן באובונטו 18.04 LTS עם Docker 18.09.2 (גרסת Docker ברירת המחדל במהדורה זו).

כדי לשפר את יכולת השחזור, החלטנו להגדיר תמיד את המאסטר בצומת הראשון, למקם את חלק השרת של ה-benchmark בשרת השני, ואת חלק הלקוח בשלישי. לשם כך, אנו משתמשים ב-NodeSelector בפריסות Kubernetes.

נתאר את תוצאות ההשוואה בסולם הבא:

בחירת CNI עבור מדד

זהו אמת מידה רק עבור CNI מהרשימה בסעיף על יצירת אשכול מאסטר אחד עם kubeadm עיין בתיעוד הרשמי של Kubernetes. מתוך 9 CNIs, ניקח רק 6: נשלל את אלה שקשה להתקין ו/או לא עובדים ללא תצורה לפי התיעוד (Romana, Contiv-VPP ו-JuniperContrail/TungstenFabric).

נשווה את ה-CNIs הבאים:

• Calico v3.6
• Canal v3.6 (בעצם פלנל לרשת + Calico כחומה)
• Cilium 1.4.2
• פלנל 0.11.0
• קיוב-נתב 0.2.5
• WeaveNet 2.5.1

התקנה

ככל שיהיה קל יותר להתקין את ה-CNI, כך הרושם הראשוני שלנו יהיה טוב יותר. כל ה-CNIs מהמדד קלים מאוד להתקנה (עם פקודה אחת או שתיים).

כפי שאמרנו, השרתים והמתג מוגדרים עם מסגרות ג'מבו מופעלות (הגדרנו את ה-MTU ל-9000). נשמח אם CNI יקבע אוטומטית את ה-MTU בהתבסס על תצורת המתאמים. עם זאת, רק Cilium ו- Flanell הצליחו בכך. לשאר ה-CNIs יש בקשות ב-GitHub להוסיף גילוי MTU אוטומטי, אך אנו נגדיר זאת באופן ידני על ידי שינוי ConfigMap עבור Calico, Canal ו-Kube-נתב, או העברת משתנה סביבה עבור WeaveNet.

מה הבעיה עם MTU שגוי? דיאגרמה זו מציגה את ההבדל בין WeaveNet עם ברירת המחדל של MTU ומסגרות ג'מבו מופעלות:

כיצד MTU משפיע על התפוקה?

ראינו כמה חשוב MTU לביצועים, עכשיו בואו נראה איך ה-CNI שלנו קובעים זאת באופן אוטומטי:

CNI מזהה אוטומטית MTU

הגרף מראה שעליך להגדיר את ה-MTU עבור Calico, Canal, Kube-Roter ו-WeaveNet לביצועים מיטביים. Cilium ו-Flannel הצליחו לקבוע נכון את ה-MTU בעצמם ללא כל הגדרות.

אבטחה

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

רק שני CNIs מצפינים נתונים: Cilium ו-WeaveNet. הצפנה WeaveNet מופעל על ידי הגדרת סיסמת ההצפנה כמשתנה סביבת CNI. IN תיעוד WeaveNet מתארת ​​את זה בצורה מסובכת, אבל הכל נעשה בפשטות. הצפנה סיליום מוגדר על ידי פקודות, על ידי יצירת סודות Kubernetes, ודרך שינוי של daemonSet (קצת יותר מסובך מאשר ב-WeaveNet, אבל ל-Cilium יש שלב אחר שלב הוראות).

באשר ליישום מדיניות הרשת, הם הצליחו Calico, Canal, Cilium ו-WeaveNet, שבו אתה יכול להגדיר כללי Ingress ו-Egress. ל קובי-נתב יש כללים רק עבור Ingress, ו פלָנֶל אין מדיניות רשת בכלל.

להלן התוצאות הכוללות:

תוצאות ביצועי בטיחות

פרודוקטיביות

אמת מידה זו מציגה את התפוקה הממוצעת לאורך שלוש ריצות לפחות של כל בדיקה. אנו בודקים את הביצועים של TCP ו-UDP (באמצעות iperf3), יישומים אמיתיים כמו HTTP (עם Nginx ו-curl) או FTP (עם vsftpd ו-curl) ולבסוף ביצועי אפליקציות באמצעות הצפנה מבוססת SCP (באמצעות לקוח ושרת OpenSSH).

עבור כל הבדיקות, ביצענו מדד מתכת חשוף (קו ירוק) כדי להשוות בין ביצועי CNI לביצועי רשת מקומיים. כאן אנו משתמשים באותו סולם, אבל בצבע:

• צהוב = טוב מאוד
• כתום = טוב
• כחול = כך-כך
• אדום = רע

לא ניקח CNIs שהוגדרו בצורה שגויה ונראה רק תוצאות עבור CNIs עם ה-MTU הנכון. (הערה: Cilium לא מחשב נכון את ה-MTU אם תפעיל הצפנה, אז תצטרך להפחית את ה-MTU באופן ידני ל-8900 בגרסה 1.4. הגרסה הבאה, 1.5, עושה זאת באופן אוטומטי.)

הנה התוצאות:

ביצועי TCP

כל ה-CNIs הציגו היטב במדד ה-TCP. CNI עם הצפנה מפגר הרבה מאחור מכיוון שההצפנה יקרה.

ביצועי UDP

גם כאן כל ה-CNI מצליחים. CNI עם הצפנה הראה כמעט את אותה תוצאה. Cilium קצת מאחורי המתחרים, אבל זה רק 2,3% של מתכת חשופה, אז זו תוצאה לא רעה. אל תשכח שרק Cilium ו-Flannel קבעו את ה-MTU בצורה נכונה בעצמם, ואלה התוצאות שלהם ללא כל תצורה נוספת.

מה לגבי אפליקציה אמיתית? כפי שאתה יכול לראות, הביצועים הכוללים עבור HTTP הם מעט נמוכים יותר מאשר עבור TCP. גם אם אתה משתמש ב-HTTP עם TCP, הגדרנו את iperf3 במבחן TCP כדי למנוע התחלה איטית שתשפיע על מדד HTTP. כולם עשו כאן עבודה טובה. ל-Kube-Roter יש יתרון ברור, אבל WeaveNet לא הצליחו: כ-20% גרועים יותר ממתכת חשופה. Cilium ו-WeaveNet עם הצפנה נראים ממש עצובים.

עם FTP, פרוטוקול נוסף מבוסס TCP, התוצאות משתנות. Flanell ו-Kube-Roter עושים את העבודה, אבל Calico, Canal ו-Cilium נמצאים קצת בפיגור והם איטיים בכ-10% ממתכת חשופה. WeaveNet נמצאת בפיגור של עד 17%, אבל WeaveNet המוצפנת מקדימה ב-40% את Cilium המוצפנת.

עם SCP נוכל לראות מיד כמה עולה לנו הצפנת SSH. כמעט כל ה-CNI מצליחים, אבל WeaveNet מפגרת שוב. Cilium ו-WeaveNet עם הצפנה צפויים להיות הגרועים ביותר בגלל הצפנה כפולה (SSH + CNI).

להלן טבלת סיכום עם התוצאות:

צריכת משאבים

כעת נשווה כיצד CNI צורך משאבים בעומסים כבדים (במהלך העברת TCP, 10 Gbps). במבחני ביצועים אנו משווים CNI עם מתכת חשופה (קו ירוק). לצריכת משאבים, בואו נראה Kubernetes טהור (קו סגול) ללא CNI ונראה כמה משאבים נוספים CNI צורך.

נתחיל בזיכרון. הנה הערך הממוצע של זיכרון RAM של צמתים (לא כולל מאגרים ומטמון) ב-MB במהלך ההעברה.

צריכת זיכרון

Flanell ו-Kube-ראוטר הראו תוצאות מצוינות - רק 50 MB. ל-Calico ול-Canal יש 70 כל אחת. WeaveNet צורכת בבירור יותר מהאחרים - 130 מגה-בייט, ו-Cilium משתמש ב-400.
עכשיו בואו נבדוק את צריכת זמן המעבד. ראוי לציון: התרשים לא מציג אחוזים, אלא ppm, כלומר, 38 ppm עבור "ברזל חשוף" הוא 3,8%. להלן התוצאות:

צריכת מעבד

Calico, Canal, Flannel ו-Kube-Roter יעילים מאוד במעבד - רק 2% יותר מ-Kubernetes ללא CNI. WeaveNet מפגרת הרחק מאחור עם תוספת של 5%, ואחריה Cilium ב-7%.

להלן סיכום של צריכת משאבים:

תוצאות של

טבלה עם כל התוצאות:

תוצאות בנצ'מרק כלליות

מסקנה

בחלק האחרון אביע את דעתי הסובייקטיבית על התוצאות. זכור שרף זה בודק רק את התפוקה של חיבור בודד על אשכול קטן מאוד (3 צמתים). זה לא חל על אשכולות גדולים (<50 צמתים) או חיבורים מקבילים.

אני ממליץ להשתמש ב-CNI הבאים בהתאם לתרחיש:

• האם יש לך באשכול שלך צמתים עם מעט משאבים (מספר ג'יגה-בייט של זיכרון RAM, מספר ליבות) ואתה לא צריך תכונות אבטחה - בחר פלָנֶל. זהו אחד ה-CNIs החסכוניים ביותר. והוא תואם למגוון רחב של ארכיטקטורות (amd64, arm, arm64 וכו'). בנוסף, זהו אחד משני (השני הוא Cilium) CNI שיכול לקבוע באופן אוטומטי את ה-MTU, כך שלא תצטרך להגדיר שום דבר. נתב Kube מתאים גם הוא, אבל הוא לא כסטנדרט ותצטרך להגדיר ידנית את ה-MTU.
• במידת הצורך להצפין את הרשת ליתר ביטחון, קח WeaveNet. אל תשכח לציין את גודל ה-MTU אם אתה משתמש במסגרות ג'מבו, ולאפשר הצפנה על ידי ציון סיסמה באמצעות משתנה סביבה. אבל עדיף לשכוח מהביצועים - זה עלות ההצפנה.
• עבור שימוש רגיל советую קאליקו. CNI זה נמצא בשימוש נרחב בכלי פריסה שונים של Kubernetes (Kops, Kubespray, Rancher וכו'). כמו ב-WeaveNet, הקפד להגדיר את ה-MTU ב-ConfigMap אם אתה משתמש במסגרות ג'מבו. זהו כלי רב תפקודי יעיל מבחינת צריכת משאבים, ביצועים ואבטחה.

ולבסוף, אני ממליץ לך לעקוב אחר ההתפתחות סיליום. ל-CNI הזה יש צוות מאוד פעיל שעובד הרבה על המוצר שלהם (תכונות, חיסכון במשאבים, ביצועים, אבטחה, אשכולות...) ויש להם תוכניות מאוד מעניינות.

תרשים חזותי לבחירת CNI

מקור: www.habr.com