בדף הזה מוסבר איך אתם ו-Google Kubernetes Engine (GKE) מנהלים שינויים במהלך מחזור החיים של אשכול כדי למקסם את הביצועים והזמינות ולצמצם את השיבושים בעומסי העבודה.
הדף הזה מיועד לאדמינים של פלטפורמות שרוצים לתכנן ולבצע אופטימיזציה של סביבת האשכולות כדי לצמצם את ההפרעות לעומסי העבודה. אפשר לקרוא את הדף הזה לפני או אחרי שקוראים את המאמרים ניהול אשכולות וסקירה כללית על ניהול אשכולות, שבהם מוסבר איך לבצע את משימות הניהול הבסיסיות של אשכולות.
פלטפורמה מנוהלת ואחריות משותפת
GKE הוא הטמעה מנוהלת של Google של פלטפורמת תזמור קונטיינרים בקוד פתוח Kubernetes. כמו שצוין במאמר איך GKE פועל, אשכול GKE מורכב ממישור בקרה, שכולל צמתי ניהול שבהם פועלים רכיבי מערכת, ומצמתי עובדים שבהם פורסים עומסי עבודה.
יצירת סביבת אשכול אופטימלית להרצת עומסי העבודה, עם ביצועים מקסימליים, זמינות גבוהה והפרעות מינימליות, היא אחריות משותפת:
- האחריות של GKE היא לשמור על סביבת אשכולות אמינה, זמינה, מאובטחת ובעלת ביצועים טובים. לשם כך, GKE מנהל את מישור הבקרה, את רכיבי המערכת ובמצב Autopilot גם את צמתי העובדים.
- האחריות שלכם כאדמינים של הפלטפורמה היא להגדיר את האשכול ולנהל את עומסי העבודה, כולל הכנתם לטיפול בהפרעות. במצב רגיל, אתם גם יוצרים ומנהלים את צמתי העובדים, שמקובצים במאגרי צמתים.
מידע נוסף זמין במאמר בנושא אחריות משותפת ב-GKE.
איך GKE מנהל שינויים במהלך מחזור החיים של אשכול
כיישום של Kubernetes, אשכול GKE הוא רשת של תהליכים ומערכות שפועלים יחד כדי לשמור על סביבה אופטימלית להרצת עומסי העבודה. כדי לנהל את האשכול, GKE מבצע משימות תחזוקה, מבצע שינויים, מתחיל פעולות, מעדכן רכיבים ומשדרג את הגרסה של מישור הבקרה והצמתים.
רוב הפעולות השוטפות של האפליקציה מתבצעות בשקט ברקע, כדי שעומסי העבודה יפעלו ללא הפרעה. עם זאת, יש שינויים קריטיים שצריך לבצע אותם בדרכים שעלולות לשבש באופן זמני את עומסי העבודה, כמו שמתואר בקטע הבא.
חלק מהשינויים באשכולות עלולים לשבש את עומסי העבודה
מערכת GKE פועלת כדי שעומסי העבודה יפעלו בצורה חלקה, אבל שינויים מסוימים יכולים לגרום להפרעות זמניות בעומסי העבודה – בעיקר שינויים שמפעילים מחדש את הצמתים שבהם פועלים עומסי העבודה. באמצעות תכונות של GKE ו-Kubernetes, אתם יכולים לציין מתי ואיך אתם רוצים שהשיבוש יתרחש, כך שכשהוא יקרה, עומסי העבודה יוכלו לטפל בשינויים בצורה חלקה.
בקטעים הבאים מוסבר אילו סוגי שינויים מתבצעים באשכולות GKE, איזה סוג של שיבוש הם גורמים ואיך אפשר להתכונן לקראתם.
שדרוגים ועדכונים באמצעות ניהול מחזור החיים של אשכולות GKE
ב-GKE, לשדרוגים של אשכולות ולעדכונים של אשכולות יש משמעויות קשורות.
ב-GKE, המונח שדרוגים של אשכולות – או פשוט שדרוגים – מתייחס לעדכון של גרסת Kubernetes של מישור הבקרה (שדרוגים של מישור הבקרה) או של הצמתים (שדרוגים של צמתים), או של שניהם. כשמשתמשים באשכולות Standard, שדרוגי צמתים נקראים גם שדרוגי מאגר צמתים, כי GKE משתמש בפעולה אחת כדי לשדרג מאגר צמתים.
המונח עדכוני אשכולות – או פשוט עדכונים – הוא מונח כללי יותר שמתייחס לכל סוג של שינויים ברמת הבקרה או בצמתים, כולל עדכון הגרסאות שלהם. GKE מנהל באופן פעיל את סביבת האשכול על ידי ביצוע שדרוגים, סוגים אחרים של עדכונים ופעולות תחזוקה נדרשות. הפעולות האלה מבטיחות שהאשכול יישאר יעיל, מאובטח ועדכני עם התכונות האחרונות ותיקוני הבאגים. ב-GKE נעשה שימוש בכלים כמו אסטרטגיות לשדרוג צמתים ומדיניות תחזוקה כדי לצמצם את ההפרעות במהלך התהליכים האלה.
תכנון שיבושים בעדכון הצמתים
סוגים מסוימים של שינויים באשכול – בעיקר שינויים בצמתים – עלולים לגרום לשיבוש.
GKE משתמש בשיטות לשדרוג צמתים כדי לעדכן צמתים – צמתים של Autopilot או מאגרי צמתים של אשכול Standard – באופן שמבצע אופטימיזציה לצרכים של עומס העבודה. השיטות האלה רלוונטיות לשדרוגי גרסה וגם לכמה סוגים אחרים של שינויים בצומת. השיטות האלה מאפשרות ל-GKE לצמצם את ההפרעות במהלך עדכוני הצמתים, שחשובים לשמירה על תפקוד האשכולות ועל הביצועים שלהם.
אתם יכולים להשתמש בחלונות זמן לתחזוקה ובחריגות כדי לבחור מתי תתבצע תחזוקה מסוימת של האשכול ומתי לא, ובאשכולות רגילים, לבחור אסטרטגיית שדרוג של הצומת שהכי מתאימה לפרופיל העומס ולמגבלות המשאבים שלכם.
גם כשמבצעים שינויים בצמתים באופן ידני וגם כשמבצעים אותם באופן אוטומטי, GKE מבצע את השינויים עם המאפיינים הכלליים הבאים:
- השינויים בדרך כלל תואמים למדיניות התחזוקה: כש-GKE מבצע שינויים בצמתים, השינויים האלה בדרך כלל תואמים למדיניות התחזוקה של GKE.
אם אתם מבצעים שינויים ידניים שדורשים יצירה מחדש של כל הצמתים במאגר הצמתים, כדאי לשים לב לנקודות הבאות:
- במקרה של חלק מהשינויים, מערכת GKE מתחשבת במדיניות התחזוקה ולא מיישמת את השינוי ששלחתם עד שיש זמינות לתחזוקה. אם GKE ממתין לזמינות של תחזוקה והשינוי דחוף, אפשר להחיל את השינויים באופן ידני כדי להחיל את ההגדרה החדשה באופן מיידי.
- בשינויים ידניים אחרים, כולל שדרוגים ידניים, GKE לא מתחשב במדיניות התחזוקה. כשמבצעים שינויים ידניים כאלה, צריך לוודא שעומסי העבודה מוכנים להפרעה מיידית.
- שינויים בדרך כלל משתמשים בשיטות לשדרוג צמתים: כש-GKE מבצע את רוב השינויים האוטומטיים או השינויים שהופעלו באופן ידני בצמתים – כולל עדכוני צמתים שאינם שדרוגי גרסה – GKE בוחר שיטה לשדרוג צמתים: שדרוגים מצטברים, שדרוגים מסוג blue-green או שדרוגים מסוג blue-green עם שינוי גודל אוטומטי (גרסת Preview). במצב Autopilot תמיד נעשה שימוש בשדרוגים מצטברים. שינויים במאגרי צמתים של אשכול Standard בדרך כלל משתמשים בשדרוגים מצטברים, אלא אם הגדרתם שדרוגים מסוג blue-green או שדרוגים מסוג blue-green עם שינוי גודל אוטומטי וביצעתם סוגים מסוימים של שינויים. למידע נוסף על השיטה שמוגדרת למאגר צמתים, אפשר לעיין במאמר בדיקת הגדרות השדרוג של מאגר צמתים.
- שינויים דורשים מספיק משאבים: כש-GKE מבצע שינוי באמצעות אסטרטגיית שדרוג של צומת, השינוי הזה דורש כמות מסוימת של משאבים, בהתאם לאסטרטגיה ולתצורה שלה. בפרויקט של האשכול צריך להיות מספיק מכסת משאבים, זמינות משאבים ויכולת שריון (למאגרי צמתים עם שיוך ספציפי של שריון). מידע נוסף זמין במאמר בנושא הקצאת משאבים לשדרוג צמתים.
רשימה מפורטת של שינויים ספציפיים ומאפיינים שלהם מופיעה בקטע סוגי שינויים באשכול GKE בדף הזה.
הגדלת הזמינות של עומסי העבודה באמצעות היערכות לשינויים משבשים
כדי למקסם את הזמינות של עומסי העבודה שפועלים באשכול GKE, מומלץ לבצע את הפעולות שמתוארות בקטעים הבאים:
בחירת הזמינות של האשכול
אם זמינות מישור הבקרה היא בראש סדר העדיפויות, כדאי לבחור באשכול Autopilot או באשכול סטנדרטי אזורי, ולא באשכול סטנדרטי לפי אזור. מידע נוסף זמין במאמר אפשרויות להגדרת אשכול.
שליטה בשדרוגים באמצעות כלי GKE
אתם יכולים להשתמש בכלים הבאים כדי לקבוע מתי ואיך GKE ישדרג את האשכול, וכך ליישם את שיטות העבודה המומלצות:
- ערוצי הפצה: בוחרים ערוץ הפצה כדי לקבל גרסאות של אשכולות עם איזון בין זמינות התכונות ליציבות, לפי הבחירה שלכם.
- חלונות זמן לתחזוקה: מציינים חלון זמן חוזר שבו יכולים להתבצע סוגים מסוימים של תחזוקה באשכול GKE, כמו שדרוגים.
- החרגות מתחזוקה: מונעות את התחזוקה של האשכול למשך תקופה מסוימת.
- תקציבים לשיבוש אשכולות: התאמה אישית של מרווח הזמן המינימלי בין סוגים ספציפיים של שדרוגי אשכולות, כולל שדרוגי תיקון או שדרוגים משניים.
- אסטרטגיות לשדרוג צמתים: אם משתמשים במאגר צמתים רגיל, בוחרים איך הצמתים ישודרגו – שדרוג הדרגתי, שדרוג blue-green או שדרוג blue-green עם שינוי גודל אוטומטי (בגרסת Preview) – כדי למזער את ההפרעה לעומסי העבודה. בנוסף, בוחרים כמה מאגרי צמתים ישודרגו אוטומטית על ידי GKE בו-זמנית באשכול.
- רצף ההשקה: הגדרת שדרוגים בסביבת טרום-ייצור לפני ש-GKE ישדרג את אשכולות הייצור.
- שדרוגים ידניים: שדרוג ידני של האשכול, וביצוע פעולות כמו ביטול, חידוש, חזרה לגרסה קודמת והשלמה של שדרוגים אוטומטיים או ידניים שנמצאים בתהליך.
ניהול האשכול ומעקב אחריו
כדי למנוע שיבושים פוטנציאליים באשכולות, צריך לבצע באופן רציף את המשימות הבאות:
- עוקבים אחרי האשכול באמצעות חבילת כלי התצפית של GKE.
- הודעות על עדכונים מופיעות בהערות לגבי מהדורות GKE.
- הצגת התראות על אשכולות, למשל מתי מתחילים או מסיימים שדרוגים, מתי גרסאות חדשות זמינות, עלוני אבטחה ותאריכי סיום התמיכה.
- קבלת תמונה ברורה יותר של שדרוגי האשכולות כדי להבין את מצב השדרוגים של האשכולות.
- כדאי לעיין בלוח הזמנים של מהדורות GKE כדי לקבל הערכה אופטימית לגבי הזמן שבו גרסאות משניות יהיו זמינות לשדרוגים, ועד סיום התמיכה.
- ההנחיות המפורטות מזהות הזדמנויות פוטנציאליות לאופטימיזציה ומסבירות איך לבצע אופטימיזציה של השימוש באשכול, כולל הנחיות לגבי הוצאה משימוש של תכונות ו-API.
הכנת עומסי העבודה
כדי לצמצם את ההפרעות, כדאי להפוך את עומסי העבודה לעמידים ככל האפשר בפני הפרעות:
- מריצים רפליקות של עומסי העבודה כדי להבטיח יתירות ולהימנע מנקודת כשל בודדת.
- מגדירים תקציב לשיבוש באפליקציה באמצעות תקציב לשיבוש Pod.
- מגדירים תקופת חסד לסיום באורך המתאים לעומס העבודה, כדי שהכיבוי יתבצע בצורה מסודרת.
- אם עומס העבודה שלכם משתמש ב-GPU או ב-TPU, אתם צריכים לפעול לפי ההוראות לניהול שיבושים בצמתי GKE עבור GPU ו-TPU.
- עבור אפליקציות עם שמירת מצב, שלעתים קרובות צריכות זמן כדי להפסיק את פעולות הקלט/פלט בצורה נקייה ולבטל את ההתקנה מנפח האחסון, פועלים לפי השלבים במאמר איך מוודאים שעומסי עבודה עם שמירת מצב מוכנים להפרעות.
לדיון כללי בנושאים האלה, אפשר לקרוא את הקטע ניהול שיבושים בפוסט בבלוג שיטות מומלצות ל-GKE: פעולות ביום 2 להמשכיות עסקית.
סוגי שינויים באשכול GKE
בטבלאות הבאות מוצגים הסוגים הנפוצים ביותר של שינויים משמעותיים באשכול, כולל מאפיינים של השינויים האלה כמו תדירות ורמת השיבוש.
סוגי שדרוגים
בטבלה הבאה מוסבר איך שדרוגים יכולים לשבש סביבת אשכול.
| שינוי | אוטומטית או ידנית | תואם למדיניות התחזוקה | תדירות | סוג השיבוש | רמת השיבוש |
|---|---|---|---|---|---|
| שדרוג של מישור הבקרה | אוטומטי או ידני |
שדרוגים אוטומטיים מתבצעים בהתאם למדיניות התחזוקה עד לסיום התמיכה, למעט תיקוני חירום נדירים ביותר, לפי הצורך. מדיניות התחזוקה לא חוסמת שדרוגים ידניים. |
שדרוגי תיקון, בתדירות של פעם בשבוע, בהתאם לערוץ ההפצה. שדרוגים קלים בערך כל ארבעה חודשים. במקרים של אשכולות ערוצים מורחבים, שדרוגים משניים מתבצעים רק כשהגרסה המשנית מתקרבת לסוף התמיכה. |
מישור הבקרה |
במצב Autopilot ובאשכולות אזוריים רגילים, מישור הבקרה נשאר זמין. במקרה של אשכולות אזוריים מסוג Standard, יכול להיות שלא תהיה אפשרות לתקשר עם מישור הבקרה במשך כמה דקות, כלומר לא תוכלו להגדיר את האשכול, הצמתים ועומסי העבודה במהלך הזמן הזה. |
| שדרוג צומת | אוטומטי או ידני |
שדרוגים אוטומטיים מתבצעים בהתאם למדיניות התחזוקה עד לסיום התמיכה, למעט תיקוני חירום נדירים ביותר, לפי הצורך. מדיניות התחזוקה לא חוסמת שדרוגים ידניים. |
בדרך כלל זהה לשדרוגים של מישור הבקרה. אם האשכול שלכם לא רשום בערוץ הפצה והשבתתם את השדרוגים האוטומטיים של הצמתים, אתם אחראים לשדרוג ידני של מאגרי הצמתים באשכול. |
כל הצמתים באשכולות במצב Autopilot, או מאגר צמתים אחד או יותר באשכולות סטנדרטיים. |
צריך להשבית את הצמתים כדי ליצור אותם מחדש, ולהחליף את ה-Pods. ב-GKE נעשה שימוש בשדרוגים מצטברים ב-Autopilot, או בשיטת השדרוג של הצמתים שהוגדרה (מצטבר, blue-green או autoscaled blue-green (גרסת Preview)) באשכולות Standard. |
שינויים ידניים שיוצרים מחדש את הצמתים באמצעות אסטרטגיית שדרוג צמתים, בהתאם למדיניות התחזוקה
בטבלה הבאה מוסבר איך שינויים ידניים כאלה יכולים לשבש סביבת אשכול. הרשימה הזו כוללת, בין היתר, שינויים ידניים שתואמים למדיניות התחזוקה של GKE.
| שינוי | אוטומטית או ידנית | תואם למדיניות התחזוקה | תדירות | סוג השיבוש | רמת השיבוש |
|---|---|---|---|---|---|
| השבתת יציאת ה-kubelet לקריאה בלבד | הופעל ידנית | לא מכבד את מדיניות התחזוקה, ומבצע שינויים באופן מיידי. | פעם אחת לכל שינוי מהסוג הזה. | כל הצמתים באשכול במצב Autopilot כל הצמתים במאגר הצמתים של אשכול סטנדרטי. |
צריך לכבות את הצמתים כדי ליצור אותם מחדש. צריך להחליף את ה-Pods. GKE משתמש באופן מיידי בשדרוגים מצטברים כדי ליצור מחדש את הצמתים, ללא קשר למדיניות תחזוקה פעילה. GKE משתמש בשדרוגים מצטברים גם אם מוגדרת אסטרטגיית שדרוג שונה של צמתים, כמו שדרוגים מסוג blue-green. |
| החלפת פרטי הכניסה של האשכול | אוטומטי אם התוקף של פרטי הכניסה של האשכול יפוג תוך 30 יום, אפשר גם להפעיל אותו באופן ידני. | הוא פועל בהתאם למדיניות התחזוקה. עם זאת, יכול להיות ש-GKE יבטל את מדיניות התחזוקה תוך 30 יום ממועד התפוגה של פרטי הכניסה. במהלך 30 הימים הראשונים, מערכת GKE מתעלמת מהזמינות לתחזוקה בשלב הראשון, שהוא התחלת הרוטציה. בנוסף, אם מפעילים באופן ידני פעולות ספציפיות אחרי השלב הראשון, הפעולה הזו לא תכבד את מדיניות התחזוקה. | פעם אחת לכל שינוי ידני מהסוג הזה, או בהתאם למשך החיים של פרטי הכניסה של האשכול להפעלה אוטומטית. אתם יכולים להפעיל באופן ידני פעולות עבור שלבים ספציפיים בתהליך הרוטציה. | בחלק מהשלבים, מישור הבקרה. בשלבים אחרים, כל הצמתים באשכולות במצב Autopilot, כל הצמתים בכל מאגר צמתים באשכול סטנדרטי. |
כשמתחילים את הסבב ומשלימים אותו, רמת השיבוש היא כזו:
כשהצמתים נוצרים מחדש, רמת השיבוש היא כדלקמן:
|
| החלפת כתובת ה-IP של מישור הבקרה | הופעל ידנית | הכלי פועל בהתאם למדיניות התחזוקה, אבל אם מפעילים ידנית פעולות ספציפיות אחרי השלב הראשון, הפעולה הזו לא פועלת בהתאם למדיניות התחזוקה. | פעם אחת לכל שינוי ידני מסוג זה. אתם יכולים להפעיל באופן ידני פעולות עבור שלבים ספציפיים בתהליך הרוטציה. | חלק מהשלבים, מישור הבקרה. בשלבים אחרים, כל הצמתים באשכולות במצב Autopilot, כל הצמתים בכל מאגר צמתים באשכול סטנדרטי. |
כשמתחילים את הסבב ומשלימים אותו, רמת השיבוש היא כזו:
כשהצמתים נוצרים מחדש, רמת השיבוש היא כדלקמן:
|
| הגדרת צמתים מוגנים | הופעל ידנית |
יצירה מחדש של מישור הבקרה לא מתחשבת במדיניות התחזוקה, והשינויים מתבצעים באופן מיידי. יצירה מחדש של הצמתים מכבדת את כללי המדיניות לתחזוקה. |
פעם אחת לכל שינוי מהסוג הזה |
מישור הבקרה מתעדכן. אחרי שרמת הבקרה מתעדכנת, צריך ליצור מחדש את כל הצמתים בכל מאגר צמתים של אשכול רגיל. |
כשמישור הבקרה נוצר מחדש, רמת השיבוש היא כדלקמן:
כשיוצרים מחדש את הצמתים, רמת השיבוש היא כזו:
|
| הגדרת מדיניות רשת | הופעל ידנית | האם יש ציות למדיניות התחזוקה | פעם אחת לכל שינוי מהסוג הזה | כל הצמתים באשכולות במצב Autopilot, כל הצמתים בכל מאגר צמתים באשכול סטנדרטי. |
צריך להשבית את הצמתים כדי ליצור אותם מחדש, ולהחליף את ה-Pods. GKE משתמש בשדרוגים מצטברים כדי ליצור מחדש את הצמתים. GKE משתמש בשדרוגים מצטברים בלי קשר לשאלה אם מוגדרת אסטרטגיית שדרוג צמתים אחרת, כמו שדרוגים מסוג blue-green. |
| הגדרת הרשאות גישה בתוך הצומת | הופעל ידנית | האם יש ציות למדיניות התחזוקה | פעם אחת לכל שינוי מהסוג הזה | כל הצמתים באשכולות במצב Autopilot, כל הצמתים בכל מאגר צמתים באשכול סטנדרטי. |
צריך להשבית את הצמתים כדי ליצור אותם מחדש, ולהחליף את ה-Pods. GKE משתמש בשדרוגים מצטברים כדי ליצור מחדש את הצמתים. GKE משתמש בשדרוגים מצטברים בלי קשר לשאלה אם מוגדרת אסטרטגיית שדרוג צמתים אחרת, כמו שדרוגים מסוג blue-green. |
| הגדרת NodeLocal DNSCache | הופעל ידנית | האם יש ציות למדיניות התחזוקה | פעם אחת לכל שינוי מהסוג הזה | צריך לעדכן את כל הצמתים במאגר הצמתים של אשכול Standard שעובר עדכון. |
צריך להשבית את הצמתים כדי ליצור אותם מחדש, ולהחליף את ה-Pods. GKE משתמש בשדרוגים מצטברים כדי ליצור מחדש את הצמתים. GKE משתמש בשדרוגים מצטברים בלי קשר לשאלה אם מוגדרת אסטרטגיית שדרוג צמתים אחרת, כמו שדרוגים מסוג blue-green. |
| הפעלת סטרימינג של תמונות | הופעל ידנית |
כשמעדכנים ברמת האשכול, המערכת מתחשבת במדיניות התחזוקה. כשמעדכנים מאגרי צמתים נפרדים, המערכת לא מתחשבת במדיניות התחזוקה. |
פעם אחת לכל שינוי מהסוג הזה |
אם משנים את ההגדרה ברמת מאגר הצמתים, כל הצמתים במאגר הצמתים של אשכול Standard. אם ההגדרה מופעלת או מושבתת ברמת האשכול, היא תחול על צמתים בכל מאגרי הצמתים של אשכול רגיל, שבהם לא הפעלתם או השבתתם את ההגדרה באופן פרטני. |
GKE משתמש בשדרוגים מצטברים כדי ליצור מחדש את הצמתים של מאגר צמתים.GKE משתמש בשדרוגים מצטברים בלי קשר לשאלה אם מוגדרת אסטרטגיית שדרוג צמתים אחרת, כמו שדרוגים כחול-ירוק. |
תחזוקה אוטומטית שלא מתבצעת בהתאם למדיניות התחזוקה
בטבלה הבאה מוסבר איך תחזוקה אוטומטית שלא מתבצעת בהתאם למדיניות התחזוקה עלולה לשבש את סביבת האשכול.
| שינוי | אוטומטית או ידנית | תואם למדיניות התחזוקה | תדירות | סוג השיבוש | רמת השיבוש |
|---|---|---|---|---|---|
| תיקון או שינוי גודל של מישור הבקרה | אוטומטי | לא מכבד את מדיניות התחזוקה |
תדירות התיקון של מישור הבקרה היא אקראית, אבל אין לה השפעה על אשכולות Autopilot ואשכולות סטנדרטיים אזוריים. שינוי הגודל של רמת הבקרה לא מתבצע לעיתים קרובות, אבל התדירות שלו עולה עם אירועי התאמה לעומס (scaling) של האשכול. בנוסף, אין לו השפעה על אשכולות סטנדרטיים אזוריים ועל אשכולות במצב Autopilot. |
מישור הבקרה |
במצב Autopilot ובאשכולות אזוריים רגילים, מישור הבקרה נשאר זמין. במקרה של אשכולות אזוריים מסוג Standard, יכול להיות שלא תהיה אפשרות לתקשר עם מישור הבקרה במשך כמה דקות, כלומר לא תוכלו להגדיר את האשכול, הצמתים ועומסי העבודה במהלך הזמן הזה. |
| אירוע תחזוקה של המארח | אוטומטי | לא מכבד את מדיניות התחזוקה | למידע על התדירות המשוערת, אפשר לעיין במאמר בנושא אירועי תחזוקה. | צומת אחד |
ברוב סוגי הצמתים, ההשפעה מינימלית. יכול להיות שיהיו שיבושים גדולים יותר בחלק מהצמתים, כולל צמתים עם מעבדים גרפיים (GPU) או מעבדי TPU. מידע נוסף זמין במאמר בנושא תחזוקה Cloud de Confiance by S3NS אחרת. |
| תיקון אוטומטי של צמתים | אוטומטי | לא מכבד את מדיניות התחזוקה | תדירות התיקון האוטומטי של הצמתים היא אקראית. |
צומת אחד | הצומת מופעל מחדש, ולכן יש שיבוש בפעולה של כל ה-Pods שפועלים בצומת. |
| החזרת מכונות וירטואליות במודל Spot ומכונות וירטואליות זמניות | אוטומטי | לא מכבד את מדיניות התחזוקה |
למכונות Preemptible VM, לפחות פעם ב-24 שעות. במכונות וירטואליות מסוג Spot, כש-Compute Engine צריך את המשאבים במקום אחר. |
צומת אחד | מידע נוסף זמין במאמרים בנושא הפסקת השימוש במכונות וירטואליות זמניות וכיבוי שלהן והפסקת השימוש במכונות וירטואליות שניתן לקטוע את הפעולה שלהן וכיבוי שלהן. |
| תחזוקה של מסד הנתונים של מצב האשכול שמבוסס על Spanner | אוטומטי | לא מכבד את מדיניות התחזוקה | האירועים הם אקראיים ואין להם השפעה על אשכולות או על עומסי עבודה. | אין. מסד הנתונים שמבוסס על Spanner פועל בנפרד מרמת הבקרה של האשכול ומהצמתים בתשתית של Google. | אין. מסד הנתונים שמבוסס על Spanner משוכפל לכל סוגי האשכולות ונשאר זמין במהלך תחזוקה. |
שינויים ידניים שיוצרים מחדש את הצמתים באמצעות אסטרטגיית שדרוג צמתים בלי להתחשב במדיניות התחזוקה
בטבלה הבאה מוסבר איך שינויים ידניים כאלה יכולים לשבש סביבת אשכול. הרשימה הזו כוללת שינויים שמתרחשים כש-GKE משתמש בשדרוגים של surge וכש-GKE משתמש בשדרוגים של blue-green, שלא נכללים בקטע השני כי הם לא מתבצעים בהתאם למדיניות התחזוקה.
| שינוי | אוטומטית או ידנית | תואם למדיניות התחזוקה | תדירות | סוג השיבוש | רמת השיבוש |
|---|---|---|---|---|---|
| שינויים באיסוף יומנים של מישור הבקרה | הופעל ידנית | לא מתחשב במדיניות התחזוקה, ומבצע את השינויים באופן מיידי. | פעם אחת לכל שינוי מהסוג הזה | מישור הבקרה מתעדכן. | כשמישור הבקרה נוצר מחדש, רמת השיבוש היא כדלקמן:
|
| עדכון התווית של מאגר הצמתים | הופעל ידנית | לא מתחשב במדיניות התחזוקה, ומבצע את השינויים באופן מיידי. | פעם אחת לכל שינוי מהסוג הזה | כל הצמתים במאגר צמתים של אשכול רגיל | מערכת GKE משתמשת מיד בשדרוגים מצטברים כדי ליצור מחדש את מאגר הצמתים כשמעדכנים את תוויות הצמתים במאגר צמתים קיים, ללא קשר למדיניות תחזוקה פעילה. מערכת GKE משתמשת בשדרוגים מצטברים גם אם מוגדרת אסטרטגיית שדרוג צמתים אחרת, כמו שדרוגים מסוג blue-green. |
| הגדלת הקיבולת של הצמתים על ידי שינוי מאפייני המכונה של הצומת | הופעל ידנית | לא מתחשב במדיניות התחזוקה, ומבצע את השינויים באופן מיידי. | פעם אחת לכל שינוי מהסוג הזה | כל הצמתים במאגר צמתים של אשכול רגיל | GKE משתמש באופן מיידי בשדרוגים מצטברים כדי ליצור מחדש את הצמתים במאגר צמתים קיים, ללא קשר למדיניות תחזוקה פעילה. GKE משתמש בשדרוגים מצטברים, גם אם מוגדרת אסטרטגיית שדרוג שונה של צמתים, כמו שדרוגים מסוג blue-green. |
| שינויים בסוג התמונה | הופעל ידנית | לא מתחשב במדיניות התחזוקה, ומבצע את השינויים באופן מיידי. | פעם אחת לכל שינוי מהסוג הזה | כל הצמתים במאגר צמתים של אשכול רגיל |
צריך להשבית את הצמתים כדי ליצור אותם מחדש, ולהחליף את ה-Pods. GKE משתמש באסטרטגיית שדרוג הצמתים שהוגדרה (surge, blue-green או autoscaled blue-green (Preview)) עבור אשכולות Standard. |
| הוספה או החלפה של מאגרי אחסון במאגר צמתים של אשכול רגיל | הופעל ידנית | לא מתחשב במדיניות התחזוקה, ומבצע את השינויים באופן מיידי. | פעם אחת לכל שינוי מהסוג הזה | כל הצמתים במאגר צמתים של אשכול רגיל |
צריך להשבית את הצמתים כדי ליצור אותם מחדש, ולהחליף את ה-Pods. GKE משתמש באסטרטגיית שדרוג הצמתים שהוגדרה (surge, blue-green או autoscaled blue-green (Preview)) עבור אשכולות Standard. |
| הפעלת סטרימינג של תמונות | הופעל ידנית |
כשמעדכנים ברמת האשכול, המערכת מתחשבת במדיניות התחזוקה. כשמעדכנים מאגרי צמתים נפרדים, המערכת לא מתחשבת במדיניות התחזוקה. |
פעם אחת לכל שינוי מהסוג הזה |
אם משנים את ההגדרה ברמת מאגר הצמתים, כל הצמתים במאגר הצמתים של אשכול Standard. אם ההגדרה מופעלת או מושבתת ברמת האשכול, היא תחול על צמתים בכל מאגרי הצמתים של אשכול רגיל, שבהם לא הפעלתם או השבתתם את ההגדרה באופן פרטני. |
GKE משתמש בשדרוגים מצטברים כדי ליצור מחדש את הצמתים של מאגר צמתים. מערכת GKE משתמשת בשדרוגים מצטברים בלי קשר לשאלה אם מוגדרת אסטרטגיית שדרוג צמתים אחרת, כמו שדרוגים כחול-ירוק. |
| עדכוני הגדרות אישיות של ביצועי הרשת | הופעל ידנית | לא מתחשב במדיניות התחזוקה, ומבצע את השינויים באופן מיידי. | פעם אחת לכל שינוי מהסוג הזה | כל הצמתים במאגר צמתים של אשכול רגיל |
צריך להשבית את הצמתים כדי ליצור אותם מחדש, ולהחליף את ה-Pods. GKE משתמש באופן מיידי בשדרוגים מצטברים כדי ליצור מחדש את הצמתים במאגר צמתים קיים, ללא קשר למדיניות תחזוקה פעילה. GKE משתמש בשדרוגים מצטברים גם אם מוגדרת אסטרטגיית שדרוג שונה של צמתים, כמו שדרוגים מסוג blue-green. |
| הפעלת gVNIC | הופעל ידנית | לא מתחשב במדיניות התחזוקה, ומבצע את השינויים באופן מיידי. | פעם אחת לכל שינוי מהסוג הזה | כל הצמתים במאגר צמתים של אשכול רגיל |
צריך להשבית את הצמתים כדי ליצור אותם מחדש, ולהחליף את ה-Pods. GKE משתמש באופן מיידי בשדרוגים מצטברים כדי ליצור מחדש את הצמתים במאגר צמתים קיים, ללא קשר למדיניות תחזוקה פעילה. GKE משתמש בשדרוגים מצטברים גם אם מוגדרת אסטרטגיית שדרוג שונה של צמתים, כמו שדרוגים מסוג blue-green. |
| שינויים בהגדרות המערכת של הצומת | הופעל ידנית | לא מתחשב במדיניות התחזוקה, ומבצע את השינויים באופן מיידי. | פעם אחת לכל שינוי מהסוג הזה | כל הצמתים במאגר צמתים של אשכול רגיל |
צריך להשבית את הצמתים כדי ליצור אותם מחדש, ולהחליף את ה-Pods. GKE משתמש באופן מיידי בשדרוגים מצטברים כדי ליצור מחדש את הצמתים במאגר צמתים קיים, ללא קשר למדיניות תחזוקה פעילה. GKE משתמש בשדרוגים מצטברים גם אם מוגדרת אסטרטגיית שדרוג שונה של צמתים, כמו שדרוגים מסוג blue-green. |
| צמתים סודיים | הופעל ידנית | לא מתחשב במדיניות התחזוקה, ומבצע את השינויים באופן מיידי. | פעם אחת לכל שינוי מהסוג הזה | כל הצמתים במאגר צמתים של אשכול רגיל |
צריך להשבית את הצמתים כדי ליצור אותם מחדש, ולהחליף את ה-Pods. GKE משתמש באופן מיידי בשדרוגים מצטברים כדי ליצור מחדש את הצמתים במאגר צמתים קיים, ללא קשר למדיניות תחזוקה פעילה. GKE משתמש בשדרוגים מצטברים גם אם מוגדרת אסטרטגיית שדרוג שונה של צמתים, כמו שדרוגים מסוג blue-green. |
שינויים שלא מחייבים יצירה מחדש של הצמתים
כדאי לעיין בטבלה הבאה כדי להבין אילו שינויים בהגדרת הצומת לא מחייבים ליצור מחדש את הצמתים. השינויים האלה לא גורמים לשיבושים, אבל עדיין יכולים להיות שיבושים אם הגדרת הצומת המעודכנת משפיעה על עומס העבודה.
| שינוי | אוטומטית או ידנית | תואם למדיניות התחזוקה | תדירות | סוג השיבוש | רמת השיבוש |
|---|---|---|---|---|---|
|
מעדכנים את ההגדרות הבאות:
|
הופעל ידנית | לא מתחשב במדיניות התחזוקה, ומבצע את השינויים באופן מיידי. | פעם אחת לכל שינוי מהסוג הזה | כל הצמתים הרלוונטיים יעודכנו. | אין צורך להחליף את ה-Pods כי הגדרת הצומת מתעדכנת בלי ליצור מחדש את הצמתים. |
המאמרים הבאים
- סקירה כללית של GKE
- ארכיטקטורת אשכול GKE
- אחריות משותפת ב-GKE
- גרסאות ותמיכה ב-GKE
- הסכם רמת שירות (SLA) של GKE
- שדרוגים של אשכולות GKE