בדף הזה מוסבר איך אתם ו-Google Kubernetes Engine (GKE) מנהלים שינויים במהלך מחזור החיים של אשכול כדי למקסם את הביצועים והזמינות ולצמצם את השיבושים בעומסי העבודה.
הדף הזה מיועד לאדמינים של פלטפורמות שרוצים לתכנן ולבצע אופטימיזציה של סביבת האשכולות כדי לצמצם את ההפרעות לעומסי העבודה. אפשר לקרוא את הדף הזה לפני או אחרי שלומדים איך לבצע את משימות הניהול הבסיסיות של אשכולות, כפי שמתואר במאמרים ניהול אשכולות וסקירה כללית על ניהול אשכולות.
פלטפורמה מנוהלת ואחריות משותפת
GKE הוא הטמעה של פלטפורמת Kubernetes בקוד פתוח לתזמור בין קונטיינרים, שמנוהלת על ידי Google. כמו שצוין במאמר איך GKE פועל, אשכול GKE מורכב ממישור בקרה, שכולל צמתים לניהול שבהם פועלים רכיבי מערכת, ומצמתים של עובדים, שבהם פורסים עומסי עבודה.
יצירת סביבת אשכול אופטימלית להרצת עומסי העבודה, עם ביצועים מקסימליים, זמינות גבוהה והפרעה מינימלית, היא אחריות משותפת:
- האחריות של GKE היא לשמור על סביבת אשכולות אמינה, זמינה, מאובטחת ובעלת ביצועים טובים. לשם כך, GKE מנהל את מישור הבקרה, את רכיבי המערכת, ובמצב Autopilot גם את צמתי העובדים.
- האחריות שלכם כאדמינים של הפלטפורמה היא להגדיר את האשכול ולנהל את עומסי העבודה, כולל הכנתם לטיפול בשיבושים. במצב רגיל, אתם גם יוצרים ומנהלים את צמתי העובדים, שמקובצים במאגרי צמתים.
מידע נוסף זמין במאמר בנושא אחריות משותפת ב-GKE.
איך GKE מנהל שינויים במהלך מחזור החיים של אשכול
אשכול GKE הוא הטמעה של Kubernetes, והוא רשת של תהליכים ומערכות שפועלים יחד כדי לשמור על סביבה אופטימלית להרצת עומסי העבודה. כדי לנהל את האשכול, GKE מבצע משימות תחזוקה, משנה הגדרות, מפעיל פעולות, מעדכן רכיבים ומשדרג את הגרסה של מישור הבקרה והצמתים.
רוב הפעולות השוטפות של האפליקציה מתבצעות בשקט ברקע, כדי שעומסי העבודה יפעלו ללא הפרעה. עם זאת, יש שינויים קריטיים שצריך לבצע בדרכים שעלולות לשבש באופן זמני את עומסי העבודה, כפי שמתואר בקטע הבא.
חלק מהשינויים באשכול עלולים לשבש את עומסי העבודה
מערכת GKE פועלת כדי שעומסי העבודה יפעלו בצורה חלקה, אבל שינויים מסוימים שחיוניים לפעולה יכולים לגרום להפרעות זמניות בעומסי העבודה – בעיקר שינויים שמפעילים מחדש את הצמתים שבהם פועלים עומסי העבודה. באמצעות תכונות של GKE ו-Kubernetes, אתם יכולים לציין מתי ואיך אתם רוצים שהשיבוש יתרחש, כך שכשהוא יקרה, עומסי העבודה יוכלו לטפל בשינויים בצורה חלקה.
בקטעים הבאים מוסבר אילו סוגי שינויים מתבצעים באשכולות GKE, איזה סוג של שיבוש הם גורמים ואיך אפשר להתכונן אליהם.
שדרוגים ועדכונים באמצעות ניהול מחזור החיים של אשכולות GKE
ב-GKE, לשדרוגים של אשכולות ולעדכונים של אשכולות יש משמעויות קשורות.
ב-GKE, המונח שדרוגי אשכולות – או פשוט שדרוגים – מתייחס לעדכון של גרסת Kubernetes של מישור הבקרה (שדרוגים של מישור הבקרה) או של הצמתים (שדרוגים של הצמתים), או של שניהם. כשמשתמשים באשכולות Standard, שדרוגי צמתים נקראים גם שדרוגי מאגר צמתים, כי GKE משתמש בפעולה אחת כדי לשדרג מאגר צמתים.
המונח עדכוני אשכולות – או פשוט עדכונים – הוא מונח כללי יותר שמתייחס לכל סוג של שינוי ברמת הבקרה או בצומת, כולל עדכון הגרסאות שלהם. GKE מנהל באופן פעיל את סביבת האשכול על ידי ביצוע שדרוגים, עדכונים מסוגים אחרים ופעולות תחזוקה נדרשות. הפעולות האלה מבטיחות שהאשכול יישאר יעיל, מאובטח ועדכני עם התכונות החדשות ותיקוני הבאגים האחרונים. ב-GKE נעשה שימוש בכלים כמו אסטרטגיות לשדרוג צמתים ומדיניות תחזוקה כדי לצמצם את השיבושים במהלך התהליכים האלה.
תכנון שיבושים בעדכון הצמתים
סוגים מסוימים של שינויים באשכול – בעיקר שינויים בצמתים – עלולים לגרום לשיבוש.
GKE משתמש באסטרטגיות לשדרוג צמתים כדי לעדכן צמתים – צמתים של Autopilot או מאגרי צמתים של אשכול Standard – באופן שמבצע אופטימיזציה לצרכים של עומס העבודה. השיטות האלה רלוונטיות לשדרוגי גרסה וגם לכמה סוגים אחרים של שינויים בצומת. השיטות האלה מאפשרות ל-GKE לצמצם את ההפרעות במהלך עדכוני הצמתים, שחשובים כדי שהאשכולות יתפקדו בצורה תקינה וישיגו ביצועים טובים.
אתם יכולים להשתמש בחלונות זמן לתחזוקה ובאי הכללות כדי לבחור מתי תתבצע תחזוקה של חלק מהאשכולות ומתי לא, ובאשכולות רגילים, אתם יכולים לבחור אסטרטגיית שדרוג של צמתים שהכי מתאימה לפרופיל עומס העבודה ולמגבלות המשאבים שלכם.
גם בשינויים שמתבצעים בצמתים באופן ידני וגם בשינויים שמתבצעים בצמתים באופן אוטומטי, GKE מבצע את השינויים עם המאפיינים הכלליים הבאים:
- השינויים בדרך כלל תואמים למדיניות התחזוקה: כש-GKE מבצע שינויים בצמתים, השינויים האלה בדרך כלל תואמים למדיניות התחזוקה של GKE.
אם אתם מבצעים שינויים ידניים שמחייבים יצירה מחדש של כל הצמתים במאגר הצמתים, כדאי לשים לב לנקודות הבאות:
- במקרה של חלק מהשינויים, מערכת GKE מתחשבת במדיניות התחזוקה ולא מיישמת את השינוי ששלחתם עד שיש זמינות לתחזוקה. אם GKE ממתין לזמינות של תחזוקה, והשינוי דחוף, אפשר להחיל את השינויים באופן ידני כדי להחיל את ההגדרה החדשה באופן מיידי.
- במקרה של שינויים ידניים אחרים, כולל שדרוגים ידניים, GKE לא מתחשב במדיניות התחזוקה. במקרה של שינויים ידניים, חשוב לוודא שעומסי העבודה מוכנים להפרעה מיידית.
- השינויים בדרך כלל מתבצעים באמצעות שיטות לשדרוג צמתים: כש-GKE מבצע שינויים אוטומטיים או שינויים שהופעלו באופן ידני בצמתים – כולל עדכוני צמתים שאינם שדרוגי גרסה – הוא בוחר שיטה לשדרוג צמתים: שדרוגי גל, שדרוגי blue-green או שדרוגי blue-green עם שינוי גודל אוטומטי (גרסת Preview). ב-Autopilot תמיד נעשה שימוש בשדרוגים מצטברים. שינויים במאגרי צמתים של אשכולות רגילים בדרך כלל משתמשים בשדרוגים מצטברים, אלא אם הגדרתם שדרוגים מסוג blue-green או שדרוגים מסוג blue-green עם שינוי גודל אוטומטי וביצעתם סוגים מסוימים של שינויים. מידע נוסף על האסטרטגיה שהוגדרה למאגר צמתים זמין במאמר בדיקת הגדרות השדרוג של מאגר צמתים.
- שינויים דורשים מספיק משאבים: כש-GKE מבצע שינוי באמצעות אסטרטגיית שדרוג של צומת, השינוי הזה דורש כמות מסוימת של משאבים, בהתאם לאסטרטגיה ולתצורה שלה. בפרויקט של האשכול צריך להיות מספיק מכסת משאבים, זמינות משאבים ויכולת שריון (למאגרי צמתים עם שיוך ספציפי של שריון). מידע נוסף זמין במאמר בנושא הקצאת משאבים לשדרוג צמתים.
רשימה מפורטת של שינויים ספציפיים והמאפיינים שלהם מופיעה בקטע סוגי שינויים באשכול GKE בדף הזה.
הכנה לשינויים משמעותיים כדי למקסם את הזמינות של עומסי העבודה
כדי למקסם את הזמינות של עומסי העבודה שפועלים באשכול GKE, מומלץ לבצע את הפעולות שמתוארות בקטעים הבאים:
בחירת הזמינות של האשכול
אם זמינות מישור הבקרה היא בראש סדר העדיפויות, כדאי לבחור באשכול Autopilot או באשכול אזורי רגיל, ולא באשכול אזורי רגיל. מידע נוסף זמין במאמר אפשרויות להגדרת אשכול.
שליטה בשדרוגים באמצעות כלי GKE
אתם יכולים להשתמש בכלים הבאים כדי לקבוע מתי ואיך GKE ישדרג את האשכול, וכך תוכלו ליישם את שיטות העבודה המומלצות:
- ערוצי הפצה: בוחרים ערוץ הפצה כדי לקבל גרסאות של אשכולות עם איזון בין זמינות התכונות ליציבות, לפי הבחירה שלכם.
- חלונות זמן לתחזוקה: מציינים חלון זמן חוזר שבו יכולה להתבצע תחזוקה מסוגים מסוימים של אשכולות GKE, כמו שדרוגים.
- החרגות מתחזוקה: מונעות את התחזוקה של האשכול למשך תקופה מסוימת.
- תקציבים להפרעות באשכולות: אפשר להתאים אישית את מרווח הזמן המינימלי בין סוגים ספציפיים של שדרוגי אשכולות, כולל שדרוגי תיקון או שדרוגים משניים.
- אסטרטגיות לשדרוג צמתים: אם משתמשים במאגרי צמתים רגילים, בוחרים איך הצמתים ישודרגו – שדרוג מהיר, שדרוג כחול-ירוק או שדרוג כחול-ירוק עם שינוי גודל אוטומטי (גרסת Preview) – כדי למזער את ההפרעה לעומסי העבודה.
- רצף ההשקה: הגדרת שדרוגים בסביבת טרום-ייצור לפני ש-GKE ישדרג את אשכולות הייצור.
- שדרוגים ידניים: שדרוג ידני של האשכול, וביצוע פעולות כמו ביטול, חידוש, חזרה לגרסה קודמת והשלמה של שדרוגים אוטומטיים או ידניים שנמצאים בתהליך.
ניהול האשכול ומעקב אחריו
כדי לנהל שיבושים פוטנציאליים באשכולות, צריך לבצע באופן רציף את המשימות הבאות:
- אפשר לעקוב אחרי האשכול באמצעות חבילת כלי התצפית של GKE.
- כדאי לעקוב אחרי הערות לגבי מהדורות GKE כדי לקבל הודעות.
- אפשר לראות התראות על אשכולות, למשל מתי מתחילים או מסיימים שדרוגים, מתי גרסאות חדשות זמינות, עלוני אבטחה ותאריכי סיום התמיכה.
- קבלת תמונה ברורה יותר של שדרוגי האשכולות כדי להבין את מצב השדרוגים של האשכולות.
- כדי לקבל הערכה אופטימית לגבי הזמן שבו גרסאות משניות יהיו זמינות לשדרוג, ועד מתי הן יקבלו תמיכה, אפשר לעיין בלוח הזמנים של מהדורות GKE.
- ההמלצות המפורטות מזהות הזדמנויות פוטנציאליות לאופטימיזציה ומסבירות איך לבצע אופטימיזציה של השימוש באשכול, כולל הנחיות לגבי הוצאה משימוש של תכונות ו-API.
הכנת עומסי העבודה
כדי לצמצם את ההפרעות, כדאי להפוך את עומסי העבודה לעמידים ככל האפשר בפני הפרעות:
- מריצים רפליקות של עומסי העבודה כדי להבטיח יתירות ולהימנע מנקודת כשל בודדת.
- מגדירים תקציב לשיבוש עבור האפליקציה באמצעות תקציב לשיבוש Pod.
- מגדירים תקופת חסד לסיום באורך המתאים לעומס העבודה, כדי שהכיבוי יתבצע בצורה חלקה.
- אם עומס העבודה שלכם משתמש במעבדי GPU או TPU, אתם צריכים לפעול לפי ההוראות לניהול שיבושים בצמתי GKE עבור מעבדי GPU ו-TPU.
- עבור אפליקציות עם שמירת מצב, שלעתים קרובות צריכות זמן כדי להפסיק את פעולות הקלט/פלט בצורה נקייה ולבטל את הקישור שלהן לאחסון, פועלים לפי השלבים במאמר איך מוודאים שעומסי עבודה עם שמירת מצב מוכנים להפרעות.
לדיון כללי בנושאים האלה, אפשר לעיין בקטע ניהול שיבושים בפוסט בבלוג שיטות מומלצות ל-GKE: פעולות ביום 2 להמשכיות עסקית.
סוגי השינויים באשכול GKE
בטבלאות הבאות מוצגים הסוגים הנפוצים ביותר של שינויים משמעותיים באשכול, כולל מאפיינים של השינויים האלה כמו תדירות ורמת השיבוש.
סוגי שדרוגים
בטבלה הבאה מוסבר איך שדרוגים יכולים לשבש סביבת אשכול.
| שינוי | אוטומטית או ידנית | התאמה למדיניות התחזוקה | תדירות | סוג השיבוש | רמת השיבוש |
|---|---|---|---|---|---|
| שדרוג מישור הבקרה | אוטומטי או ידני |
השדרוגים האוטומטיים מתבצעים בהתאם למדיניות התחזוקה עד לסיום התמיכה, למעט תיקוני חירום נדירים ביותר, לפי הצורך. כללי מדיניות תחזוקה לא חוסמים שדרוגים ידניים. |
שדרוגי תיקון, בתדירות של פעם בשבוע, בהתאם לערוץ ההפצה. שדרוגים קלים בערך כל ארבעה חודשים. במקרים של אשכולות ערוצים מורחבים, שדרוגים משניים מתבצעים רק כשגרסה משנית מתקרבת לסוף תקופת התמיכה. |
מישור הבקרה |
במקרים של Autopilot ואשכולות אזוריים רגילים, מישור הבקרה נשאר זמין. לגבי אשכולות אזוריים מסוג Standard, יכול להיות שלא תהיה אפשרות לתקשר עם מישור הבקרה במשך כמה דקות, כלומר לא תוכלו להגדיר את האשכול, הצמתים ועומסי העבודה במהלך הזמן הזה. |
| שדרוג צומת | אוטומטי או ידני |
השדרוגים האוטומטיים מתבצעים בהתאם למדיניות התחזוקה עד לסיום התמיכה, למעט תיקוני חירום נדירים ביותר, לפי הצורך. כללי מדיניות תחזוקה לא חוסמים שדרוגים ידניים. |
בדרך כלל, השדרוג זהה לשדרוג של רמת הבקרה. אם האשכול שלכם לא רשום בערוץ הפצה והשבתתם את השדרוגים האוטומטיים של הצמתים, אתם אחראים לשדרוג ידני של מאגרי הצמתים באשכול. |
כל הצמתים באשכולות במצב Autopilot, או מאגר צמתים אחד או יותר באשכולות סטנדרטיים. |
צריך להשבית את הצמתים כדי ליצור אותם מחדש, וצריך להחליף את ה-Pods. ב-GKE נעשה שימוש בעדכוני גל לעדכוני Autopilot, או בשיטת העדכון של הצמתים שהוגדרה (גל, כחול-ירוק או כחול-ירוק עם שינוי גודל אוטומטי (גרסת 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 משתמש בשדרוגים מצטברים גם אם מוגדרת אסטרטגיית שדרוג שונה של צמתים, כמו שדרוגים מסוג blue-green. |
תחזוקה אוטומטית שלא מתבצעת בהתאם למדיניות התחזוקה
בטבלה הבאה מוסבר איך תחזוקה אוטומטית שלא מתבצעת בהתאם לכללי מדיניות התחזוקה עלולה לשבש את סביבת האשכול.
| שינוי | אוטומטית או ידנית | התאמה למדיניות התחזוקה | תדירות | סוג השיבוש | רמת השיבוש |
|---|---|---|---|---|---|
| תיקון או שינוי גודל של מישור הבקרה | אוטומטי | לא מכבד את מדיניות התחזוקה |
תדירות התיקון של מישור הבקרה היא אקראית, אבל אין לה השפעה על אשכולות Autopilot ואשכולות אזוריים רגילים. שינוי הגודל של מישור הבקרה לא מתבצע לעיתים קרובות, אבל התדירות שלו עולה עם אירועי שינוי גודל של האשכול. בנוסף, אין לו השפעה על אשכולות Autopilot ואשכולות אזוריים רגילים. |
מישור הבקרה |
במקרים של Autopilot ואשכולות אזוריים רגילים, מישור הבקרה נשאר זמין. לגבי אשכולות אזוריים מסוג Standard, יכול להיות שלא תהיה אפשרות לתקשר עם מישור הבקרה במשך כמה דקות, כלומר לא תוכלו להגדיר את האשכול, הצמתים ועומסי העבודה במהלך הזמן הזה. |
| אירוע תחזוקה של המארח | אוטומטי | לא מכבד את מדיניות התחזוקה | למידע על התדירות המשוערת, אפשר לעיין במאמר בנושא אירועי תחזוקה. | צומת אחד |
ברוב סוגי הצמתים, ההשפעה מינימלית. יכול להיות שיהיו שיבושים גדולים יותר בחלק מהצמתים, כולל צמתים עם מעבדים גרפיים (GPU) או מעבדי TPU. מידע נוסף זמין במאמר בנושא תחזוקה Google Cloud אחרת. |
| תיקון אוטומטי של צמתים | אוטומטי | לא מכבד את מדיניות התחזוקה | תדירות התיקון האוטומטי של הצמתים היא אקראית. |
צומת אחד | הצומת מופעל מחדש, ולכן יש שיבוש בפעולה של כל ה-Pods שפועלים בצומת. |
| החזרת מכונות וירטואליות במודל Spot ומכונות וירטואליות זמניות | אוטומטי | לא מכבד את מדיניות התחזוקה |
למכונות Preemptible VM, לפחות פעם ב-24 שעות. במכונות וירטואליות מסוג Spot, כש-Compute Engine צריך את המשאבים במקום אחר. |
צומת אחד | מידע נוסף זמין במאמרים בנושא הפסקת השימוש במכונות וירטואליות מסוג Spot וכיבוי שלהן בצורה מסודרת והפסקת השימוש במכונות וירטואליות זמניות וכיבוי שלהן בצורה מסודרת. |
| תחזוקה של מסד הנתונים של מצב האשכול שמבוסס על Spanner | אוטומטי | לא מכבד את מדיניות התחזוקה | האירועים הם אקראיים ואין להם השפעה על אשכולות או על עומסי עבודה. | אין. מסד הנתונים שמבוסס על Spanner פועל בנפרד מרמת הבקרה של האשכול ומהצמתים בתשתית של Google. | אין. מסד הנתונים שמבוסס על Spanner משוכפל לכל סוגי האשכולות ונשאר זמין במהלך תחזוקה. |
שינויים ידניים שיוצרים מחדש את הצמתים באמצעות אסטרטגיית שדרוג צמתים בלי להתחשב במדיניות התחזוקה
בטבלה הבאה מוסבר איך שינויים ידניים כאלה יכולים לשבש את סביבת האשכול. הרשימה הזו כוללת שינויים שמתרחשים כש-GKE משתמש בשדרוגים של surge וכש-GKE משתמש בשדרוגים של blue-green, שלא נכללים בקטע השני כי הם לא מתבצעים בהתאם למדיניות התחזוקה.
| שינוי | אוטומטית או ידנית | התאמה למדיניות התחזוקה | תדירות | סוג השיבוש | רמת השיבוש |
|---|---|---|---|---|---|
| שינויים באיסוף יומנים של מישור הבקרה | הופעל ידנית | לא מתחשב במדיניות התחזוקה, ומבצע את השינויים באופן מיידי. | פעם אחת לכל שינוי מהסוג הזה | מישור הבקרה מתעדכן. | כשמישור הבקרה נוצר מחדש, רמת השיבוש היא כדלקמן:
|
| עדכון התווית של מאגר הצמתים | הופעל ידנית | לא מתחשב במדיניות התחזוקה, ומבצע את השינויים באופן מיידי. | פעם אחת לכל שינוי מהסוג הזה | כל הצמתים במאגר צמתים של אשכול Standard | מערכת GKE משתמשת מיד בשדרוגים מצטברים כדי ליצור מחדש את מאגר הצמתים כשמעדכנים את תוויות הצמתים במאגר צמתים קיים, בלי קשר למדיניות תחזוקה פעילה. GKE משתמש בשדרוגים מצטברים גם אם מוגדרת אסטרטגיית שדרוג שונה של צמתים, כמו שדרוגים מסוג blue-green. |
| הגדלת הקיבולת של הצמתים על ידי שינוי מאפייני המכונה של הצומת | הופעל ידנית | לא מתחשב במדיניות התחזוקה, ומבצע את השינויים באופן מיידי. | פעם אחת לכל שינוי מהסוג הזה | כל הצמתים במאגר צמתים של אשכול Standard | GKE משתמש באופן מיידי בשדרוגים מצטברים כדי ליצור מחדש את הצמתים במאגר צמתים קיים, ללא קשר למדיניות תחזוקה פעילה. GKE משתמש בשדרוגים מצטברים, בלי קשר לשאלה אם מוגדרת אסטרטגיית שדרוג שונה של צמתים, כמו שדרוגים מסוג blue-green. |
| שינויים בסוג התמונה | הופעל ידנית | לא מתחשב במדיניות התחזוקה, ומבצע את השינויים באופן מיידי. | פעם אחת לכל שינוי מהסוג הזה | כל הצמתים במאגר צמתים של אשכול Standard |
צריך להשבית את הצמתים כדי ליצור אותם מחדש, וצריך להחליף את ה-Pods. GKE משתמש בשיטת השדרוג של הצמתים שהוגדרה (surge, blue-green או autoscaled blue-green (גרסת Preview)) באשכולות Standard. |
| הוספה או החלפה של מאגרי אחסון במאגר צמתים של אשכול רגיל | הופעל ידנית | לא מתחשב במדיניות התחזוקה, ומבצע את השינויים באופן מיידי. | פעם אחת לכל שינוי מהסוג הזה | כל הצמתים במאגר צמתים של אשכול Standard |
צריך להשבית את הצמתים כדי ליצור אותם מחדש, וצריך להחליף את ה-Pods. GKE משתמש בשיטת השדרוג של הצמתים שהוגדרה (surge, blue-green או autoscaled blue-green (גרסת Preview)) באשכולות Standard. |
| הפעלת סטרימינג של תמונות | הופעל ידנית |
כשמעדכנים ברמת האשכול, המערכת מתחשבת במדיניות התחזוקה. כשמעדכנים מאגרי צמתים נפרדים, המערכת לא מתחשבת במדיניות התחזוקה. |
פעם אחת לכל שינוי מהסוג הזה |
אם משנים את ההגדרה ברמת מאגר הצמתים, כל הצמתים במאגר הצמתים של אשכול Standard. אם ההגדרה מופעלת ברמת האשכול, הצמתים של כל מאגרי הצמתים של אשכולות רגילים שבהם לא הפעלתם או השבתתם את ההגדרה באופן פרטני עבור מאגר הצמתים. |
GKE משתמש בשדרוגים מדורגים כדי ליצור מחדש את הצמתים של מאגר צמתים. GKE משתמש בשדרוגים מצטברים גם אם מוגדרת אסטרטגיית שדרוג שונה של צמתים, כמו שדרוגים מסוג blue-green. |
| עדכוני הגדרות אישיות של ביצועי הרשת | הופעל ידנית | לא מתחשב במדיניות התחזוקה, ומבצע את השינויים באופן מיידי. | פעם אחת לכל שינוי מהסוג הזה | כל הצמתים במאגר צמתים של אשכול Standard |
צריך להשבית את הצמתים כדי ליצור אותם מחדש, וצריך להחליף את ה-Pods. GKE משתמש באופן מיידי בשדרוגים מצטברים כדי ליצור מחדש את הצמתים במאגר צמתים קיים, ללא קשר למדיניות תחזוקה פעילה. GKE משתמש בשדרוגים מצטברים גם אם מוגדרת אסטרטגיית שדרוג שונה של צמתים, כמו שדרוגים מסוג blue-green. |
| הפעלת gVNIC | הופעל ידנית | לא מתחשב במדיניות התחזוקה, ומבצע את השינויים באופן מיידי. | פעם אחת לכל שינוי מהסוג הזה | כל הצמתים במאגר צמתים של אשכול Standard |
צריך להשבית את הצמתים כדי ליצור אותם מחדש, וצריך להחליף את ה-Pods. GKE משתמש באופן מיידי בשדרוגים מצטברים כדי ליצור מחדש את הצמתים במאגר צמתים קיים, ללא קשר למדיניות תחזוקה פעילה. GKE משתמש בשדרוגים מצטברים גם אם מוגדרת אסטרטגיית שדרוג שונה של צמתים, כמו שדרוגים מסוג blue-green. |
| שינויים בהגדרות המערכת של הצומת | הופעל ידנית | לא מתחשב במדיניות התחזוקה, ומבצע את השינויים באופן מיידי. | פעם אחת לכל שינוי מהסוג הזה | כל הצמתים במאגר צמתים של אשכול Standard |
צריך להשבית את הצמתים כדי ליצור אותם מחדש, וצריך להחליף את ה-Pods. GKE משתמש באופן מיידי בשדרוגים מצטברים כדי ליצור מחדש את הצמתים במאגר צמתים קיים, ללא קשר למדיניות תחזוקה פעילה. GKE משתמש בשדרוגים מצטברים גם אם מוגדרת אסטרטגיית שדרוג שונה של צמתים, כמו שדרוגים מסוג blue-green. |
| צמתים סודיים | הופעל ידנית | לא מתחשב במדיניות התחזוקה, ומבצע את השינויים באופן מיידי. | פעם אחת לכל שינוי מהסוג הזה | כל הצמתים במאגר צמתים של אשכול Standard |
צריך להשבית את הצמתים כדי ליצור אותם מחדש, וצריך להחליף את ה-Pods. GKE משתמש באופן מיידי בשדרוגים מצטברים כדי ליצור מחדש את הצמתים במאגר צמתים קיים, ללא קשר למדיניות תחזוקה פעילה. GKE משתמש בשדרוגים מצטברים גם אם מוגדרת אסטרטגיית שדרוג שונה של צמתים, כמו שדרוגים מסוג blue-green. |
שינויים שלא מחייבים ליצור מחדש את הצמתים
כדאי לעיין בטבלה הבאה כדי להבין אילו שינויים בהגדרת הצומת לא מחייבים ליצור מחדש את הצמתים. השינויים האלה לא גורמים לשיבושים, אבל עדיין יכולים להיות שיבושים אם הגדרות הצומת המעודכנות משפיעות על עומס העבודה.
| שינוי | אוטומטית או ידנית | התאמה למדיניות התחזוקה | תדירות | סוג השיבוש | רמת השיבוש |
|---|---|---|---|---|---|
|
מעדכנים את ההגדרות הבאות:
|
הופעל ידנית | לא מתחשב במדיניות התחזוקה, ומבצע את השינויים באופן מיידי. | פעם אחת לכל שינוי מהסוג הזה | כל הצמתים הרלוונטיים מתעדכנים. | אין צורך להחליף את ה-Pods כי הגדרת הצומת מתעדכנת בלי ליצור מחדש את הצמתים. |
המאמרים הבאים
- סקירה כללית של GKE
- ארכיטקטורת אשכול GKE
- אחריות משותפת ב-GKE
- גרסאות ותמיכה ב-GKE
- הסכם רמת שירות (SLA) של GKE
- שדרוגים של אשכולות GKE