Multi Cluster Ingress

‫Multi Cluster Ingress הוא בקר שמתארח בענן לאשכולות Google Kubernetes Engine‏ (GKE). זהו שירות שמתארח ב-Google ומאפשר פריסה של משאבי איזון עומסים משותפים בין אשכולות ובין אזורים. כדי לפרוס Multi Cluster Ingress בכמה אשכולות, צריך להשלים את השלבים במאמר הגדרת Multi Cluster Ingress ואז לעיין במאמר פריסת Ingress בכמה אשכולות.

השוואה מפורטת בין Multi Cluster Ingress ‏ (MCI),‏ Multi-cluster Gateway ‏(MCG) ומאזן עומסים עם Standalone Network Endpoint Groups ‏ (LB ו-Standalone NEGs) זמינה במאמר בחירת API לאיזון עומסים בין כמה אשכולות ב-GKE.

רישות מרובה אשכולות

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

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

התמיכה של Multi Cluster Ingress באשכולות מרובים מתאימה לתרחישי שימוש רבים, כולל:

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

מכסות שמוגדרות כברירת המחדל

ל-Multi Cluster Ingress יש את מכסות ברירת המחדל הבאות:

  • פרטים על מגבלות החברים בצי זמינים במאמר בנושא מכסות לניהול צי.
  • ‫100 MultiClusterIngress משאבים ו-100 MultiClusterService משאבים לכל פרויקט. אפשר ליצור עד 100 משאבי MultiClusterIngress ו-100 משאבי MultiClusterService באשכול תצורה לכל מספר של אשכולות עורפיים, עד למקסימום האשכולות לכל פרויקט.

תמחור ותקופות ניסיון

מידע על התמחור של Multi Cluster Ingress זמין במאמר תמחור של Multi Cluster Ingress.

איך פועל Multi Cluster Ingress

‫Multi Cluster Ingress מבוסס על הארכיטקטורה של מאזן העומסים הגלובלי החיצוני של אפליקציות. מאזן העומסים הגלובלי החיצוני של אפליקציות (ALB) הוא מאזן עומסים שמופץ גלובלית עם שרתי proxy שנפרסים ביותר מ-100 נקודות נוכחות (PoP) של Google ברחבי העולם. השרתים האלה, שנקראים ממשקי קצה של Google‏ (GFE), נמצאים בקצה הרשת של Google, במיקום קרוב ללקוחות. ‫Multi Cluster Ingress יוצר מאזני עומסים חיצוניים של אפליקציות במסלול פרימיום. מאזני העומסים האלה משתמשים בכתובות IP חיצוניות גלובליות שמתפרסמות באמצעות anycast. הבקשות מוגשות על ידי GFEs והאשכול הקרוב ביותר ללקוח. תעבורת נתונים באינטרנט מגיעה לנקודת ה-PoP הקרובה ביותר של Google ומשתמשת בשדרה המרכזית של Google כדי להגיע לאשכול GKE. הגדרת איזון העומסים הזו גורמת לזמן אחזור קצר יותר מהלקוח ל-GFE. כדי לצמצם את זמן האחזור בין אשכולות GKE לבין GFE, אפשר להריץ את אשכולות GKE באזורים שהכי קרובים ללקוחות.

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

‫Multi Cluster Ingress הוא בקר Ingress שמתכנת את מאזן העומסים החיצוני מסוג HTTP(S) באמצעות קבוצות של נקודות קצה ברשת (NEGs). כשיוצרים משאב MultiClusterIngress, ‏ GKE פורס משאבי איזון עומסים של Compute Engine ומגדיר את ה-Pods המתאימים באשכולות כשרתי קצה עורפיים. קבוצות ה-NEG משמשות למעקב דינמי אחרי נקודות קצה של Pod, כדי שלמאזן העומסים של Google יהיה את הסט הנכון של בק-אנדים תקינים.

זרימת התנועה ב-Multi Cluster Ingress

