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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

השוואה מפורטת של יכולות Ingress

רשת לקוח

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

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

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

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

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

סוג הרשת פתרונות זמינים
פנימי שירות ClusterIP
שירות NodePort
שירות Internal LoadBalancer
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 לפי שני הממדים האלה.

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

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

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

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

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

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

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

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

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

Service mesh

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

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