במאמר הזה נסביר איך לתכנן ולבצע שדרוגים בסביבת Google Kubernetes Engine (GKE) עם כמה אשכולות. במסמך הזה נעשה שימוש ב-Multi Cluster Ingress לשדרוגים, אבל אפשר להחיל את המושגים גם על פתרונות אחרים. המסמך הזה מיועד לאדמינים שאחראים על תחזוקת צי GKE clusters. Google Cloud
ניהול מחזור החיים של אשכולות GKE
ניהול מחזור החיים של אשכולות מוגדר כאסטרטגיות והתכנון שנדרשים כדי לשמור על צי של אשכולות Kubernetes תקינים ומעודכנים, בלי להפר את הסכמי רמת השירות (SLO) של השירות. אם יש לכם תוכנית אסטרטגית טובה, ניהול מחזור החיים של האשכול צריך להיות שגרתי, צפוי ונטול אירועים מיוחדים.
מידע נוסף על ניהול הגרסה של אשכול GKE זמין במאמר מידע על שדרוגים של אשכולות GKE. מידע נוסף על ניהול כל סוגי השינויים במהלך מחזור החיים של אשכול זמין במאמר ניהול שינויים במחזור החיים של אשכול כדי למזער שיבושים.
ניהול מחזור החיים של כמה אשכולות ב-GKE
בקטע הזה מתוארות אסטרטגיות שונות לניהול מחזור החיים של כמה אשכולות GKE, ומוסבר איך לתכנן את השימוש בהן.
שיקולים בתכנון ובעיצוב
ארכיטקטורת ה-multi-cluster של GKE משפיעה על הבחירה של אסטרטגיית ניהול מחזור החיים של האשכול. לפני שנדון בשיטות האלה, חשוב לדון בהחלטות עיצוביות מסוימות שעשויות להשפיע על אסטרטגיית הניהול של מחזור החיים של האשכול או להיות מושפעות ממנה.
סוג האשכולות
אם אתם משתמשים בשדרוג אוטומטי של GKE כשיטה לניהול מחזור החיים של אשכול, סוג האשכול יכול להיות חשוב. לדוגמה, באשכולות אזוריים יש כמה צמתים של רמת הבקרה, והשדרוג של הצמתים האלה מתבצע אוטומטית אחד בכל פעם. באשכולות אזוריים יש צומת אחד של רמת הבקרה. אם אתם לא משתמשים בשדרוג אוטומטי של GKE ואם אתם רואים בכל אשכול Kubernetes תשתית שניתן להשליך, יכול להיות שלא משנה איזה סוג אשכול תבחרו כשאתם מחליטים על אסטרטגיית ניהול מחזור החיים של האשכול. אפשר להחיל את האסטרטגיות שמוסברות בקטע הבא, ניהול מחזור החיים של כמה אשכולות ב-GKE על כל סוג של אשכול.
מיקום וגודל של אשכול
כשמחליטים על המיקום והגודל של האשכול, כדאי לקחת בחשבון את הגורמים הבאים:
- אזורים שבהם נדרש להציב את האשכולות.
- מספר האשכולות והגודל שלהם.
בדרך כלל קל לטפל בגורם הראשון כי האזורים והאזורים הגיאוגרפיים נקבעים לפי העסק והאזורים שבהם אתם מספקים שירות למשתמשים.
הטיפול במספר ובגודל של אשכולות בדרך כלל נחלק לקטגוריות הבאות, שלכל אחת מהן יש יתרונות וחסרונות:
- מספר קטן של אשכולות גדולים. אתם יכולים להשתמש ביתירות ובחוסן שקלאסטרים אזוריים מספקים, ולהציב קלאסטר אזורי גדול אחד (או שניים) לכל אזור. היתרון של הגישה הזו הוא שאין הרבה תקורה תפעולית בניהול של כמה אשכולות. החיסרון הוא שהיא עלולה להשפיע על מספר גדול של שירותים בבת אחת בגלל אזור ההשפעה הגדול שלה.
- מספר גדול של אשכולות קטנים. אתם יכולים ליצור מספר גדול של אשכולות קטנים כדי לצמצם את אזור ההשפעה של האשכול, כי השירותים שלכם מחולקים בין הרבה אשכולות. הגישה הזו מתאימה גם לאשכולות זמניים לטווח קצר (לדוגמה, אשכולות שמריצים עומס עבודה של אצווה). החיסרון בגישה הזו הוא תקורה תפעולית גבוהה יותר, כי יש יותר אשכולות לשדרוג. יכול להיות שיהיו גם עלויות נוספות שקשורות למספר גבוה יותר של צמתים במישור הבקרה. אפשר לקזז את העלויות ואת התקורה התפעולית הגבוהה באמצעות אוטומציה, תזמון ואסטרטגיה צפויים ותיאום קפדני בין הצוותים והשירותים המושפעים.
במסמך הזה לא מומלצת גישה אחת על פני אחרת, אלא מוצגות אפשרויות. במקרים מסוימים, אפשר לבחור את שני דפוסי העיצוב לקטגוריות שונות של שירותים.
השיטות הבאות פועלות עם כל אחת מהאפשרויות.
תכנון קיבולת
כשמתכננים את הקיבולת, חשוב לקחת בחשבון את אסטרטגיית מחזור החיים של האשכול שנבחר. בתכנון הקיבולת צריך לקחת בחשבון את עומס השירות הרגיל ואת אירועי התחזוקה הבאים:
- אירועים מתוכננים כמו שדרוגי אשכולות
- אירועים לא מתוכננים כמו הפסקות חשמל באשכולות, לדוגמה, דחיפות של הגדרות שגויות ופריסות שגויות
כשמתכננים את הקיבולת, צריך לקחת בחשבון הפסקות שירות מלאות או חלקיות. אם אתם מתכננים רק אירועי תחזוקה מתוכננים, כל השירותים המבוזרים צריכים לכלול אשכול נוסף מעבר לנדרש, כדי שתוכלו להוציא אשכול אחד מהמחזור בכל פעם לצורך שדרוגים בלי לפגוע בשירות. הגישה הזו נקראת גם N+1 capacity planning. אם אתם מתכננים אירועי תחזוקה מתוכננים ולא מתוכננים, לכל השירותים המבוזרים צריכים להיות שני אשכולות נוספים (או יותר) מעבר לנדרש כדי לספק את הקיבולת המיועדת – אחד לאירוע המתוכנן ואחד לאירוע לא מתוכנן, למקרה שהוא יתרחש במהלך חלון הזמן של התחזוקה המתוכננת. הגישה הזו נקראת גם תכנון קיבולת N+2.
בארכיטקטורות מרובות אשכולות, המונחים ניקוז וגלישה משמשים לעיתים קרובות. המונחים האלה מתייחסים לתהליך של הסרת תעבורה (או ניקוז תעבורה) מאשכול והפניה לכתובת אחרת (או העברת תעבורה) לאשכולות אחרים במהלך שדרוגים ואירועי תחזוקה. התהליך הזה מתבצע באמצעות פתרונות רשת כמו Ingress בכמה אשכולות או שיטות אחרות לאיזון עומסים. שימוש זהיר בריקון ובגלישה הוא הבסיס לכמה אסטרטגיות לניהול מחזור החיים של אשכולות. כשמתכננים את הקיבולת, צריך לקחת בחשבון את הניקוז וההצפה. לדוגמה, כשמרוקנים אשכול אחד, צריך לבדוק אם יש לאשכולות האחרים מספיק קיבולת כדי לטפל בתנועה הנוספת שמופנית אליהם. שיקולים נוספים כוללים קיבולת מספקת באזור או באזור, או צורך לשלוח תעבורה לאזור אחר (אם משתמשים באשכול אזורי יחיד לכל אזור). בתרשים הבא מוצגת תנועה שמוסרת (לפעמים נקראת ניקוי של אשכול) מאשכול אחד ונשלחת לאשכול אחר שמריץ את אותו שירות מבוזר.
אשכולות ושירותים מבוזרים
עיצוב אשכולות שמבוסס על שירותים קובע שארכיטקטורת האשכולות (מספר, גודל ומיקום) נקבעת לפי השירותים שנדרשים להפעלה באשכולות. לכן, המיקום של האשכולות נקבע לפי המקום שבו נדרשים השירותים המבוזרים. כשמחליטים איפה למקם שירותים מבוזרים, כדאי להביא בחשבון את הנקודות הבאות:
- דרישה לגבי מיקום. באילו אזורים צריך להפעיל את השירות?
- חשיבות. עד כמה זמינות השירות חשובה לעסק?
- SLO. מהם היעדים למדידת רמת השירות (SLO) של השירות (בדרך כלל על סמך רמת הקריטיות)?
- חוסן. מה רמת העמידות הנדרשת של השירות? האם צריך לעמוד בפני כשלים באשכול, באזור או אפילו באזור גיאוגרפי?
כשמתכננים שדרוגים של אשכולות, צריך לקחת בחשבון את מספר השירותים שאשכול יחיד משפיע עליהם כשהוא מתרוקן, ולתכנן את ההעברה של כל אחד מהשירותים האלה לאשכולות מתאימים אחרים. אשכולות יכולים להיות עם דייר יחיד או עם כמה דיירים. קלאסטרים עם דייר יחיד משרתים רק שירות אחד או מוצר שמיוצג על ידי קבוצה של שירותים. במערכות של לקוח יחיד, האשכול לא משותף עם שירותים או מוצרים אחרים. אפשר להפעיל באשכולות מרובי-דיירים הרבה שירותים ומוצרים שמחולקים בדרך כלל למרחבי שמות.
ההשפעה על הצוותים
אירוע באשכול לא משפיע רק על שירותים, אלא גם על צוותים. לדוגמה, יכול להיות שצוות ה-DevOps יצטרך להפנות מחדש את צינורות ה-CI/CD או לעצור אותם במהלך שדרוג של אשכול. באופן דומה, צוותי תמיכה יכולים לקבל התראות על הפסקות שירות מתוכננות. צריך להטמיע אוטומציה וכלים כדי להקל על ההשפעה על כמה צוותים. שדרוג של אשכול או של צי אשכולות צריך להיחשב כפעולה שגרתית ופשוטה אם כל הצוותים קיבלו על כך הודעה.
תזמון, תכנון ותיאום
ב-Kubernetes יוצאת גרסה משנית חדשה מדי רבעון, והתחזוקה מתבצעת ל-3 הגרסאות האחרונות. חשוב לתכנן בקפידה את התזמון של שדרוגי האשכולות. צריך להגיע להסכמה בין בעלי השירות, מפעילי השירות ואדמינים של הפלטפורמה לגבי המועד שבו יתבצעו השדרוגים האלה. כשמתכננים שדרוגים, כדאי להביא בחשבון את השאלות הבאות:
- באיזו תדירות אתם משדרגים? האם אתם משדרגים כל רבעון או בפרק זמן אחר?
- מתי כדאי לשדרג? האם אתם משדרגים בתחילת הרבעון כשהפעילות העסקית מואטת, או במהלך תקופות השבתה אחרות בעסק שנובעות מהתחום שלכם?
- מתי לא כדאי לשדרג? האם יש לכם תוכנית ברורה לגבי מתי לא כדאי לשדרג, למשל, להימנע מאירועים עם נפח גדול כמו בלאק פריידיי, סייבר מאנדיי או במהלך כנסים בולטים ואירועים אחרים שספציפיים לתעשייה.
חשוב להגדיר אסטרטגיה ולעדכן בה בצורה ברורה את בעלי השירות, את צוות התפעול ואת צוות התמיכה. לא אמורים להיות הפתעות, וכולם צריכים לדעת מתי ואיך מתבצע שדרוג של האשכולות. כדי לעשות את זה, צריך לתאם באופן ברור עם כל הצוותים המעורבים. לשירות יחיד יש כמה צוותים שמשתמשים בו. בדרך כלל, אפשר לקבץ את הצוותים האלה לקטגוריות הבאות:
- מפתח השירות, שאחראי ליצירה ולתכנות של הלוגיקה העסקית בשירות.
- מפעיל השירות, שאחראי להפעלה בטוחה ואמינה של השירות. המפעילים יכולים להיות מורכבים מכמה צוותים, כמו אדמין של מדיניות או אבטחה, אדמין של רשתות וצוותי תמיכה.
כל המשתתפים צריכים להיות בקשר במהלך שדרוגי האשכול, כדי שיוכלו לבצע את הפעולות הנדרשות בזמן הזה. אחת הגישות היא לתכנן שדרוגים באותו אופן שבו מתכננים אירוע של הפסקת שירות. יש לכם מנהל אירוע, חדר צ'אט וסיכום (גם אם אף משתמש לא הושפע). מידע נוסף זמין במאמר בנושא תגובה לאירועים.
שיטות לניהול מחזור החיים של אשכולות GKE
בקטע הזה נסביר על האסטרטגיות העיקריות לניהול מחזור החיים של אשכולות, שבהן נעשה שימוש בדרך כלל בארכיטקטורה של כמה אשכולות ב-GKE. חשוב לזכור ששיטה אחת לא תתאים לכל התרחישים, ויכול להיות שתבחרו כמה שיטות לקטגוריות שונות של שירותים ולצרכים שונים של העסק.
שדרוגים בהדרגה (rolling)
התרשים הבא מציג את אסטרטגיית השדרוג המתגלגל.
באמצעות מאזן עומסים, כל התנועה מנותבת מאשכול 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) של השירות. אחרי שהתנועה עוברת במלואה לאשכולות החדשים, מרוקנים את האשכולות עם הגרסה הישנה ומוחקים אותם.
האסטרטגיה הכחולה/ירוקה לשדרוג אשכולות דומה לאסטרטגיה כחולה/ירוקה שמשמשת בדרך כלל לשירותים. יצירה של כמה אשכולות חדשים בו-זמנית מגדילה את העלות הכוללת, אבל מקצרת את זמן השדרוג של צי המכונות. העלות הנוספת היא רק למשך השדרוג, כשמשתמשים באשכולות נוספים. היתרון ביצירת אשכולות חדשים קודם הוא שאם משהו משתבש, אפשר לבטל את השינוי. אפשר גם לבדוק את האשכול החדש לפני ששולחים אליו תנועה של נתוני ייצור. האשכולות האלה פועלים במקביל לגרסה הישנה שלהם למשך תקופה קצרה, ולכן העלויות הנוספות הן מינימליות.
אם חשוב לכם שהשדרוג יהיה פשוט ועמיד יותר מאשר זול, כדאי להשתמש באסטרטגיית השדרוג הכחול/ירוק. קודם כל נוספים אשכולות נוספים, והם חורגים מהקיבולת הנדרשת של צי GKE למשך השדרוגים.
בתרשים שלמעלה, הוספה של אשכול חדש מגדילה באופן זמני את הקיבולת הזמינה מעבר לקיבולת הנדרשת, בזמן שאשכול אחר בצי מתרוקן ומוסר מהצי. אבל אחרי שמסירים אחד מהאשכולות הישנים (שנפרקו לגמרי), הקיבולת חוזרת למה שנדרש. השינוי הזה בקיבולת מודגש כי יכול להיות שהעלות תגדל עם המודל הזה, בהתאם למספר ולגודל של האשכולות ב-Fleet.
שדרוגים של אשכולות Canary
שדרוג אשכול קנרי הוא האסטרטגיה הכי עמידה ומורכבת מבין האסטרטגיות שמוסברות במסמך הזה. השיטה הזו מפרידה לחלוטין בין ניהול מחזור החיים של האשכול לבין ניהול מחזור החיים של השירותים, וכך מציעה את הסיכון הנמוך ביותר ואת החוסן הגבוה ביותר לשירותים שלכם. באסטרטגיות הקודמות של שדרוג מתגלגל ושדרוג כחול/ירוק, כל צי GKE נשאר באותה גרסה. בשיטה הזו, אתם מחזיקים בשני או אולי שלושה ציי של אשכולות GKE שפועלות בהם גרסאות שונות. במקום לשדרג את האשכולות, מעבירים את השירותים מ-Fleet אחד של אשכולות ל-Fleet האחר לאורך זמן. אחרי שכל השירותים מועברים ל-Fleet של GKE עם הגרסה החדשה, אפשר למחוק את ה-Fleet הקודם של GKE.
כדי להשתמש באסטרטגיה הזו, צריך לשמור על מינימום של שני צי GKE – אחד לגרסת הייצור הנוכחית ואחד לגרסת המועמד הבאה לייצור. אפשר גם לנהל יותר משני ציי GKE. הוספת צי רכבים נותנת לכם יותר גמישות, אבל גם מגדילה את העלות והעומס התפעולי. הציים הנוספים האלה לא זהים לשימוש באשכולות בסביבות שונות, למשל סביבות פיתוח, Staging וייצור. סביבות שאינן סביבות ייצור מתאימות לבדיקת התכונות והשירותים של Kubernetes עם תעבורה שאינה תעבורת ייצור.
השיטה הזו של שדרוגי אשכולות קנריים מחייבת שמירה של כמה גרסאות של GKE Fleet בסביבת הייצור. זה דומה לאסטרטגיות של גרסה איטרטיבית לקהל מצומצם (canary release), שמשמשות לעיתים קרובות שירותים. בעזרת פריסות קנריות של שירותים, בעלי השירות יכולים תמיד לאתר בעיות בגרסה מסוימת של השירות. במקרה של אשכולות גרסה ראשונית (canary), בעלי השירות צריכים לקחת בחשבון גם את גרסאות Fleet של GKE שבהן השירותים שלהם פועלים. גרסה אחת של שירות מבוזר יכולה לפעול בכמה גרסאות של צי GKE. ההעברה של שירות יכולה להתבצע בהדרגה, כדי שתוכלו לראות את ההשפעות של השירות על צי המכונות החדש לפני שתשלחו את כל התנועה של השירות לאשכולות החדשים עם הגרסאות.
הדיאגרמה הבאה מראה שניהול של Fleet של אשכולות GKE שונים יכול להפריד לחלוטין בין מחזור החיים של האשכול לבין מחזור החיים של השירותים.
בתרשים הקודם מוצג שירות מבוזר frontend שמועבר בהדרגה מצי אחד של אשכולות GKE לצי הבא שמריץ את הגרסה החדשה, עד שהצי הישן יותר מתרוקן לחלוטין לאורך זמן. אחרי שכל המכונות בצי יתרוקנו, אפשר להסיר אותו וליצור צי חדש. כל השירותים מועברים לצי הבא, והציים הישנים מוסרים כשהם מתרוקנים.
אם החוסן חשוב לכם יותר מכל דבר אחר, כדאי להשתמש באסטרטגיית השדרוג של אשכול קנרי.
בחירת אסטרטגיית שדרוג
התרשים הבא יכול לעזור לכם לקבוע איזו אסטרטגיה הכי מתאימה לכם על סמך השירות והצרכים העסקיים.
התרשים שלמעלה הוא עץ החלטות שיעזור לכם לבחור את אסטרטגיית השדרוג שמתאימה לכם:
- אם אתם לא צריכים שליטה מלאה בגרסה המדויקת ובזמן השדרוג, אתם יכולים לבחור בתכונת השדרוג האוטומטי שזמינה ב-GKE.
- אם העדיפות שלכם היא עלות נמוכה, אתם יכולים לבחור באסטרטגיית השדרוג המתגלגל.
- אם העדיפות שלכם היא איזון בין עלות לבין עמידות, אתם יכולים לבחור באסטרטגיית blue/green.
- אם העמידות חשובה לכם יותר מהעלות, תוכלו לבחור באסטרטגיית השדרוג של אשכול קנרי.
ניהול תנועה בין כמה אשכולות למחזור החיים של אשכולות GKE
כדי לשמור על זמינות השירות במהלך שדרוגים של כמה אשכולות, צריך לנקז את התנועה ולנתב אותה מחדש בין האשכולות. אפשר לנהל את התנועה הזו באמצעות שער מרובה אשכולות (מומלץ) או Multi Cluster Ingress. Multi-cluster Gateway הוא המחליף של Multi Cluster Ingress, והוא מספק גישה יותר מפורטת ומבוססת-תפקידים לרשת שירותים.
שימוש בשער מרובה אשכולות לניהול מחזור החיים של אשכולות
Multi-cluster Gateway (MCG) משתמש ב-Gateway API כדי לנהל את התנועה של שירותים שנפרסו בכמה אשכולות GKE בתוך צי.
בקר GKE Gateway הוא שירות שמתארח ב-Google ועוקב אחרי משאבי Gateway ו-HTTPRoute באשכול הגדרות ייעודי. הבקר מקצה ומנהל אוטומטית את תשתית איזון העומסים, ומספק נקודת כניסה מאוחדת אחת לאפליקציות בכל האשכולות ב-Fleet. הארכיטקטורה הזו מאפשרת לכם להפריד את מחזור החיים של מאזן העומסים מאשכולות GKE נפרדים שבהם נמצאים עומסי העבודה.
לניהול מחזור החיים של אשכולות GKE, שער רב-אשכולי מאפשר שיטות מתקדמות לשליטה בתנועה:
- שדרוגים מסוג blue-green: פריסת אשכול חדש מסוג green והעברת התנועה בהדרגה מאשכול מסוג blue על ידי שינוי המשקלים במשאב HTTPRoute.
- איזון עומסים לפי קיבולת: הפניית תנועה אוטומטית כששירות באחד האשכולות מגיע למגבלת הקיבולת המוגדרת שלו, מה שעוזר להגן עליו מפני עומס יתר במהלך שדרוגים מתגלגלים.
- מעבר לגיבוי (failover) על סמך תקינות: מעקב אחרי התקינות של שרתי קצה בכל האשכולות והפניית תנועה אוטומטית מאשכול שמתבצע בו ניקוי או שנתקל בבעיות.
מידע נוסף זמין במדריך בנושא פריסת שער מרובה אשכולות לפיצול תנועה משוקלל.
שימוש ב-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.