כשפורסים אפליקציות באשכולות ב-GKE,‏ Multi Cluster Ingress מוודא שמאזן העומסים מסונכרן עם אירועים שמתרחשים באשכול:

  • פריסת האפליקציה נוצרת עם התוויות התואמות הנכונות.
  • התהליך של Pod מסוים מסתיים ובדיקת התקינות שלו נכשלת.
  • אשכול מוסר ממאגר השרתים העורפיים.

Multi Cluster Ingress מעדכן את מאזן העומסים, כדי לשמור על עקביות עם הסביבה והמצב הרצוי של משאבי Kubernetes.

ארכיטקטורה של Multi Cluster Ingress

Multi Cluster Ingress משתמש בשרת Kubernetes API מרכזי כדי לפרוס Ingress בכמה אשכולות. שרת ה-API המרכזי הזה נקרא אשכול ההגדרות. כל אשכול GKE יכול לשמש כאשכול ההגדרות. באשכול התצורה נעשה שימוש בשני סוגים של משאבים בהתאמה אישית: MultiClusterIngress ו-MultiClusterService. כשפורסים את המשאבים האלה באשכול התצורה, בקר Multi Cluster Ingress פורס מאזני עומסים בכמה אשכולות.

המושגים והרכיבים הבאים מרכיבים את Multi Cluster Ingress:

  • בקר Multi Cluster Ingress – זהו מישור בקרה מבוזר גלובלית שפועל כשירות מחוץ לאשכולות. כך מחזור החיים והפעולות של בקר ה-GKE יכולים להיות בלתי תלויים באשכולות GKE.

  • אשכול הגדרות – זהו אשכול GKE שנבחר ופועל ב-Google Cloud , שבו נפרסים המשאבים MultiClusterIngress ו-MultiClusterService. זוהי נקודת בקרה מרכזית למשאבים מרובי-אשכולות. המשאבים האלה של כמה אשכולות קיימים ב-API לוגי אחד ונגישים ממנו, כדי לשמור על עקביות בכל האשכולות. בקר Ingress עוקב אחרי אשכול ההגדרות ומבצע התאמה בין תשתית איזון העומסים.

  • צי מאפשר לקבץ ולנרמל אשכולות GKE באופן לוגי, וכך להקל על ניהול התשתית ולאפשר שימוש בתכונות של ריבוי אשכולות, כמו Multi Cluster Ingress. מידע נוסף על היתרונות של צי מכשירים ועל אופן היצירה שלהם זמין בתיעוד לניהול צי מכשירים. אפשר להוסיף אשכול רק לצי אחד.

  • אשכול חבר – אשכולות שרשומים ב-Fleet נקראים אשכולות חברים. אשכולות החברים בצי מייצגים את כל היקף השרתים העורפיים ש-Multi Cluster Ingress מודעת אליהם. תצוגת הניהול של אשכולות Google Kubernetes Engine מספקת קונסולה מאובטחת שבה אפשר לראות את המצב של כל האשכולות הרשומים.

Multi Cluster Ingress arch

תהליך הפריסה

השלבים הבאים ממחישים תהליך עבודה ברמה גבוהה לשימוש ב-Multi Cluster Ingress בכמה אשכולות.

  1. רושמים אשכולות GKE ב-Fleet בפרויקט שבחרתם.

  2. הגדרת אשכול GKE כאשכול ההגדרות המרכזי. האשכול הזה יכול להיות מישור בקרה ייעודי, או שהוא יכול להריץ עומסי עבודה אחרים.

  3. פריסת אפליקציות באשכולות GKE שבהם הן צריכות לפעול.

  4. פורסים משאב אחד או יותר של MultiClusterService באשכול התצורה עם התאמות של תוויות ואשכולות כדי לבחור אשכולות, מרחב שמות ו-Pods שנחשבים לשרתי קצה עורפיים בשביל שירות נתון. הפעולה הזו יוצרת קבוצות של נקודות קצה לרשת (NEGs) ב-Compute Engine, שמתחילות לרשום ולנהל נקודות קצה של שירותים.

  5. פורסים משאב MultiClusterIngress באשכול ההגדרות שמפנה למשאב אחד או יותר של MultiClusterService כקצה עורפי למאזן העומסים. הפעולה הזו פורסת את המשאבים של מאזן העומסים החיצוני של Compute Engine וחושפת את נקודות הקצה באשכולות באמצעות כתובת IP וירטואלית אחת של מאזן עומסים.

