Multi Cluster Ingress

Autopilot Standard

‫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 מבוססת על הארכיטקטורה של Global External Application Load Balancer. מאזן העומסים הגלובלי החיצוני של אפליקציות (ALB) הוא מאזן עומסים שמופץ גלובלית עם שרתי proxy שמוצבים ביותר מ-100 נקודות נוכחות (PoP) של Google ברחבי העולם. הפרוקסי האלה, שנקראים ממשקי קצה של Google‏ (GFE), נמצאים בקצה הרשת של Google, במיקום קרוב ללקוחות. ‫Multi Cluster Ingress יוצר מאזני עומסים חיצוניים של אפליקציות (ALB) במסלול פרימיום. מאזני העומסים האלה משתמשים בכתובות IP חיצוניות גלובליות שמתפרסמות באמצעות anycast. הבקשות מוגשות על ידי GFEs והאשכול שהכי קרוב ללקוח. תעבורת הנתונים עוברת ל-PoP הכי קרוב של Google, ומשתמשת בשדרה המרכזית של Google כדי להגיע לאשכול GKE. הגדרת איזון העומסים הזו מובילה לזמן אחזור נמוך יותר מהלקוח ל-GFE. אפשר גם להקטין את זמן האחזור בין ההצגה של אשכולות GKE לבין GFE על ידי הפעלת אשכולות GKE באזורים שהכי קרובים ללקוחות.

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

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

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

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

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

ארכיטקטורת Multi Cluster Ingress

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

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

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

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

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

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

תהליך העבודה של הפריסה

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

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

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

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

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

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

מושגים שקשורים לתעבורת נתונים נכנסת (ingress)

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

משאבי MultiClusterService

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

‫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 לכל הפודים שתואמים לבורר התוויות שצוין באשכול הזה. שירות ו-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

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

• התפקיד שלו הוא קיבוץ לוגי של נקודות קצה (endpoints) כ-backend ל-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 אל הפודים עם התווית app:foo בשני האשכולות. מ-bar.example.com, התנועה זורמת ל-Pods עם התווית app:bar בשני האשכולות.

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

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

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

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

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

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

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

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

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

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

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

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

אלה עקרונות התכנון של אשכולות הגדרות:

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

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

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

בתרשים הבא מוצג איך מערכת CI/CD מרכזית מחילה משאבי MultiClusterIngress ו-MultiClusterService על שרת ה-API של GKE עבור אשכול התצורה (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. כל אשכול אחר לא ייכלל, גם אם יש בו Pods עם התווית app: foo.

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

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

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

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