ארכיטקטורת העזר הזו מספקת פתרון מאוזן עומסים בשכבה 7 שמנוהל על ידי הלקוח ב-Google Distributed Cloud (GDC) עם מרווח אוויר. אם לקוחות יפרסו בקלאסטר רגיל של GDC בקרי בקוד פתוח פופולריים כמו HAProxy Kubernetes Ingress או NGINX Gateway Fabric, הם יוכלו לנתב תנועת משתמשים ברמה 7 לסביבות היברידיות בצורה חלקה. הארכיטקטורה הזו משתמשת ב-TLS Termination (Ingress / HTTPRoute) כדי לנתב תעבורה על סמך Server Name Indication (SNI) אל פודים מוכלים מובנים ואל אפליקציות שמתארחות במכונות וירטואליות חיצוניות.
תכונות ויכולות
- ניתוב מתקדם בשכבה 7: תמיכה בניתוח מבוסס-מארח, בניתוח מבוסס-נתיב ובניהול מתקדם של תעבורת נתונים, כמו התאמה מבוססת-כותרת ושקלול של תעבורת נתונים.
- ניהול TLS ריכוזי: ניהול וסיום TLS ריכוזיים.
- תמיכה בסביבה היברידית: ניתוב חלק של תעבורת L7 אל פודים מובנים של קונטיינרים ואל אפליקציות שמתארחות במכונות וירטואליות חיצוניות.
- אפשרויות גמישות של בקרים: אפשר לבחור בין NGINX Gateway Fabric מודרני (באמצעות Gateway API) לבין HAProxy Ingress Controller מבוסס.
- מוכנות לשימוש בסביבה מבודדת: משולב עם Harbor Registry לאחסון תמונות של פרוקסי ואפליקציות ולהצגתן בסביבות פרטיות ומנותקות.
- חלוקת תנועה מורכבת: מאפשרת אסטרטגיות מתקדמות לחלוקת תנועה לצורך אספקת אפליקציות מודרניות.
עקרונות אדריכליים
- תבנית איזון עומסים דו-שכבתית: בארכיטקטורה הזו משולב איזון עומסים מובנה בשכבה 4 של GDC (כנקודת הכניסה) עם שער בשכבה 7 שמנוהל על ידי הלקוח ונפרס ב-Kubernetes.
- הפרדה לפי תפקידים: העיצוב מפריד בין האחריות של ספקי התשתית, מפעילים של אשכולות ומפתחים באמצעות משאבים ספציפיים (כמו
GatewayClass,Gatewayו-HTTPRoute, אוIngress). - מעבר לתקנים מודרניים: הארכיטקטורה נותנת עדיפות ל-Gateway API ליכולות ניתוב מודרניות, תוך שמירה על תמיכה ב-Ingress API מדור קודם במקרים שבהם נדרשת יציבות עבור בקרי ספציפיים.
- גמישות בניהול על ידי הלקוח: פריסת בקרי ניהול עצמי מאפשרת ללקוחות לשלוט בתכונות ובהגדרות של L7 שלא מסופקות באופן מובנה על ידי מאזן העומסים המנוהל של GDC L4.
- אבסטרקציה של מיקום עומס העבודה: הארכיטקטורה מתייחסת לעומסי עבודה מבוססי קונטיינרים ומכונות וירטואליות באופן עקבי באמצעות אבסטרקציות של שירות Kubernetes (רגילות או headless).
ארכיטקטורה מושגית
ארכיטקטורה לוגית
הארכיטקטורה הלוגית מורכבת מכמה רכיבים פונקציונליים שפועלים יחד כדי לנתב תנועה חיצונית אל עורפי קצה פנימיים או חיצוניים:
- נקודת הכניסה של Ingress/Gateway: לקוח יוזם בקשות HTTPS שמגיעות קודם ל-Load Balancer ברמה 4 של GDC. מאזן העומסים המובנה הזה משמש כנקודת הכניסה ומפיץ את תעבורת ה-TCP/443 למאזן העומסים ברמה L7.
- מישור הבקרה: בקרי Ingress או Gateway (אופרטורים של HAProxy או NGINX) עוקבים אחרי משאבי Kubernetes כמו
Ingress,Gatewayו-HTTPRoute - מישור הנתונים: על סמך המשאבים שנצפו, הבקרים מעדכנים באופן דינמי את ה-Proxies הבסיסיים שמבצעים את הניתוב בפועל של התנועה על סמך כללי ניתוב של מארחים שמבוססים על SNI ועל סיום TLS.
- שירותים לקצה העורפי:
- Pods מבוססי-Container: מנוהלים כפריסות רגילות ונחשפים באמצעות שירותי Kubernetes רגילים.
- מכונות וירטואליות חיצוניות: משולבות באשכול עם שירות Kubernetes ללא ראש ונקודת קצה מותאמת אישית (או
EndpointSlice) שמכילה את כתובת ה-IP הישירה של המכונה הווירטואלית
- ניהול ארטיפקטים: כל התמונות של ה-proxies והאפליקציות מוגשות ממאגר מקומי של Harbor כדי להבטיח את הפונקציונליות בסביבה מבודדת
מושגים וטכנולוגיות מרכזיים
הארכיטקטורה משתמשת בתבנית איזון עומסים דו-שכבתית, שמשלבת את מאזן העומסים המובנה L4 של GDC עם שער L7 בניהול הלקוח שנפרס ב-Kubernetes. הרכיבים העיקריים כוללים את הדברים הבאים:
- לקוח: ישות שיוזמת בקשות HTTPS כדי ליצור אינטראקציה עם האפליקציות.
- אשכול GDC רגיל: GDC מספק דרך מובנית ליצירת אשכולות Kubernetes Vanilla. בפתרון הזה, האשכול יארח את איזון העומסים ברמה 7 ואת בקרי איזון העומסים, יחד עם עומסי העבודה והשירות ללא ראש עבור מכונות וירטואליות חיצוניות
- מאזן עומסים GDC L4: מאזן העומסים המובנה L4 משמש כנקודת הכניסה, ומפיץ את התנועה TCP/443 ישירות אל ה-Pods של Kubernetes שמריצים את בקרי ה-Ingress או ה-Gateway.
- בקרי תעבורת נתונים נכנסת (ingress) ושערים (gateway): אופרטורים של HAProxy או NGINX שפועלים באשכול רגיל. ב-Nginx, הם עוקבים אחרי משאבי Gateway API (כמו
Gatewayו-HTTPRoute) ומעדכנים באופן דינמי את השרתים הפרוקסי הבסיסיים. ב-HAProxy, הם עוקבים אחרי משאביIngressומעדכנים באופן דינמי את השרתים הפרוקסי הבסיסיים.- 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 (חיצוני): עומס עבודה שמארח מכונה וירטואלית חיצונית ברשת הפרויקט, שנחשף ל-proxy עם Kubernetes
Serviceללא ראש ונקודת קצה מותאמת אישית שמכילה את כתובת ה-IP הישירה של המכונה הווירטואלית. - Harbor Registry: מאגר פרטי של קונטיינרים שמשמש לאחסון ולשליפה של קובצי האימג' של ה-proxy והאפליקציה בסביבה מבודדת.
ההבדלים בין Ingress לבין Gateway APIs
תחום הרשתות של 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 במדריך הזה. הסיבה לכך היא שהשילוב של HAProxy עם Gateway API לא נחשב לבוגר. באמצעות HAProxy Ingress Controller המבוסס, אנחנו מבטיחים פתרון יציב ואמין ברמה 7 ללקוחות שמעדיפים HAProxy, ועדיין מספקים דרך להשתמש ביכולות מודרניות ברמה 7.
הנחות ומגבלות
הנחות
- מוכנות התשתית: הפריסה מניחה את הזמינות של GDC עם air gap 1.15.x Standard Clusters.
- מאגר מקומי: ההנחה היא שמאגר מקומי של Harbor מוגדר בצורה נכונה לאחסון ולהצגת תמונות של פרוקסי ואפליקציות בסביבה מבודדת.
- נקודת כניסה מקורית: התעבורה מגיעה קודם למאזן העומסים המובנה של GDC L4, שמעביר את התעבורה לשרתי ה-proxy של L7.
מגבלות
- פתרון בניהול הלקוח: אין שירות מנוהל ברמה 7 שמגובה בהסכם SLA ב-GDC. ההטמעה הזו מנוהלת באופן מלא על ידי הלקוח.
- רק אשכולות רגילים: אשכולות משתמשים משותפים לא נכללים בהיקף ההגדרה בגלל ההרשאות הגבוהות שנדרשות לפריסת בקר Ingress ובקר Gateway.
- מידת הבשלות של ה-API: בעוד ש-NGINX משתמש ב-Gateway API המודרני, HAProxy מוגבל ל-Ingress API כי השילוב שלו עם Gateway API עדיין לא נחשב לבשל.
- תחזוקה ב-Air-gapped: צריך לקדם ולנהל את כל תמונות הקונטיינר באופן ידני במאגר המקומי של Harbor.
- מהדורות קהילתיות: הארכיטקטורה מיועדת למהדורות קהילתיות של Nginx ו-HAProxy בקוד פתוח. יכול להיות שמהדורות Enterprise יפעלו, אבל לא בדקנו אותן באופן מפורש.
- בעלות תפעולית: הלקוחות צריכים לנהל בעצמם את ההתאמה של בקרים של צד שלישי, את הזמינות הגבוהה שלהם ואת התיקונים שלהם.
- גבולות התמיכה: התמיכה של Google מכסה רק את התשתית הבסיסית של GDC. בעיות בתוכנה HAProxy או NGINX הן באחריות הלקוח או הספק.
- הוצאה משימוש של API: קהילת Kubernetes הקפיאה את התכונות של Ingress API (שמשמש ל-HAProxy), מה שעשוי להגביל את יכולות הניתוב העתידיות.
רישוי
- מהדורות קהילתיות: הארכיטקטורה מיועדת למהדורות קהילתיות של קוד פתוח (בדרך כלל Apache 2.0 או דומה), שזמינות לשימוש בחינם אבל מנוהלות על ידי הלקוח.
- רכש Enterprise: רכש וניהול של רישיונות מסחריים, כמו NGINX Plus או HAProxy Enterprise, הם באחריות הלקוח בלבד.