מושגים שקשורים ל-Ingress

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

משאבי MultiClusterService

‫MultiClusterService הוא משאב בהתאמה אישית שמשמש את Multi Cluster Ingress כדי לייצג שיתוף שירותים בין אשכולות. משאב MultiClusterService בוחר Pods, בדומה למשאב Service, אבל משאב MultiClusterService יכול גם לבחור תוויות וקלאסטרים. מאגר האשכולות שמהם MultiClusterService בוחר נקרא אשכולות חברים. כל האשכולות שרשומים בצי הם אשכולות חברים.

‫MultiClusterService קיים רק באשכול ההגדרות, והוא לא מנתב שום דבר כמו שירות ClusterIP, ‏ LoadBalancer או NodePort. במקום זאת, הוא מאפשר לבקר Multi Cluster Ingress להפנות למשאב מבוזר יחיד.

המניפסט לדוגמה הבא מתאר MultiClusterService לאפליקציה בשם foo:

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: foo
  namespace: blue
spec:
  template:
    spec:
      selector:
        app: foo
      ports:
      - name: web
        protocol: TCP
        port: 80
        targetPort: 80

קובץ המניפסט הזה פורס שירות בכל אשכולות החברים עם הסלקטור app: foo. אם קיימים app: foo Pods באשכול הזה, כתובות ה-IP של ה-Pods האלה מתווספות כשרתי קצה עורפיים ל-MultiClusterIngress.

השירות mci-zone1-svc-j726y6p1lilewtu7 הבא הוא שירות נגזר שנוצר באחד מאשכולות היעד. השירות הזה יוצר NEG שעוקב אחרי נקודות קצה של Pod לכל ה-Pods שתואמים לבורר התוויות שצוין באשכול הזה. שירות ו-NEG נגזרים יופיעו בכל אשכול יעד לכל MultiClusterService (אלא אם משתמשים בבוררי אשכולות). אם אין Pods תואמים באשכול היעד, השירות וה-NEG יהיו ריקים. השירותים הנגזרים מנוהלים באופן מלא על ידי MultiClusterService ולא על ידי משתמשים באופן ישיר.

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports":{"8080":{}}}'
    cloud.google.com/neg-status: '{"network_endpoint_groups":{"8080":"k8s1-a6b112b6-default-mci-zone1-svc-j726y6p1lilewt-808-e86163b5"},"zones":["us-central1-a"]}'
    networking.gke.io/multiclusterservice-parent: '{"Namespace":"default","Name":"zone1"}'
  name: mci-zone1-svc-j726y6p1lilewtu7
  namespace: blue
spec:
  selector:
    app: foo
  ports:
  - name: web
    protocol: TCP
    port: 80
    targetPort: 80

כמה הערות לגבי השירות הנגזר:

  • הפונקציה שלו היא קיבוץ לוגי של נקודות קצה כשרתי קצה עורפיים עבור Multi Cluster Ingress.
  • הוא מנהל את מחזור החיים של ה-NEG עבור אשכול ואפליקציה נתונים.
  • הוא נוצר כשירות ללא ראש. שימו לב שרק השדות Selector ו-Ports מועברים מ-MultiClusterService לשירות הנגזר.
  • בקר Ingress מנהל את מחזור החיים שלו.

משאב MultiClusterIngress

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

במניפסט הבא מתואר MultiClusterIngress שמנתב תנועה לשרתי הקצה העורפיים foo ו-bar בהתאם לכותרות המארח של HTTP:

apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  name: foobar-ingress
  namespace: blue
spec:
  template:
    spec:
      backend:
        serviceName: default-backend
        servicePort: 80
      rules:
      - host: foo.example.com
        backend:
          serviceName: foo
          servicePort: 80
      - host: bar.example.com
        backend:
          serviceName: bar
          servicePort: 80

