תרשים עזר לארכיטקטורה של איזון עומסים בשכבה 7

ארכיטקטורת העזר הזו מספקת פתרון לאיזון עומסים בשכבה 7 בניהול הלקוח ב-Google Distributed Cloud (GDC)‎ עם Air Gap. לקוחות יכולים לפרוס בקרי קוד פתוח פופולריים כמו HAProxy Kubernetes Ingress או NGINX Gateway Fabric באשכול רגיל של GDC, וכך לנתב בצורה חלקה תנועה בשכבה 7 לסביבות היברידיות. הארכיטקטורה הזו משתמשת בסיום TLS‏ (Ingress / HTTPRoute) כדי לנתב תנועה על סמך ציון שם השרת (SNI) גם לפודים מובְנים בקונטיינרים וגם לאפליקציות שמתארחות במכונות וירטואליות חיצוניות.

תכונות ויכולות

  • ניתוב מתקדם בשכבה 7: תמיכה בניתוב מבוסס-מארח, בניתוב מבוסס-נתיב ובניהול מתקדם של תעבורת נתונים, כמו התאמה מבוססת-כותרת ושקלול תעבורת נתונים.
  • thought ניהול TLS ריכוזי: ניהול וסיום של TLS באופן ריכוזי.
  • תמיכה בסביבה היברידית: ניתוב חלק של תעבורת נתונים בשכבה 7 גם לפודים מובְנים בקונטיינרים וגם לאפליקציות שמתארחות במכונות וירטואליות חיצוניות.
  • אפשרויות גמישות לבקרים: אתם יכולים לבחור בין NGINX Gateway Fabric המודרני (באמצעות Gateway API) לבין HAProxy Ingress Controller המבוסס.
  • מוכנות ל-Air-Gap: שילוב עם Harbor Registry כדי לאחסן ולהציג תמונות של שרתי proxy ואפליקציות בסביבות פרטיות ומנותקות.
  • חלוקת תנועה מורכבת: מאפשרת אסטרטגיות מתקדמות של חלוקת תנועה לשליחת אפליקציות מודרניות.

עקרונות ארכיטקטוניים

  • תבנית איזון עומסים בשתי שכבות: הארכיטקטורה הזו משלבת את מאזן העומסים המובנה L4 של GDC (כנקודת הכניסה) עם שער L7 בניהול הלקוח שנפרס ב-Kubernetes.
  • הפרדה לפי תפקידים: העיצוב של Gateway API מפריד בין תחומי האחריות של ספקי התשתית, מפעילי האשכולות והמפתחים באמצעות משאבים ספציפיים (כמו GatewayClass,‏ Gateway ו-HTTPRoute או Ingress).
  • מעבר לתקנים מודרניים: הארכיטקטורה נותנת עדיפות ל-Gateway API בשביל יכולות ניתוב מודרניות, תוך שמירה על תמיכה ב-Ingress API מדור קודם במקרים שבהם נדרשת יציבות לבקרים ספציפיים.
  • גמישות בניהול הלקוחות: פריסת בקרים בניהול עצמי מאפשרת ללקוחות לשלוט בתכונות ובהגדרות של L7, שלא מסופקות באופן מקורי על ידי מאזן העומסים L4 שמנוהל על ידי GDC.
  • הפשטה של מיקום עומס העבודה: הארכיטקטורה מתייחסת לעומסי עבודה מבוססי-קונטיינרים ומבוססי-VM באופן עקבי באמצעות הפשטות של Kubernetes Service (רגילות או ללא ממשק משתמש).

ארכיטקטורה קונספטואלית

דיאגרמת ארכיטקטורה קונספטואלית של איזון עומסים בשכבה 7 ב-GDC עם air gap.

ארכיטקטורה לוגית

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

  1. נקודת כניסה של Ingress/Gateway: לקוח יוזם בקשות HTTPS שמגיעות קודם למאזן העומסים GDC L4. מאזן העומסים המובנה הזה משמש כנקודת הכניסה ומפיץ את תעבורת הנתונים של TCP/443 למאזן העומסים ברמת L7.
  2. מישור הבקרה: בקרי Ingress או Gateway (מפעילי HAProxy או NGINX) עוקבים אחרי משאבים ב-Kubernetes כמו Ingress,‏ Gateway ו-HTTPRoute
  3. מישור הנתונים: על סמך המשאבים שנצפו, הבקרים מעדכנים באופן דינמי את שרתי ה-Proxy הבסיסיים שמבצעים את הניתוב בפועל של תעבורת הנתונים, על סמך כללי מסלול מארחים שמבוססים על SNI וסיום TLS.
  4. שירותים לקצה העורפי:
    • פודים בקונטיינרים: מנוהלים כפריסות רגילות ונחשפים באמצעות שירותי Kubernetes רגילים.
    • מכונות וירטואליות חיצוניות: משולבות באשכול עם שירות Kubernetes ללא ממשק משתמש ונקודת קצה מותאמת אישית (או EndpointSlice) שמכילה את כתובת ה-IP הישירה של המכונה הווירטואלית.
  5. ניהול פריטי מידע שנוצרו בתהליך הפיתוח (Artifact): כל קובצי האימג' של שרתי ה-Proxy והאפליקציות מוצגים מ-Harbor Registry מקומי כדי להבטיח פונקציונליות בסביבה עם air gap.

