במאמר הזה מוסבר איך לתכנן, לעצב ולהטמיע שדרוגים בסביבה של Google Kubernetes Engine (GKE) עם כמה אשכולות. במסמך הזה נעשה שימוש ב-Multi Cluster Ingress לשדרוגים, אבל אפשר להחיל את המושגים גם על פתרונות אחרים. המסמך הזה מיועד Google Cloud לאדמינים שאחראים על תחזוקת צי של אשכולות GKE.
ניהול מחזור החיים של אשכולות GKE
ניהול מחזור החיים של אשכולות הוא האסטרטגיות והתכנון שנדרשים כדי לשמור על תקינות ועדכניות של צי אשכולות Kubernetes, בלי להפר את יעדי ה-SLO של השירות. אם יש לכם אסטרטגיות ותוכניות מתאימות, ניהול מחזור החיים של האשכול צריך להיות שגרתי, צפוי ונטול אירועים מיוחדים.
מידע נוסף על ניהול גרסת GKE של אשכול זמין במאמר מידע על שדרוגים של אשכולות GKE. מידע נוסף על ניהול כל סוגי השינויים במהלך מחזור החיים של אשכול זמין במאמר ניהול שינויים במחזור החיים של אשכולות כדי לצמצם את ההפרעות.
ניהול מחזור החיים של כמה אשכולות ב-GKE
בקטע הזה מתוארות אסטרטגיות שונות לניהול מחזור החיים של כמה אשכולות GKE, ומוסבר איך לתכנן אותן.
שיקולים בתכנון ובעיצוב
ארכיטקטורת ריבוי האשכולות של GKE משפיעה על הבחירה של אסטרטגיית ניהול מחזור החיים של האשכול. לפני שנדון באסטרטגיות האלה, חשוב לדון בהחלטות עיצוביות מסוימות שעשויות להשפיע על האסטרטגיה לניהול מחזור החיים של האשכול, או להיות מושפעות ממנה.
סוג האשכולות
אם אתם משתמשים בשדרוג האוטומטי של GKE כאסטרטגיה לניהול מחזור החיים של האשכול, סוג האשכול יכול להיות חשוב. לדוגמה, באשכולות אזוריים יש כמה צמתים של רמת הבקרה, והשדרוג של הצמתים האלה מתבצע אוטומטית בכל פעם בצומת אחד. לעומת זאת, באשכולות אזוריים יש רק צומת אחד של רמת הבקרה. אם אתם לא משתמשים בשדרוג אוטומטי של GKE ואם אתם רואים בכל אשכול Kubernetes תשתית שאפשר להשליך, יכול להיות שלא משנה איזה סוג אשכול תבחרו כשאתם מחליטים על אסטרטגיית ניהול מחזור החיים של האשכול. אפשר להחיל את האסטרטגיות שמוסברות בקטע הבא, ניהול מחזור החיים של כמה אשכולות GKE על כל סוג של אשכול.
מיקום וגודל של אשכולות
כשמחליטים על מיקום האשכול ועל טביעת הרגל שלו, כדאי להביא בחשבון את הגורמים הבאים:
- אזורים ואזורים שבהם נדרש להציב אשכולות.
- מספר האשכולות וגודלם.
בדרך כלל קל לטפל בגורם הראשון כי האזורים והאזורים הגיאוגרפיים נקבעים על ידי העסק והאזורים שבהם אתם מספקים שירות למשתמשים.
ההחלטה על מספר האשכולות והגודל שלהם מתחלקת בדרך כלל לקטגוריות הבאות, שלכל אחת מהן יש יתרונות וחסרונות:
- מספר קטן של אשכולות גדולים. אתם יכולים להשתמש ביתירות ובגמישות שמספקים אשכולות אזוריים, ולהציב אשכול אזורי גדול אחד (או שניים) בכל אזור. היתרון של הגישה הזו הוא תקורה תפעולית נמוכה של ניהול כמה אשכולות. החיסרון הוא שהיא עלולה להשפיע על מספר גדול של שירותים בבת אחת, בגלל אזור ההשפעה הגדול שלה.
- מספר גדול של אשכולות קטנים. אתם יכולים ליצור מספר גדול של אשכולות קטנים כדי לצמצם את אזור ההשפעה של האשכול, כי השירותים שלכם מפולגים בין הרבה אשכולות. הגישה הזו מתאימה גם לאשכולות זמניים לטווח קצר (לדוגמה, אשכולות שמריצים עומס עבודה של אצווה). החיסרון בגישה הזו הוא תקורה תפעולית גבוהה יותר, כי יש יותר אשכולות לשדרוג. יכולות להיות גם עלויות נוספות שקשורות למספר גבוה יותר של צומתי מישור בקרה. אפשר לקזז את העלויות ואת התקורה התפעולית הגבוהה באמצעות אוטומציה, תזמון ואסטרטגיה צפויים ותיאום קפדני בין הצוותים והשירותים המושפעים.
במסמך הזה לא מומלצת גישה אחת על פני השנייה, אלא מוצגות אפשרויות. במקרים מסוימים, אפשר לבחור את שני דפוסי העיצוב לקטגוריות שונות של שירותים.
השיטות הבאות מתאימות לשתי אפשרויות העיצוב.
תכנון קיבולת
כשמתכננים את הקיבולת, חשוב לקחת בחשבון את אסטרטגיית מחזור החיים של האשכול שנבחר. בתכנון הקיבולת צריך להתייחס לעומס הרגיל של השירות ולאירועי התחזוקה הבאים:
- אירועים מתוכננים כמו שדרוגי אשכולות
- אירועים לא מתוכננים כמו הפסקות חשמל באשכולות, לדוגמה, דחיפות של הגדרות שגויות ופריסות שגויות
כשמתכננים את הקיבולת, צריך לקחת בחשבון הפסקות שירות מלאות או חלקיות. אם אתם מתכננים רק אירועי תחזוקה מתוכננים, לכל השירותים המבוזרים צריך להיות אשכול אחד נוסף על מה שנדרש, כדי שתוכלו להוציא אשכול אחד מהרוטציה בכל פעם לצורך שדרוגים בלי לפגוע בשירות. הגישה הזו נקראת גם N+1 תכנון קיבולת. אם אתם מתכננים אירועי תחזוקה מתוכננים ולא מתוכננים, לכל השירותים המבוזרים צריכים להיות שני אשכולות נוספים (או יותר) מעבר לנדרש כדי לספק את הקיבולת המיועדת – אחד לאירוע מתוכנן ואחד לאירוע לא מתוכנן, למקרה שהוא יתרחש במהלך חלון זמן לתחזוקה המתוכנן. הגישה הזו נקראת גם תכנון קיבולת N+2.
בארכיטקטורות עם כמה אשכולות, משתמשים לעיתים קרובות במונחים ניקוז וזליגה. המונחים האלה מתייחסים לתהליך של הסרת (או ניקוז) תנועה מאשכול והפניית (או זליגת) תנועה לאשכולות אחרים במהלך שדרוגים ואירועי תחזוקה. התהליך הזה מתבצע באמצעות פתרונות רשת כמו Ingress מרובה אשכולות או שיטות אחרות לאיזון עומסים. שימוש זהיר בריקון ובגלישה הוא הבסיס לכמה אסטרטגיות לניהול מחזור החיים של אשכולות. כשמתכננים קיבולת, צריך להביא בחשבון את הניקוז וההעברה. לדוגמה, כשמרוקנים אשכול אחד, צריך לבדוק אם לאשכולות האחרים יש מספיק קיבולת כדי לטפל בתנועה הנוספת שמועברת אליהם. שיקולים נוספים כוללים קיבולת מספקת באזור או בתחום, או צורך לשלוח תעבורה לאזור אחר (אם משתמשים באשכול אזורי יחיד לכל אזור). בתרשים הבא מוצגת תנועה שמוסרת (לפעמים נקראת ניקוז של אשכול) מאשכול אחד ונשלחת לאשכול אחר שמריץ את אותו שירות מבוזר.
אשכולות ושירותים מבוזרים
לפי תכנון אשכולות שמבוסס על שירותים, ארכיטקטורת האשכולות (מספר, גודל ומיקום) נקבעת לפי השירותים שנדרשים לפעול באשכולות. לכן, המיקום של האשכולות נקבע לפי המקום שבו נדרשים השירותים המבוזרים. כשמחליטים איפה למקם שירותים מבוזרים, כדאי להביא בחשבון את הנקודות הבאות:
- דרישה לגבי מיקום. באילו אזורים צריך להפעיל את השירות?
- חשיבות. עד כמה זמינות השירות חשובה לעסק?
- SLO. מהם היעדים למדידת רמת השירות (SLO) של השירות (בדרך כלל על סמך רמת הקריטיות)?
- יכולת התמודדות. עד כמה השירות צריך להיות עמיד? האם הוא צריך לעמוד בפני כשלים ברמת האשכול, האזור או אפילו האזור כולו?
כשמתכננים שדרוגים של אשכולות, צריך להביא בחשבון את מספר השירותים שאשכול אחד משפיע עליהם כשהוא מרוקן, וגם את ההעברה של כל אחד מהשירותים האלה לאשכולות מתאימים אחרים. אשכולות יכולים להיות עם דייר יחיד או עם כמה דיירים. קלאסטרים עם דייר יחיד משרתים רק שירות אחד או מוצר שמיוצג על ידי קבוצה של שירותים. במערכות של לקוח יחיד, האשכול לא משותף עם שירותים או מוצרים אחרים. בקלסטרים עם מספר דיירים אפשר להריץ הרבה שירותים ומוצרים שמחולקים בדרך כלל למרחבי שמות.
ההשפעה על הצוותים
אירוע באשכול משפיע לא רק על השירותים אלא גם על הצוותים. לדוגמה, יכול להיות שצוות ה-DevOps יצטרך להפנות מחדש או לעצור את צינורות עיבוד הנתונים של ה-CI/CD במהלך שדרוג האשכול. באופן דומה, צוותי תמיכה יכולים לקבל התראות על הפסקות שירות מתוכננות. צריך להטמיע אוטומציה וכלים כדי להקל על ההשפעה על כמה צוותים. שדרוג של אשכול או של צי אשכולות צריך להיחשב כפעולה שגרתית וחסרת אירועים מיוחדים, כשכל הצוותים מעודכנים.
תזמון, תזמון וסנכרון
ב-Kubernetes יוצאת גרסה משנית חדשה מדי רבעון, והתמיכה ניתנת ל-3 הגרסאות האחרונות. חשוב לתכנן בקפידה את התזמון של שדרוגי האשכולות. בעלי השירות, מפעילי השירות ומנהלי הפלטפורמה צריכים להסכים על מועד השדרוגים. כשמתכננים שדרוגים, כדאי להביא בחשבון את השאלות הבאות:
- באיזו תדירות משדרגים? האם אתם משדרגים כל רבעון או לפי לוח זמנים אחר?
- מתי כדאי לשדרג? האם אתם משדרגים בתחילת הרבעון כשהעסק מאט או בזמנים אחרים שבהם העסק מושבת בגלל התחום שבו אתם פועלים?
- מתי לא כדאי לשדרג? האם יש לכם תכנון ברור מתי לא לשדרג? לדוגמה, הימנעות מאירועי שיא כמו בלאק פריידיי, סייבר מאנדיי, או במהלך כנסים חשובים ואירועים אחרים שספציפיים לתחום.
חשוב שתהיה אסטרטגיה ברורה שתועבר לבעלי השירות, וגם לצוותי התפעול והתמיכה. לא אמורות להיות הפתעות, וכולם צריכים לדעת מתי ואיך משדרגים את האשכולות. כדי לעשות את זה, צריך לתאם את הפעולות עם כל הצוותים המעורבים. לשירות אחד יש כמה צוותים שמתקשרים איתו. בדרך כלל, אפשר לקבץ את הצוותים האלה לקטגוריות הבאות:
- מפתח השירות, שאחראי ליצירת הלוגיקה העסקית ולתכנות שלה בשירות.
- מפעיל השירות, שאחראי להפעלה בטוחה ואמינה של השירות. המפעילים יכולים להיות מורכבים מכמה צוותים, כמו אדמין מדיניות או אבטחה, מנהל רשת וצוותי תמיכה.
כל המשתתפים צריכים להיות בקשר במהלך שדרוגי האשכול, כדי שיוכלו לבצע את הפעולות הנדרשות בזמן הזה. גישה אחת היא לתכנן שדרוגים באותו אופן שבו מתכננים אירוע של הפסקה זמנית בפעילות. יש לכם מנהל אירוע, חדר צ'אט וסיכום (גם אם אף משתמש לא הושפע). מידע נוסף זמין במאמר בנושא תגובה לאירועים.
אסטרטגיות למחזור החיים של אשכולות GKE
בקטע הזה נסביר על האסטרטגיות העיקריות לניהול מחזור החיים של אשכולות, שמשמשות לעיתים קרובות בארכיטקטורה של כמה אשכולות ב-GKE. חשוב לציין שאסטרטגיה אחת לא תתאים לכל התרחישים, ויכול להיות שתבחרו כמה אסטרטגיות לקטגוריות שונות של שירותים וצרכים של העסק.
שדרוגים הדרגתיים
בתרשים הבא מוצגת אסטרטגיית השדרוג המתגלגל.
באמצעות מאזן עומסים, כל התנועה מנוקזת מאשכול GKE אחד והוא משודרג. עומס התנועה שנוצר מועבר לאשכול GKE אחר.
שדרוגים מתגלגלים הם האסטרטגיה הפשוטה והחסכונית ביותר מבין האסטרטגיות שמוסברות במסמך הזה. אתם מתחילים עם n מספר האשכולות
שמופעלת בהם הגרסה old_ver (או גרסת הייצור הנוכחית). לאחר מכן מרוקנים m אשכולות בכל פעם, כאשר m קטן מ-n. אחר כך מוחקים את האשכולות שהסוללה שלהם התרוקנה ויוצרים אשכולות חדשים עם הגרסה החדשה, או משדרגים את האשכולות שהסוללה שלהם התרוקנה.
ההחלטה אם למחוק אשכולות חדשים או לשדרג אותם תלויה בגודל האשכולות וגם אם אתם חושבים שהאשכולות הם תשתית בלתי משתנה. תשתית קבועה מכתיבה שבמקום לשדרג כל הזמן את האשכול, מה שעלול להוביל לתוצאות לא רצויות לאורך זמן, צריך ליצור אשכולות חדשים ולהימנע משינויים בלתי צפויים בהגדרות האישיות.
אם אתם משתמשים ב-GKE, אתם יכולים ליצור אשכול GKE באמצעות פקודה אחת או קריאה ל-API. כדי להשתמש באסטרטגיית האשכולות החדשה, צריך לאחסן את כל הגדרות האשכול (מניפסטים של אשכולות) מחוץ לאשכול, בדרך כלל ב-Git. אחר כך תוכלו להשתמש באותה תבנית הגדרה באשכול החדש. אם זה אשכול חדש, ודאו שצינורות עיבוד הנתונים של ה-CI/CD מפנים לאשכול הנכון. אחרי שהאשכול מוגדר כמו שצריך, אפשר להחזיר את תנועת הגולשים לאשכול בהדרגה, תוך מעקב אחרי יעדי רמת השירות (SLO) של השירותים.
התהליך חוזר על עצמו לכל האשכולות. בהתאם לתכנון הקיבולת, אתם יכולים לשדרג כמה אשכולות בו-זמנית בלי להפר את יעדי ה-SLO של השירות.
אם אתם מעדיפים פשטות ועלות על פני עמידות, השתמשו באסטרטגיית השדרוגים המתגלגלים. במהלך האסטרטגיה הזו, אף פעם לא חורגים מהקיבולת הנדרשת של GKE fleet לכל השירותים המבוזרים.
בתרשים הבא מוצגת השוואה בין ציר הזמן לבין דרישת קיבולת השירות במהלך שדרוג של אשכול GKE בארכיטקטורה של כמה אשכולות.
בתרשים שלמעלה אפשר לראות שבמהלך תהליך השדרוג של GKE, הקיבולת לתמיכה בשירותים אף פעם לא יורדת מתחת לנדרש. כשאשכול GKE שצריך לשדרג מוצא מהסבב, האשכולות האחרים מורחבים כדי לתמוך בעומס.
שדרוגים כחול/ירוק
התרשים הבא מציג אסטרטגיית שדרוג כחול/ירוק.
בתרשים שלמעלה, נוסף אשכול GKE חדש שבו פועלת הגרסה החדשה. לאחר מכן, מאזן עומסים משמש לשליחת תעבורת נתונים לאשכול החדש, תוך ניקוז איטי של אחד מהאשכולות הישנים עד שלא נשלחת אליו תעבורת נתונים. אחרי שהמקבץ הישן יתרוקן לגמרי, אפשר יהיה להסיר אותו. אפשר לחזור על אותו התהליך עבור שאר האשכולות.
אסטרטגיית השדרוג הכחולה/ירוקה מספקת עמידות נוספת.
האסטרטגיה הזו דומה לשדרוגים הדרגתיים, אבל היא יקרה יותר. ההבדל היחיד הוא שבמקום לרוקן את האשכולות הקיימים קודם, יוצרים אשכולות חדשים של m עם הגרסה קודם, כאשר m קטן או שווה ל-n. מוסיפים את האשכולות החדשים לצינורות ה-CI/CD, ואז מעבירים את התנועה בהדרגה תוך מעקב אחרי יעדי ה-SLO של השירות. כשהאשכולות החדשים מקבלים את כל התנועה, מרוקנים ומוחקים את האשכולות עם הגרסה הישנה.
האסטרטגיה הכחולה/ירוקה לשדרוג אשכולות דומה לאסטרטגיה כחולה/ירוקה שמשמשת בדרך כלל לשירותים. יצירת כמה אשכולות חדשים בו-זמנית מגדילה את העלות הכוללת, אבל מאפשרת לכם לזרז את זמן השדרוג של ה-fleet. העלות הנוספת היא רק למשך השדרוג, אם נעשה שימוש באשכולות נוספים. היתרון ביצירת אשכולות חדשים קודם הוא שאם משהו משתבש, אפשר לבטל את השינוי. אפשר גם לבדוק את האשכול החדש לפני ששולחים אליו תנועה של נתוני ייצור. מכיוון שהאשכולות האלה קיימים במקביל לאשכולות בגרסה הישנה שלהם לפרק זמן קצר, העלויות הנוספות הן מינימליות.
אם אתם מעדיפים פשטות וגמישות על פני עלות, השתמשו באסטרטגיית השדרוג כחול/ירוק. אשכולות נוספים מתווספים קודם, והם חורגים מהקיבולת הנדרשת של צי GKE למשך השדרוגים.
בתרשים שלמעלה, הוספת אשכול חדש מגדילה באופן זמני את הקיבולת הזמינה מעבר לקיבולת הנדרשת, בזמן שאשכול אחר בצי מרוקן ומוסר מהצי. אבל אחרי שמסירים אחד מהאשכולות הישנים (שנפח האחסון שלהם מוצה), הקיבולת חוזרת למה שנדרש. השינוי הזה בקיבולת מודגש כי יכול להיות שהעלות תגדל עם המודל הזה, בהתאם למספר ולאורך של האשכולות בצי.
שדרוגים של אשכולות Canary
שדרוג אשכולות קנרי הוא האסטרטגיה המורכבת והעמידה ביותר מבין אלה שנדונו במסמך הזה. באסטרטגיה הזו, ניהול מחזור החיים של האשכולות מופשט לחלוטין מניהול מחזור החיים של השירותים, וכך הסיכון לשירותים הוא הנמוך ביותר והעמידות שלהם היא הגבוהה ביותר. באסטרטגיות הקודמות של שדרוג מתגלגל ושדרוג כחול/ירוק, כל צי GKE נשאר באותה גרסה. באסטרטגיה הזו, אתם מנהלים שניים או אולי שלושה ציים של אשכולות GKE שמריצים גרסאות שונות. במקום לשדרג את האשכולות, מעבירים את השירותים מ-fleet אחד של אשכולות ל-fleet השני לאורך זמן. כשמרוקנים את המכשירים בארגון ב-GKE מהגרסה הכי ישנה (כלומר, כל השירותים הועברו לגרסה הבאה של המכשירים בארגון ב-GKE), מוחקים את המכשירים בארגון.
כדי להשתמש באסטרטגיה הזו, צריך להחזיק לפחות שני ציי GKE – אחד לגרסת הייצור הנוכחית ואחד לגרסה הבאה שמועמדת לייצור. אפשר גם לנהל יותר משני ציי GKE. ציים נוספים נותנים לכם יותר גמישות, אבל גם העלויות והתקורה התפעולית עולות. הצי הנוסף הזה לא זהה לשימוש באשכולות בסביבות שונות, למשל סביבות פיתוח, Staging וייצור. סביבות שהן לא סביבות ייצור מתאימות לבדיקת התכונות והשירותים של Kubernetes עם תנועה שהיא לא תנועת ייצור.
השיטה הזו של שדרוג אשכולות קנרי מחייבת שמירה של כמה גרסאות של GKE fleet בסביבת הייצור. זה דומה לאסטרטגיות של גרסה איטרטיבית לקהל מצומצם (canary release), שמשמשות לעיתים קרובות שירותים. בעזרת פריסות של שירותים בשיטת Canary, בעלי השירות יכולים תמיד לזהות בעיות בגרסה מסוימת של השירות. באשכולות קנרית, בעלי השירות צריכים גם להביא בחשבון את גרסאות ה-fleet של GKE שבהן השירותים שלהם פועלים. גרסה אחת של שירות מבוזר יכולה לפעול בכמה גרסאות של צי GKE. ההעברה של שירות יכולה להתבצע בהדרגה, כדי שתוכלו לראות את ההשפעות של השירות על צי המכונות החדש לפני שתשלחו את כל התנועה של השירות לאשכולות החדשים עם הגרסה.
הדיאגרמה הבאה מראה שניהול של Fleetים שונים של אשכולות GKE יכול להפריד לחלוטין בין מחזור החיים של האשכולות לבין מחזור החיים של השירותים.
בתרשים הקודם מוצג שירות מבוזר frontend שמועבר בהדרגה מצי של אשכולות GKE אחד לצי הבא שמריץ את הגרסה החדשה, עד שהצי הישן מתרוקן לחלוטין לאורך זמן. אחרי שכל המכונות בצי יתרוקנו, אפשר להסיר אותו וליצור צי חדש. כל השירותים מועברים לצי הבא, והציים הישנים מוסרים כשהם מתרוקנים.
אם החוסן חשוב לכם יותר מכל דבר אחר, כדאי להשתמש באסטרטגיית השדרוג של אשכול קנרי.
בחירת אסטרטגיית שדרוג
התרשים הבא יכול לעזור לכם לקבוע איזו אסטרטגיה הכי מתאימה לכם על סמך השירות והצרכים העסקיים.
התרשים שלמעלה הוא עץ החלטות שיעזור לכם לבחור את אסטרטגיית השדרוג שמתאימה לכם:
- אם אתם לא צריכים שליטה מלאה על הגרסה המדויקת ועל מועד השדרוג, אתם יכולים לבחור בתכונת השדרוג האוטומטי שזמינה ב-GKE.
- אם העדיפות שלכם היא עלות נמוכה, אתם יכולים לבחור באסטרטגיית השדרוג המתגלגל.
- אם העדיפות שלכם היא איזון בין עלות לבין עמידות, אתם יכולים לבחור באסטרטגיית blue/green.
- אם העמידות חשובה לכם יותר מהעלות, אתם יכולים לבחור באסטרטגיית השדרוג של אשכולות Canary.
ניהול תנועה באשכולות מרובים למחזור החיים של אשכולות GKE
כדי לשמור על זמינות השירות במהלך שדרוגים של כמה אשכולות, צריך לרוקן את התנועה בין האשכולות ולנתב אותה מחדש. אפשר לנהל את התנועה הזו באמצעות Multi Cluster Gateway (מומלץ) או Multi Cluster Ingress. Multi-cluster Gateway הוא היורש של Multi Cluster Ingress, והוא מספק גישה יותר אקספרסיבית ומכוונת-תפקיד לרשתות שירות.
שימוש בשער מרובה אשכולות לניהול מחזור החיים של האשכול
Multi-cluster Gateway (MCG) משתמש ב-Gateway API כדי לנהל את התנועה לשירותים שנפרסו בכמה אשכולות GKE בתוך צי.
בקר GKE Gateway הוא שירות שמתארח ב-Google ועוקב אחרי משאבי Gateway ו-HTTPRoute באשכול הגדרות ייעודי. הבקר מקצה ומנהל באופן אוטומטי את תשתית איזון העומסים, ומספק נקודת כניסה מאוחדת אחת לאפליקציות בכל האשכולות בצי. הארכיטקטורה הזו מאפשרת לכם להפריד את מחזור החיים של מאזן העומסים מאשכולות GKE נפרדים שבהם נמצאים עומסי העבודה.
בניהול מחזור החיים של אשכולות GKE, שערים לכמה אשכולות מאפשרים אסטרטגיות מתקדמות של בקרת תנועה:
- שדרוגים מסוג blue-green: פריסת אשכול חדש מסוג green והעברת התנועה בהדרגה מהאשכול מסוג blue על ידי שינוי המשקלים במשאב HTTPRoute.
- איזון עומסים לפי קיבולת: הפניה אוטומטית של תנועה כששירות באשכול אחד מגיע למגבלת הקיבולת המוגדרת שלו, כדי להגן עליו מפני עומס יתר במהלך שדרוגים מתגלגלים.
- יתירות כשל על סמך תקינות: מעקב אחרי התקינות של קצוות עורפיים בכל האשכולות וניתוב מחדש באופן אוטומטי של תנועה מאשכול שמתרוקן או שנתקל בבעיות.
למידע נוסף, עיינו במדריך פריסת שער מרובה אשכולות לפיצול תנועה משוקלל.
שימוש ב-Multi Cluster Ingress לניהול מחזור החיים של אשכולות
פתרון נוסף לניהול תנועה בכמה אשכולות הוא Multi Cluster Ingress. Multi Cluster Ingress הוא בקר כניסה (ingress) מרובה אשכולות שמארח Google Cloudלאשכולות GKE, שתומך בפריסת משאבים משותפים של איזון עומסים באשכולות ובאזורים שונים. Multi Cluster Ingress הוא פתרון להעברת תנועת לקוחות לשירות מבוזר שפועל באשכולות רבים באזורים רבים. בדומה ל-Ingress ל-GKE, הוא משתמש ב-Cloud Load Balancing כדי לשלוח תנועה לשירות קצה עורפי. שירות הקצה העורפי הוא השירות המבוזר. שירות הקצה העורפי שולח תנועה לכמה רכיבי קצה עורפי, שהם שירותי Kubernetes שפועלים בכמה אשכולות GKE. כדי לנהל תעבורה בין שירותים באשכולות שונים, אפשר להשתמש בטכנולוגיות של רשת שירותים כמו Cloud Service Mesh או Istio, שמספקות פונקציונליות דומה בשירותים מבוזרים.
למידע נוסף, אפשר לעיין במדריך בנושא שדרוג סביבת GKE מרובת אשכולות באמצעות Multi Cluster Ingress.