סקירה כללית על רשתות שירות ב-GKE

בדף הזה מוסבר איך אפשר לפרוס שירותים ב-Google Kubernetes Engine ‏ (GKE). הדף הזה נועד לעזור לכם להבין טוב יותר את ההיבטים של Service Networking ואת התכונות של Service Network שקיימות ב-GKE.

סקירה כללית על Service Networking

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

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

רכיבים של שירות

חשיפת אפליקציה ללקוחות כוללת שלושה רכיבים מרכזיים של שירות:

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

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

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

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

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

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

הסבר על איזון עומסים ב-GKE

כדי לחשוף אפליקציות מחוץ לאשכול GKE,‏ GKE מספק בקר GKE Ingress ובקר GKE Service מובנים, שפורסים מאזני עומסים בשם משתמשי GKE. התשתית הזו זהה לתשתית של איזון עומסים במכונות וירטואליות, אבל מחזור החיים שלה אוטומטי לגמרי ונשלט על ידי GKE. בקרי הרשת של GKE מספקים איזון עומסים של כתובות IP של Pods שמותאמות לקונטיינרים, באמצעות ממשקים ברמה גבוהה יותר שמתאימים לתקנים של Ingress ו-Service API.

הדיאגרמה הבאה ממחישה איך בקרי הרשת של GKE יוצרים מאזני עומסים באופן אוטומטי:

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

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

בחירת השיטה לחשיפת האפליקציה

כשבוחרים שיטה לחשיפת האפליקציה ב-GKE, הגורמים העיקריים שצריך לקחת בחשבון הם הרשת, הפרוטוקול והאזוריות של האפליקציה והלקוח. חבילת בקרים של Ingress ו-Service ב-GKE מאפשרת לחשוף את האפליקציות תוך התחשבות בכל אחד מהגורמים האלה.

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

השוואה מפורטת של יכולות Ingress זמינה במאמר בנושא הגדרת Ingress.

רשת לקוח

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

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

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

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

בטבלה הבאה מפורטים הפתרונות שזמינים לרשתות פנימיות וחיצוניות.

סוג הרשת פתרונות זמינים
פנימי שירות ClusterIP
שירות NodePort
שירות Internal LoadBalancer
Internal Ingress
חיצוני ‫NodePort Service1
External LoadBalancer Service
External Ingress
Multi Cluster Ingress

‫1 באשכולות GKE שמוגדרים עם הדגל --no-enable-private-nodes יכולים להיות צמתים עם כתובות IP ציבוריות ופרטיות, ולכן אפשר לגשת לשירותי NodePort באופן פנימי וחיצוני.

פרוטוקול

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

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

שכבות פרוטוקולים פתרונות זמינים
L4 TCP
UDP		 שירות ClusterIP
שירות NodePort
שירות Internal LoadBalancer
שירות External LoadBalancer
L7 HTTP
HTTPS
HTTP2 		Internal Ingress
External Ingress
Multi Cluster Ingress

מיקוד לפי אזורים באפליקציה

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

אפשר לחלק את הפתרונות לאיזון עומסים ב-GKE לפי אזור לשני תחומים:

  • היקף קצה עורפי (או היקף אשכול): ההיקף הזה מתייחס לשאלה אם מאזן עומסים יכול לשלוח תנועה לקצוות עורפיים בכמה אשכולות GKE. ל-Multi Cluster Ingress יש אפשרות לחשוף כתובת IP וירטואלית אחת שמפנה תנועה ל-Pods מאשכולות שונים ומאזורים שונים.

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

בטבלה הבאה מפורטים פתרונות איזון העומסים ב-GKE לפי שני המאפיינים האלה.

היקף הרשאות בקצה העורפי
(היקף הרשאות באשכול)		 פתרונות זמינים
אשכול יחיד שירות ClusterIP
שירות NodePort
שירות Internal LoadBalancer
שירות External LoadBalancer
Internal Ingress
External Ingress
אשכול מרובה Multi Cluster Ingress
היקף הקצה הקדמי פתרונות זמינים
אזורי שירות ClusterIP
Internal Ingress
עולמי ‫ClusterIP Service
‫NodePort Service
‫Internal LoadBalancer Service
‫External LoadBalancer Service
‫External Ingress
‫Multi Cluster Ingress

פתרונות אחרים לחשיפת אפליקציות

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

תעבורת נתונים נכנסת (ingress) בתוך האשכול

תעבורת נתונים נכנסת (ingress) בתוך האשכול מתייחסת לבקרי תעבורת נתונים נכנסת (ingress) של תוכנה, ששרתי ה-proxy של תעבורת הנתונים הנכנסת (ingress) שלהם מתארחים בתוך אשכול Kubernetes עצמו. הם שונים מאמצעי הבקרה של GKE Ingress, שמארחים ומנהלים את תשתית איזון העומסים שלהם בנפרד מאשכול Kubernetes. פתרונות צד שלישי כאלה נפרסים ומנוהלים בדרך כלל על ידי מפעיל האשכול. istio-ingressgateway ו-nginx-ingress הן שתי דוגמאות לבקרי Ingress בתוך האשכול שנמצאים בשימוש נפוץ וזמינים כקוד פתוח.

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

קבוצות עצמאיות של נקודות קצה ברשת (NEGs)

בקרי GKE Ingress ו-Service מספקים שיטות אוטומטיות, הצהרתיות ומקוריות של Kubernetes לפריסת Cloud Load Balancing. יש גם תרחישי שימוש תקפים לפריסה ידנית של מאזני עומסים עבור קצה עורפי של GKE, למשל שליטה ישירה ופרטנית יותר במאזן העומסים, או איזון עומסים בין קצה עורפי של קונטיינר וקצה עורפי של מכונת VM.

קבוצות NEGs עצמאיות מספקות את היכולת הזו על ידי עדכון דינמי של כתובות ה-IP של קצה עורפי של Pod עבור קבוצת NEG, אבל מאפשרות פריסה ידנית של קצה קדמי של מאזן העומסים. כך מקבלים שליטה מקסימלית וישירה במאזן העומסים, תוך שמירה על עורפי דינמיים שנשלטים על ידי אשכול GKE.

Service mesh

רשתות Service mesh מספקות איזון עומסים בצד הלקוח באמצעות מישור בקרה מרכזי. ‫Cloud Service Mesh מאפשר איזון עומסים של תעבורה פנימית בין אשכולות GKE, בין אזורים וגם בין קונטיינרים ומכונות וירטואליות. הדבר הזה מטשטש את ההבדל בין איזון עומסים פנימי (תנועה ממזרח למערב) לבין חשיפת האפליקציה (תנועה מצפון לדרום). בזכות הגמישות וההיקף של מישורי הבקרה המודרניים של Service mesh, סביר יותר מתמיד שהלקוח והשרת יהיו באותו היקף של Service mesh. פתרונות GKE Ingress ו-Service שצוינו למעלה בדרך כלל פורסים מאזני עומסים של פרוקסי באמצע עבור לקוחות שאין להם פרוקסי sidecar משלהם. עם זאת, אם הלקוח והשרת נמצאים באותה רשת משנה, אפשר לטפל בחשיפה של האפליקציה באמצעות הרשת המשנה ולא באמצעות איזון עומסים של שרת proxy ביניים.

המאמרים הבאים