המשאב MultiClusterIngress מתאים לתנועה לכתובת ה-IP הווירטואלית ב-foo.example.com וב-bar.example.com על ידי שליחת התנועה הזו למשאבי MultiClusterService בשמות foo ו-bar. ל-MultiClusterIngress יש קצה עורפי שמוגדר כברירת מחדל, שתואם לכל שאר הטראפיק ושולח את הטראפיק הזה ל-MultiClusterService.

הדיאגרמה הבאה מציגה את אופן זרימת התעבורה מ-Ingress לאשכול:

בתרשים יש שני אשכולות, gke-us ו-gke-eu. התנועה זורמת מ-foo.example.com אל ה-Pods עם התווית app:foo בשני האשכולות. החל מ-bar.example.com, התנועה זורמת אל ה-Pods עם התווית app:bar בשני האשכולות.

משאבי Ingress באשכולות

אפשר להגדיר משאבי MultiClusterIngress ו-MultiClusterService רק באשכול התצורה. לכל אשכול יעד שיש בו Pods שתואמים לבוררי התוויות MultiClusterService מתוזמן גם שירות נגזר תואם. אם לא בוחרים במפורש באשכול באמצעות MultiClusterService, לא נוצר שירות נגזר תואם באשכול הזה.

דמיון במרחב השמות

מרחב שמות זהה הוא מאפיין של אשכולות Kubernetes שבו מרחב שמות מתרחב לאשכולות ונחשב לאותו מרחב שמות.

בתרשים הבא, מרחב השמות blue קיים באשכולות GKE‏ gke-cfg, gke-eu ו-gke-us. בבדיקה של מרחב שמות זהה, מרחב השמות blue נחשב זהה בכל האשכולות. כלומר, למשתמש יש את אותן הרשאות למשאבים במרחב השמות blue בכל אשכול. המשמעות של זהות במרחב השמות היא גם שמשאבי Service עם אותו שם בכמה אשכולות במרחב השמות blue נחשבים לאותו Service.

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

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

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

עיצוב אשכול ההגדרות

אשכול התצורה של Multi Cluster Ingress הוא אשכול GKE יחיד שמארח את המשאבים MultiClusterIngress ו-MultiClusterService ומשמש כנקודת בקרה יחידה לתעבורת נתונים נכנסת (ingress) בכל צי אשכולות GKE היעד. כשמפעילים Multi Cluster Ingress, בוחרים את אשכול ההגדרות. אתם יכולים לבחור כל אשכול GKE כאשכול ההגדרות ולשנות את אשכול ההגדרות בכל שלב.

הזמינות של אשכולות להגדרות

מכיוון שקלאסטר ההגדרות הוא נקודת בקרה יחידה, אי אפשר ליצור או לעדכן משאבי Multi Cluster Ingress אם ה-API של קלאסטר ההגדרות לא זמין. מאזני עומסים ותנועה שמטופלת על ידם לא יושפעו מהפסקה זמנית בשירות של אשכול תצורה, אבל שינויים במשאבי MultiClusterIngress ו-MultiClusterService לא יסונכרנו על ידי בקר עד שהוא יהיה זמין שוב.

כדאי להשתמש בעקרונות התכנון הבאים עבור אשכולות של הגדרות:

  • צריך לבחור את אשכול ההגדרות כך שתהיה זמינות גבוהה. עדיף להשתמש באשכולות אזוריים ולא באשכולות אזוריים.
  • כדי להפעיל את Multi Cluster Ingress, אשכול ההגדרות לא צריך להיות אשכול ייעודי. יכול להיות שבאשכול ההגדרות יתארחו עומסי עבודה של אפליקציות או עומסי עבודה אדמיניסטרטיביים, אבל חשוב לוודא שהאפליקציות שמתארחות לא ישפיעו על הזמינות של שרת ה-API של אשכול ההגדרות. אפשר להגדיר את אשכול ההגדרות כאשכול יעד שמארח בק-אנדים של משאבי MultiClusterService, אבל אם נדרשים אמצעי זהירות נוספים, אפשר גם להחריג את אשכול ההגדרות כבק-אנד באמצעות בחירת אשכול.
  • במערכי ההגדרות צריכים להיות כל מרחבי השמות שמשמשים את קצה העורף של אשכול היעד. משאב MultiClusterService יכול להפנות רק אל Pods באותו מרחב שמות בין אשכולות, ולכן מרחב השמות הזה צריך להיות קיים באשכול התצורה.
  • משתמשים שפורסים Ingress בכמה אשכולות צריכים לקבל גישה לאשכול ההגדרות כדי לפרוס משאבי MultiClusterIngress ו-MultiClusterService. עם זאת, למשתמשים צריכה להיות גישה רק למרחבי שמות שיש להם הרשאה להשתמש בהם.