מושגים וטכנולוגיות מרכזיים

הארכיטקטורה משתמשת בתבנית של איזון עומסים דו-שכבתי, שמשלבת את מאזן העומסים המובנה L4 של GDC עם שער L7 בניהול הלקוח שנפרס ב-Kubernetes. הרכיבים העיקריים כוללים:

  • לקוח: ישות שיוזמת בקשות HTTPS כדי ליצור אינטראקציה עם האפליקציות.
  • אשכול GDC רגיל: ב-GDC יש דרך מובנית ליצור אשכולות Kubernetes Vanilla. בפתרון הזה, האשכול יארח את מאזן העומסים L7 ואת הבקרים שלו, יחד עם עומסי העבודה והשירות ללא ממשק משתמש למכונות וירטואליות חיצוניות.
  • ‫GDC L4 Load Balancer: מאזן העומסים המובנה L4 משמש כנקודת הכניסה, ומפיץ את תנועת ה-TCP/443 ישירות לפודים של Kubernetes שמריצים את בקרי ה-Ingress או ה-Gateway.
  • בקרי Ingress ו-Gateway: אופרטורים של HAProxy או NGINX שפועלים באשכול הרגיל. ב-Nginx, הם עוקבים אחרי משאבי Gateway API (כמו Gateway ו-HTTPRoute) ומעדכנים באופן דינמי את שרתי ה-proxy הבסיסיים. ב-HAProxy, הם עוקבים אחרי המשאבים של Ingress ומעדכנים באופן דינמי את שרתי ה-proxy הבסיסיים.
    • HAProxy Ingress Controller: בקר Ingress ל-Kubernetes שמשתמש ב-HAProxy כשרת proxy הפוך וכמאזן עומסים בשכבה 7, וגם מטפל בסיום TLS.
    • ‫Nginx Gateway Fabric: הטמעה של Gateway API באמצעות NGINX בתור מישור הנתונים.
  • ‫Ingress ו-Gateway (עם HTTPRoute): משאבים סטנדרטיים של Kubernetes שמגדירים את יציאת ההאזנה הפיזית (443) ואת כללי הניתוב של המארח שמבוססים על SNI עם סיום TLS.
  • עומס עבודה בקונטיינרים (Pods): פריסה רגילה של Kubernetes שנחשפת באופן פנימי באמצעות Service רגיל של Kubernetes.
  • עומס עבודה מבוסס-VM (חיצוני): עומס עבודה שמתארח ב-VM חיצוני ברשת הפרויקט, ונחשף לשרת ה-proxy באמצעות Service ללא ממשק משתמש ב-Kubernetes ונקודת קצה מותאמת אישית שמכילה את כתובת ה-IP הישירה של ה-VM.
  • ‫Harbor Registry: Container Registry פרטי שמשמש לאחסון ולהצגה של קובצי האימג' של שרת ה-proxy ושל האפליקציה בסביבה עם air gap.

ממשקי Ingress API לעומת ממשקי Gateway API

תחום הרשתות של Kubernetes עובר מ-Ingress API מדור קודם ל-Gateway API המודרני. חשוב להבין את ההבדלים בין שתי האפשרויות האלה כדי לבחור את הארכיטקטורה המתאימה לעומסי העבודה שלכם.

  • ‫Ingress API: בעבר, Ingress היה הסטנדרט לניהול גישה חיצונית לשירותי HTTP. הוא מספק ניתוב מבוסס-מארח ומבוסס-נתיב, אבל העיצוב שלו בסיסי יחסית ואין לו תמיכה מובנית בניהול תנועה מתקדם (לדוגמה, התאמה מבוססת-כותרת או שקלול תנועה) בלי להסתמך על הערות ספציפיות לספק. חשוב לציין שקהילת Kubernetes מחשיבה עכשיו את Ingress API כתכונה קפואה (מגבלות Ingress והתפתחות הרשתות של Kubernetes).

  • ‫Gateway API: נקרא לעיתים קרובות V2 של Ingress. ‏Gateway API הוא אוסף של הגדרות משאבים בהתאמה אישית (CRD) שמספקות מודל חזק וניתן להרחבה יותר לרשתות שירות. הוא מיועד להיות מכוון תפקיד, ומפריד בין תחומי האחריות של ספקי התשתית (GatewayClass), מפעילי האשכולות (Gateway) והמפתחים (HTTPRoute/TLSRoute) (Gateway API ב-GKE). ההפרדה הזו מאפשרת שליטה פרטנית יותר ותמיכה טובה יותר בריבוי דיירים.

