סקירה והשוואה של בקרי Ingress עבור Kubernetes

בעת השקת אשכול Kubernetes עבור אפליקציה ספציפית, עליך להבין מה האפליקציה עצמה, העסק והמפתחים מציבים בפני משאב זה. בעזרת המידע הזה תוכלו להתחיל לקבל החלטה ארכיטקטונית ובעיקר לבחור בבקר Ingress ספציפי, שכבר היום יש מספר גדול ממנו. על מנת לקבל מושג בסיסי על האפשרויות הזמינות מבלי לעבור על הרבה מאמרים/תיעוד וכו', הכנו סקירה כללית זו, כולל בקרי ה-Ingress העיקריים (המוכנים לייצור).

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

קריטריונים

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

אבל אתחיל עם המאפיינים שנעשו כל כך מוכרים שהם מיושמים בכל הפתרונות ואינם נחשבים:

• גילוי דינמי של שירותים (גילוי שירות);
• סיום SSL;
• עבודה עם websockets.

עכשיו לנקודות ההשוואה:

פרוטוקולים נתמכים

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

תוכנה בבסיס

ישנן מספר וריאציות של יישומים שהבקר מבוסס עליהם. הפופולריים שבהם הם nginx, traefik, haproxy, envoy. במקרה הכללי, אולי אין לזה השפעה רבה על האופן שבו תעבורה מתקבלת ומשודרת, אבל תמיד כדאי לדעת את הניואנסים והתכונות הפוטנציאליות של מה שנמצא "מתחת למכסה המנוע".

ניתוב תנועה

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

מרחב שמות בתוך אשכול