בחירה והעברה של אשכול ההגדרות

כשמפעילים Multi Cluster Ingress, צריך לבחור את אשכול ההגדרות. אפשר לבחור כל אשכול של חברים בצי כקלאסטר התצורה. אפשר לעדכן את אשכול ההגדרות בכל שלב, אבל חשוב לוודא שהעדכון לא יגרום לשיבוש. בקר ה-Ingress יבצע התאמה בין המשאבים שקיימים באשכול ההגדרות. כשמעבירים את אשכול התצורה מהנוכחי לזה שאחריו, המשאבים MultiClusterIngress ו-MultiClusterService חייבים להיות זהים. אם המשאבים לא זהים, יכול להיות שמאזני העומסים של Compute Engine יעודכנו או יושמדו אחרי עדכון אשכול התצורה.

בתרשים הבא מוצג אופן השימוש במשאבי MultiClusterIngress ו-MultiClusterService על ידי מערכת CI/CD מרכזית בשרת GKE API עבור אשכול התצורה (gke-us) ואשכול גיבוי (gke-eu) בכל רגע נתון, כך שהמשאבים זהים בשני האשכולות. אפשר לשנות את אשכול התצורה למקרה חירום או להשבתה מתוכננת בכל שלב בלי להשפיע על המערכת, כי המשאבים MultiClusterIngressוMultiClusterService זהים.

בחירת אשכול

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

כדאי להגדיר רשימה של אשכולות אם אתם צריכים:

  • בודדו את אשכול ההגדרות כדי למנוע בחירה של משאבי MultiClusterService באשכול ההגדרות.
  • שליטה בתעבורה בין אשכולות לצורך העברת אפליקציות.
  • ניתוב לשרתי בק-אנד של אפליקציות שקיימים רק בקבוצת משנה של אשכולות.
  • שימוש בכתובת IP וירטואלית אחת של HTTP(S) לניתוב לשרתי קצה עורפיים שנמצאים באשכולות שונים.

כדי למנוע התנגשויות בשמות, צריך לוודא שלאשכולות חברים באותו צי ובאותו אזור יש שמות ייחודיים.

כדי ללמוד איך להגדיר בחירת אשכול, אפשר לעיין במאמר בנושא הגדרת Multi Cluster Ingress.

קובץ המניפסט הבא מתאר MultiClusterService עם שדה clusters שמפנה אל europe-west1-c/gke-eu ואל asia-northeast1-a/gke-asia:

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: foo
  namespace: blue
spec:
  template:
    spec:
      selector:
        app: foo
      ports:
      - name: web
        protocol: TCP
        port: 80
        targetPort: 80
  clusters:
  - link: "europe-west1-c/gke-eu"
  - link: "asia-northeast1-a/gke-asia-1"

קובץ המניפסט הזה מציין שאפשר לכלול Pods עם התוויות התואמות באשכולות gke-asia ו-gke-eu כשרתי קצה עורפיים עבור MultiClusterIngress. כל אשכול אחר לא ייכלל, גם אם יש בו יחידות Pod עם התווית app: foo.

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

בתרשים יש שלושה אשכולות: gke-eu, gke-asia-1 ו-gke-asia-2. אוסף gke-asia-2 לא נכלל כקצה עורפי, למרות שיש Pods עם תוויות תואמות, כי האוסף לא נכלל ברשימת spec.clusters של המניפסט. האשכול לא מקבל תנועה לצורך תחזוקה או פעולות אחרות.

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