בפתרון הזה של GDC עם air gap, בחרנו בכוונה ממשקי API שונים לשני הבקרים:

  • ‫NGINX (Gateway API): בהטמעה של NGINX אנחנו משתמשים ב-NGINX Gateway Fabric, שהוא הטמעה מובנית ומתקדמת של Gateway API. שימוש ב-Gateway API ל-NGINX מאפשר ללקוחות ליהנות מהתקנים המודרניים ומיכולות הניתוב המתקדמות (כמו HTTPRoute) שמובנות ב-API.
  • ‫HAProxy (Ingress API): למרות שהכיוון האסטרטגי הוא Gateway API, במדריך הזה בחרנו ב-Ingress API ל-HAProxy. הסיבה לכך היא שהשילוב של Gateway API ב-HAProxy לא נחשב בשל. השימוש ב-HAProxy Ingress Controller המוכר מאפשר לנו לספק פתרון L7 יציב ואמין ללקוחות שמעדיפים את HAProxy, ועדיין לספק דרך ליכולות L7 מודרניות.

הנחות ואילוצים

הנחות

  • מוכנות התשתית: הפריסה מבוססת על הזמינות של אשכולות GDC עם air gap בגרסה 1.15.x Standard.
  • מרשם מקומי: ההנחה היא שמרשם Harbor מקומי מוגדר בצורה נכונה לאחסון ולהצגה של תמונות של שרתי proxy ואפליקציות בסביבה עם air gap.
  • נקודת כניסה מקומית: ההנחה היא שתעבורת הנתונים מגיעה קודם למאזן העומסים המובנה של GDC L4, שמפיץ את תעבורת הנתונים לשרתי ה-proxy של L7.

מגבלות

  • פתרון בניהול הלקוח: ב-GDC אין שירות L7 מנוהל שמגובה בהסכם SLA. הלקוח מנהל את ההטמעה הזו בעצמו.
  • אשכולות רגילים בלבד: אשכולות משותפים של משתמשים לא נכללים בהיקף, בגלל ההרשאות הגבוהות שנדרשות לפריסה של Ingress ושל Gateway Controller.
  • בשלות ה-API: בעוד ש-NGINX משתמש ב-Gateway API המודרני, HAProxy מוגבל ל-Ingress API כי השילוב שלו עם Gateway API עדיין לא נחשב בשל.
  • תחזוקה עם Air gap: צריך לקדם ולנהל באופן ידני את כל קובצי האימג' של הקונטיינרים בתוך המרשם המקומי של Harbor.
  • גרסאות קהילה: הארכיטקטורה מיועדת לגרסאות קהילה בקוד פתוח של Nginx ו-HAProxy. יכול להיות שמהדורות Enterprise יעבדו, אבל הן לא נבדקו באופן מפורש.
  • בעלות תפעולית: הלקוחות צריכים לנהל בעצמם את ההתאמה לעומס, הזמינות הגבוהה והתיקונים של בקרי הצד השלישי.
  • גבולות התמיכה: התמיכה של Google כוללת רק את התשתית הבסיסית של GDC. הלקוח או הספק אחראים לבעיות בתוכנות HAProxy או NGINX עצמן.
  • התיישנות של ה-API: קהילת Kubernetes הקפיאה את התכונות של Ingress API (שמשמש ל-HAProxy), מה שעלול להגביל את יכולות הניתוב בעתיד.

רישוי

  • מהדורות קהילתיות: הארכיטקטורה מיועדת למהדורות קהילתיות בקוד פתוח (בדרך כלל Apache 2.0 או דומה), שהשימוש בהן הוא בחינם אבל הן מנוהלות על ידי הלקוח.
  • רכש ארגוני: הלקוח אחראי באופן בלעדי לרכש ולניהול של רישיונות מסחריים, כמו NGINX Plus או HAProxy Enterprise.

חומרים נוספים