מרחב שמות (מרחב שמות) - היכולת לפצל משאבים באופן לוגי ב-Kubernetes (לדוגמה, על הבמה, הפקה וכו'). ישנם בקרי Ingress שחייבים להתקין בנפרד בכל מרחב שמות (ואז הוא יכול להפנות תעבורה רק לתרמילים של החלל הזה). ויש כאלה (והרוב המובהק שלהם) שעובדים גלובלית עבור כל האשכול - בהם התנועה מופנית לכל פוד של האשכול, ללא קשר למרחב השמות.

דוגמאות למעלה זרמים

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

אלגוריתמי איזון

ישנן אפשרויות רבות: ממסורתיות רובין העגול אל האקזוטי rdp-cookie, כמו גם תכונות בודדות כמו מפגשים דביקים.

אימות

באילו סכימות הרשאה תומך הבקר? Basic, digest, oauth, external-auth - אני חושב שהאפשרויות האלה צריכות להיות מוכרות. זהו קריטריון חשוב אם יש הרבה לולאות מפתחים (ו/או סתם פרטיות) שהגישה אליהן מתבצעת דרך Ingress.

חלוקת התנועה

האם הבקר תומך במנגנוני הפצת תעבורה נפוצים כמו יציאות קנריות (קנריות), בדיקת A/B, שיקוף תנועה (שיקוף / הצללה)? זהו נושא כואב מאוד עבור יישומים הדורשים ניהול תעבורה מדויק ומדויק לצורך בדיקות פרודוקטיביות, איתור באגים של מוצרים במצב לא מקוון (או עם אובדן מינימלי), ניתוח תעבורה וכו'.

מנוי בתשלום

האם יש אפשרות בתשלום לבקר, עם פונקציונליות מתקדמת ו/או תמיכה טכנית?

ממשק משתמש גרפי (ממשק אינטרנט)

האם יש GUI לניהול תצורת הבקר? בעיקר בשביל "ידיות" ו/או למי שצריך לעשות כמה שינויים בתצורת Ingress'a, אבל עבודה עם תבניות "גולמיות" היא לא נוחה. זה יכול להיות שימושי אם מפתחים רוצים לערוך כמה ניסויים עם תנועה תוך כדי תנועה.

אימות JWT

נוכחות של אימות מובנה של אסימוני אינטרנט של JSON להרשאה ואימות של המשתמש ליישום הקצה.

אפשרויות להתאמה אישית של תצורה

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

מנגנוני הגנה בסיסיים של DDOS

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

בקש מעקב

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

WAF

תמיכה חומת אש של אפליקציה.

בקרים

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

כניסה מ-Kubernetes

אתר אינטרנט: github.com/kubernetes/ingress-nginx
רישיון: Apache 2.0

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

Ingress מאת NGINX Inc.

אתר אינטרנט: github.com/nginxinc/kubernetes-ingress
רישיון: Apache 2.0

המוצר הרשמי של מפתחי nginx. יש גרסה בתשלום המבוססת על NGINX Plus. הרעיון המרכזי הוא רמה גבוהה של יציבות, תאימות מתמדת לאחור, היעדר מודולים זרים והמהירות המוצהרת המוצהרת (בהשוואה לבקר הרשמי), המושגת עקב דחיית Lua.

הגרסה החינמית מופחתת באופן משמעותי, כולל אפילו בהשוואה לבקר הרשמי (בשל היעדר אותם מודולי Lua). יחד עם זאת, לתשלום יש פונקציונליות נוספת רחבה למדי: מדדי זמן אמת, אימות JWT, בדיקות בריאות אקטיביות ועוד. יתרון חשוב על פני NGINX Ingress הוא תמיכה מלאה בתעבורת TCP / UDP (וגם בגרסת הקהילה!). מינוס - היעדרות תכונת הפצת תנועה, אשר, עם זאת, "יש לה העדיפות הגבוהה ביותר עבור מפתחים", אך לוקח זמן ליישם.

קונג אינגרס

אתר אינטרנט: github.com/Kong/kubernetes-ingress-controller
רישיון: Apache 2.0

מוצר שפותח על ידי Kong Inc. בשתי גרסאות: מסחרית וחינמית. מבוסס על nginx, שהורחב עם מספר רב של מודולי Lua.

בתחילה, הוא התמקד בעיבוד ובניתוב בקשות API, כלומר. בתור API Gateway, אבל כרגע הוא הפך לבקר Ingress מן המניין. יתרונות עיקריים: מודולים רבים נוספים (כולל אלה ממפתחי צד שלישי) שקל להתקין ולהגדיר ובעזרתם מיושם מגוון רחב של פיצ'רים נוספים. עם זאת, פונקציות מובנות כבר מציעות אפשרויות רבות. תצורת העבודה נעשית באמצעות משאבי CRD.

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

טראפיק

אתר אינטרנט: github.com/containous/traefik
רישיון: MIT

פרוקסי שנוצר במקור כדי לעבוד עם ניתוב בקשות עבור שירותי מיקרו והסביבה הדינמית שלהם. מכאן, תכונות שימושיות רבות: עדכון התצורה מבלי לאתחל כלל, תמיכה במספר רב של שיטות איזון, ממשק אינטרנט, העברת מדדים, תמיכה בפרוטוקולים שונים, REST API, מהדורות קנריות ועוד ועוד. תכונה נחמדה נוספת היא תמיכה בתעודות Let's Encrypt מהקופסה. החיסרון הוא שכדי לארגן זמינות גבוהה (HA), הבקר יצטרך להתקין ולחבר אחסון KV משלו.

HAProxy

אתר אינטרנט: github.com/jcmoraisjr/haproxy-ingress
רישיון: Apache 2.0

HAProxy ידועה זה מכבר כפרוקסי ומאזן תעבורה. כחלק מאשכול Kubernetes, הוא מציע עדכון תצורה "רך" (ללא אובדן תעבורה), גילוי שירות המבוסס על DNS, תצורה דינמית באמצעות API. זה יכול להיות אטרקטיבי להתאים אישית לחלוטין את תבנית התצורה על ידי החלפת ה-CM, כמו גם את היכולת להשתמש בפונקציות ספריית Sprig בה. באופן כללי, הדגש העיקרי של הפתרון הוא על מהירות גבוהה, אופטימיזציה שלו ויעילות במשאבים הנצרכים. היתרון של הבקר הוא תמיכה במספר שיא של שיטות איזון שונות.

נוֹסֵעַ

אתר אינטרנט: github.com/appscode/voyager
רישיון: Apache 2.0

מבוסס על בקר HAproxy, הממוקם כפתרון אוניברסלי התומך במגוון רחב של תכונות במספר רב של ספקים. מוצעת הזדמנות לאיזון תעבורה ב-L7 ו-L4, ואיזון תעבורת TCP L4 כולה יכול להיקרא אחד ממאפייני המפתח של הפתרון.

קונטור

אתר אינטרנט: github.com/heptio/contour
רישיון: Apache 2.0

הפתרון הזה לא מבוסס רק על Envoy: הוא פותח על ידי במשותף עם מחברי הפרוקסי הפופולרי הזה. תכונה חשובה היא היכולת להפריד שליטה במשאבי Ingress באמצעות משאבי IngressRoute CRD. עבור ארגונים עם צוותי פיתוח רבים המשתמשים באותו אשכול, זה עוזר למקסם את האבטחה של עבודה עם תעבורה בלולאות שכנות ולהגן עליהם מפני שגיאות בעת שינוי משאבי Ingress.

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

Istio Ingress

אתר אינטרנט: istio.io/docs/tasks/traffic-management/ingress
רישיון: Apache 2.0

פתרון רשת שירות מקיף שהוא לא רק בקר Ingress שמנהל את התעבורה הנכנסת מבחוץ, אלא גם שולט בכל התעבורה בתוך האשכול. מתחת למכסה המנוע, Envoy משמש כפרוקסי צדדי עבור כל שירות. בעצם, מדובר בשילוב גדול ש"יכול לעשות הכל", והרעיון המרכזי שלו הוא יכולת ניהול מקסימלית, הרחבה, אבטחה ושקיפות. בעזרתו, אתה יכול לכוונן את ניתוב התעבורה, לגשת להרשאות בין שירותים, איזון, ניטור, שחרורים קנריים ועוד הרבה יותר. קרא עוד על Istio בסדרת הכתבות "חזרה לשירותי מיקרו עם Istio".

שַׁגְרִיר

אתר אינטרנט: github.com/datawire/ambassador
רישיון: Apache 2.0

פתרון נוסף המבוסס על Envoy. יש לו גרסאות חינמיות ומסחריות. הוא ממוקם כ"מקורי לחלוטין ל-Kubernetes", מה שמביא את היתרונות המקבילים (אינטגרציה הדוקה עם השיטות והישויות של אשכול K8s).

טבלת השוואה

אז, שיאו של המאמר הוא הטבלה הענקית הזו:

ניתן ללחוץ עליו לצפייה מקרוב, והוא זמין גם בפורמט גיליונות אלקטרוניים של Google.

לסיכום

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

ה-Ingress הקלאסי מ-Kubernetes טוב לזמינות ולהוכחות שלו, תכונות עשירות מספיק - במקרה הכללי, זה צריך להיות "מספיק לעיניים". עם זאת, אם יש דרישות מוגברות ליציבות, לרמת התכונות והפיתוח, כדאי לשים לב ל-Ingress עם NGINX Plus ומנוי בתשלום. לקונג יש את סט התוספים העשיר ביותר (ובהתאם, ההזדמנויות שהם מספקים), ובגרסה בתשלום יש אפילו יותר מהם. יש לו הזדמנויות רבות לעבוד כשער API, תצורה דינמית המבוססת על משאבי CRD, כמו גם שירותי Kubernetes בסיסיים.

עם דרישות מוגברות לשיטות איזון והרשאה, תסתכל על Traefik ו- HAProxy. מדובר בפרויקטי קוד פתוח, שהוכחו לאורך שנים, יציבים מאוד ומתפתחים באופן פעיל. Contour יצא כבר כמה שנים, אבל זה עדיין נראה צעיר מדי ויש לו רק תכונות בסיסיות שנוספו על גבי Envoy. אם יש דרישות לנוכחות / הטמעה של WAF מול האפליקציה, כדאי לשים לב לאותה Ingress מ-Kubernetes או HAProxy.

והעשירים ביותר מבחינת תכונות הם מוצרים שנבנו על גבי Envoy, במיוחד Istio. נראה שזהו פתרון מקיף ש"יכול לעשות הכל", מה שמשמעותו, עם זאת, גם סף כניסה גבוה משמעותית להגדרה / השקה / ניהול מאשר פתרונות אחרים.

בחרנו ועדיין משתמשים ב-Ingress מ-Kubernetes כבקר סטנדרטי, שמכסה 80-90% מהצרכים. זה די אמין, קל להגדיר ולהרחיב. באופן כללי, בהיעדר דרישות ספציפיות, זה אמור להתאים לרוב האשכולות / היישומים. מתוך אותם מוצרים אוניברסליים ופשוטים יחסית, ניתן להמליץ ​​על Traefik ו- HAProxy.

נ.ב.

קרא גם בבלוג שלנו:

• "חזרה לשירותי מיקרו עם Istio": חלק 1 (מבוא לתכונות העיקריות), חלק 2 (ניתוב, בקרת תנועה), חלק 3 (אימות והרשאה);
• «עצות וטריקים של Kubernetes: דפי שגיאה מותאמים אישית ב-NGINX Ingress";
• «עצות וטריקים של Kubernetes: גישה לאתרי פיתוח".

מקור: www.habr.com