שדרוגים רגילים של אשכולות

במאמר הזה מוסבר איך פועלים שדרוגים אוטומטיים וידניים באשכולות Standard של Google Kubernetes Engine ‏ (GKE), כולל קישורים למידע נוסף על משימות והגדרות קשורות. אתם יכולים להשתמש במידע הזה כדי לעדכן את האשכולות שלכם, לשמור על היציבות והאבטחה שלהם ולצמצם את ההפרעות לעומסי העבודה.

לסקירה כללית על שדרוגי אשכולות, קראו את המאמר מידע על שדרוגי אשכולות ב-GKE. במאמר שדרוגים של אשכולות Autopilot מוסבר איך פועלים שדרוגים של אשכולות Autopilot.

איך פועלים השדרוגים של מישור הבקרה ושל מאגר הצמתים

בקטע הזה מוסבר מה קורה באשכול במהלך שדרוגים אוטומטיים או ידניים. בשדרוגים אוטומטיים, GKE מתחיל את השדרוג האוטומטי. ‫GKE עוקב אחרי שדרוגים אוטומטיים וידניים בכל אשכולות GKE, ומתערב אם מתגלות בעיות.

כדי לשדרג אשכול, GKE מעדכן את הגרסה שפועלת במישור הבקרה ובצמתים. האשכולות משודרגים לגרסה משנית חדשה יותר (לדוגמה, מ-1.24 ל-1.25) או לגרסת תיקון חדשה יותר (לדוגמה, מ-‎1.24.2-gke.100 ל-‎1.24.5-gke.200). מידע נוסף זמין במאמר ניהול גרסאות ותמיכה ב-GKE.

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

שדרוגים של מישור הבקרה

בקטע הזה מוסבר מה קורה כש-GKE משדרג אוטומטית את מישור הבקרה או כשאתם מפעילים שדרוג ידני.

הזמינות של אשכול GKE במהלך שדרוגים של מישור הבקרה תלויה בסוג האשכול הרגיל שאתם מריצים:

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

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

אם מגדירים חלון זמן לתחזוקה או החרגה, חלון הזמן לתחזוקה או ההחרגה יכובדו בשדרוגים אוטומטיים, אם הדבר אפשרי.

שיטות לשדרוג מישור הבקרה

ב-GKE משתמשים בשיטות הבאות כשמשדרגים את מישור הבקרה:

  • שדרוגים אוטומטיים: GKE מבצע שדרוגים אוטומטיים באמצעות השיטות הבאות, בהתאם לסוג השדרוג:

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

  • שדרוגים ידניים: אתם יכולים לשדרג את מישור הבקרה של האשכול בהתאם לסוג השדרוג:

    • שדרוגים של גרסאות תיקון: אפשר להשתמש בשדרוג בשלב אחד.
    • שדרוגים של גרסאות משניות: אפשר להשתמש בשדרוג בשלב אחד או בשדרוג בשני שלבים.

שדרוגים של מאגרי צמתים

בקטע הזה מוסבר מה קורה כש-GKE משדרג אוטומטית את מאגר הצמתים, או כשאתם משדרגים אותו ידנית. המידע הזה רלוונטי גם למאגרי צמתים רגילים וגם למאגרי צמתים בניהול Autopilot.

כברירת מחדל, GKE משדרג באופן אוטומטי מאגר צמתים אחד בכל פעם באשכול. כדי לקצר את זמן השדרוג הכולל של אשכולות עם כמה מאגרי צמתים, אתם יכולים להגדיר שדרוגים בו-זמניים של מאגרי צמתים (גרסת טרום-השקה (Preview)), וכך GKE ישדרג באופן אוטומטי כמה מאגרי צמתים בו-זמנית. לחלופין, אתם יכולים לשדרג ידנית כמה מאגרי צמתים במקביל. כברירת מחדל, הצמתים במאגר הצמתים משודרגים אחד אחרי השני בסדר אקראי. במאגר צמתים שפרוס על פני כמה אזורים, השדרוגים מתבצעים אזור אחר אזור. בתוך אזור, הצמתים ישודרגו בסדר לא מוגדר.

כשמשדרגים מאגרי צמתים ב-GKE Standard, אפשר לבחור בין האסטרטגיות הבאות לשדרוג צמתים:

  • שדרוגי מתח
  • שדרוגים כחול-ירוק (blue-green upgrades)
  • שדרוגים כחולים-ירוקים עם התאמה אוטומטית לעומס (גרסת טרום-השקה (Preview))

בכל אחת מהאסטרטגיות האלה לשדרוג צמתים, אתם יכולים להתאים את תהליך השדרוג לפי הצרכים של סביבת האשכול. במאגרי צמתים שמנוהלים על ידי Autopilot באשכולות רגילים, תמיד משתמשים בשדרוגים מתפרצים, ואי אפשר לשנות את ההגדרות של האסטרטגיה או את ההגדרות שלה.

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

שדרוגים משבשים למאגרי צמתים שמשתמשים במאיצים ומריצים עומסי עבודה של AI/ML

במכונות של Compute Engine עם מאיצים (GPU או TPU) אין תמיכה במיגרציה פעילה, ולכן Compute Engine צריך להשבית את הצמתים וליצור אותם מחדש במהלך התחזוקה של המארח. התהליך הזה יכול לשבש עומסי עבודה כמו אימון AI או למידת מכונה, או משימות הסקה. כדי לצמצם את ההפרעות, מומלץ לבצע את תחזוקת המארח של Compute Engine ואת שדרוגי הצמתים של GKE בו-זמנית. מידע נוסף זמין במאמר ביצוע תחזוקה של מארח לצמתים שמריצים עומסי עבודה של אימון והסקה.

איך משדרגים צמתים

במהלך שדרוג של מאגר צמתים, אופן השדרוג של הצמתים תלוי באסטרטגיית השדרוג של מאגר הצמתים ובאופן ההגדרה שלה, אם אפשר. עם זאת, השלבים הבסיסיים נשארים זהים. כדי לשדרג צומת, GKE מסיר פודים מהצומת כדי שיהיה אפשר לשדרג אותו.

כשמשדרגים צומת, זה מה שקורה לפודים:

  1. הצומת מבודד כדי ש-Kubernetes לא יתזמן בו קבוצות Pod חדשות.
  2. לאחר מכן הצומת מרוקן, כלומר ה-Pods מוסרים. בשדרוגים עם הגדלת נפח, GKE מכבד את ההגדרות PodDisruptionBudget ו-GracefulTerminationPeriod של ה-Pod למשך עד שעה. בשדרוגים כחול-ירוק, אפשר להאריך את משך הזמן הזה אם מגדירים זמן השהיה ארוך יותר.

  3. מישור הבקרה מתזמן מחדש פודים שמנוהלים על ידי בקרים לצמתים אחרים. פודים שלא ניתן לתזמן מחדש נשארים בשלב Pending עד שניתן לתזמן אותם מחדש.

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

שיקולים שמשפיעים על משך השדרוג של הצומת

הגדרות שיכולות לגרום לשדרוג הצומת להימשך זמן רב יותר כוללות:

אסטרטגיות לשדרוג צמתים

ב-GKE יש אסטרטגיות מובנות שאפשר להגדיר, שקובעות איך לשדרג את מאגר הצמתים. למידע נוסף על סוגי השינויים שמשתמשים באסטרטגיית שדרוג צמתים, ראו:

שדרוגי מתח

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

שדרוגים כחול-ירוק (blue-green upgrades)

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

למידע נוסף על אופן הפעולה של אסטרטגיות השדרוג של הצמתים, ראו אסטרטגיות לשדרוג צמתים.

שדרוגים כחול-ירוק עם התאמה אוטומטית לעומס (autoscaling)

שדרוגים כחולים-ירוקים עם התאמה אוטומטית לעומס (גרסת טרום-השקה (Preview)) הם אסטרטגיית שדרוג של צמתים שבה עומסי העבודה יכולים לפעול למשך זמן ארוך יותר, תוך צמצום העלות מצמתים לא פעילים או מצמתים שלא מנוצלים מספיק.

המשאבים הנדרשים לאסטרטגיות שדרוג של צמתים

בשדרוגים מסוג "מתח" נוצרים צמתים נוספים אם הערך של maxSurge גדול מ-0, ובשדרוגים מסוג "כחול-ירוק" מספר הצמתים במאגר מוכפל באופן זמני. לשם כך נדרשים משאבים נוספים, בכפוף ל מכסה של Compute Engine, לזמינות המשאבים ולקיבולת ההזמנה. אם במאגר הצמתים אין מספיק משאבים, השדרוגים עלולים להימשך זמן רב יותר או להיכשל.

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

שדרוג אוטומטי

כשיוצרים אשכול רגיל, השדרוג האוטומטי מופעל כברירת מחדל באשכול ובמאגרי הצמתים שלו.

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

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

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

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

איך נבחרות הגרסאות לשדרוג אוטומטי

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

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

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

בגרסה משנית (כמו v1.14.x), אפשר לשדרג את האשכולות באופן אוטומטי לגרסת תיקון חדשה.

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

גורמים שמשפיעים על תזמון ההשקה של גרסאות

כדי להבטיח את היציבות והאמינות של אשכולות בגרסאות חדשות, GKE פועל לפי שיטות מסוימות במהלך השקת גרסאות.

השיטות האלה כוללות, בין היתר:

  • ‫GKE משיק בהדרגה שינויים באזורים Google Cloudובתחומים.
  • ב-GKE, גרסאות התיקונים מושקות בהדרגה בערוצי ההפצה. תיקון מקבל זמן טבילה בערוץ ההפצה המהיר, ואז בערוץ ההפצה הרגיל, לפני שהוא מקודם לערוץ ההפצה היציב אחרי שהוא צבר שימוש והמשיך להפגין יציבות. אם נמצאה בעיה בגרסת תיקון במהלך תקופת ההרצה בערוץ הפצה, הגרסה הזו לא מקודמת לערוץ הבא והבעיה מתוקנת בגרסת תיקון חדשה יותר.
  • ‫GKE משיק בהדרגה גרסאות משניות, בתהליך הרצה דומה לגרסאות תיקון. לגרסאות משניות יש תקופות הרצה ארוכות יותר, כי הן כוללות שינויים משמעותיים יותר.
  • יכול להיות ש-GKE יעכב את השדרוגים האוטומטיים כשגרסה חדשה משפיעה על קבוצת אשכולות. לדוגמה, GKE משהה שדרוגים אוטומטיים לאשכולות שהוא מזהה שחשופים ל-API או לתכונה שהוצאו משימוש ויוסרו בגרסה המשנית הבאה.
  • יכול להיות ש-GKE יעכב את ההשקה של גרסאות חדשות בזמני שיא (לדוגמה, חגים גדולים) כדי להבטיח את המשכיות העסק.

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

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

שדרוג ידני

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

כשמשדרגים אשכול באופן ידני, הזמינות שלו תלויה בסוג האשכול (אזורי או לא):

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

  • באשכולות אזוריים, רפליקה אחת של מישור הבקרה לא זמינה בזמן השדרוג, אבל האשכול נשאר זמין במהלך השדרוג.

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

איך GKE מגיב לכשל בשדרוג האוטומטי

שדרוגים אוטומטיים של מאגרי צמתים יכולים להיכשל בגלל בעיות במכונות הבסיסיות של Compute Engine, או בגלל בעיות ב-Kubernetes. לדוגמה, השדרוגים האוטומטיים נכשלים במצבים הבאים:

  • ההגדרה של maxSurge חורגת ממכסת המשאבים של Compute Engine.
  • צומתי ה-surge החדשים לא נרשמו במישור הבקרה של האשכול.
  • הניקוז או המחיקה של הצמתים נמשכו יותר מדי זמן.

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

אם שדרוגי הצמתים נכשלים כי הבקשות לצומתי ה-surge חורגות מהמכסה של Compute Engine, ‏ GKE מפחית את מספר צומתי ה-surge בו-זמנית כדי לנסות לעמוד במכסה ולהמשיך בשדרוג.

קבלת התראות על שדרוג

‫GKE מפרסם ב-Pub/Sub התראות על אירועים שרלוונטיים לאשכול שלכם, כמו שדרוגי גרסאות ועדכוני אבטחה דחופים, ומספק לכם ערוץ לקבלת מידע מ-GKE על האשכולות שלכם.

מידע נוסף זמין במאמר קבלת התראות לגבי אשכולות.

בדיקת יומני השדרוג

כברירת מחדל, GKE מתעד ב-Cloud Logging אירועים של שדרוג מישור הבקרה ומאגר הצמתים. יומן האירועים של השדרוג מספק מידע על תהליך השדרוג, וכולל מידע חשוב לפתרון בעיות במקרה הצורך.

יומני שדרוג של מישור הבקרה

אפשר לשלוח שאילתות לגבי אירועי שדרוג של אשכולות באמצעות המסנן הבא:

resource.type="gke_cluster"
protoPayload.metadata.operationType=~"(UPDATE_CLUSTER|UPGRADE_MASTER)"
resource.labels.cluster_name="CLUSTER_NAME"

היומנים האלה מתועדים בפורמטים של רישום מובנה ביומן. אפשר להשתמש בשדות הבאים כדי לקבל פרטים על אירועי השדרוג:

שדה תיאור
protoPayload.metadata.operationType

יש שני סוגים של אירועי שדרוג אשכולות:

  • ‫UPGRADE_MASTER: שדרוג לגרסה של מישור הבקרה של Kubernetes.
  • ‫UPDATE_CLUSTER: עדכון שלא משנה את הגרסה של מישור הבקרה של Kubernetes.

שני סוגי השדרוגים של האשכולות יכולים לגרום לאובדן הזמינות של מישור הבקרה באשכולות אזוריים. מידע נוסף זמין במאמר איך פועלים השדרוגים של אשכולות ומאגרי צמתים.
protoPayload.methodName

בשדה הזה מוצג ה-API שהפעיל את שדרוג האשכול.
protoPayload.metadata.previousMasterVersion השדה הזה משמש רק לסוג הפעולה MASTER_UPGRADE, והוא מכיל את הגרסה הקודמת של מישור הבקרה שבה השתמשו לפני השדרוג.
protoPayload.metadata.currentMasterVersion השדה הזה משמש רק לסוג הפעולה MASTER_UPGRADE, והוא מכיל את מספר הגרסה החדש של מישור הבקרה שמשמש אחרי השדרוג.

יומני שדרוג של מאגר צמתים

כדי לראות אירועים של שדרוג מאגר צמתים, משתמשים בשאילתה הבאה: 

resource.type="gke_nodepool"
protoPayload.metadata.operationType="UPGRADE_NODES"
resource.labels.cluster_name="CLUSTER_NAME"

בשדה הבא מופיעים פרטים על אירוע השדרוג:

בשדה protoPayload.methodName מוצג אם השדרוג הופעל באופן ידני או אוטומטי, באופן הבא.

שדרוג רכיבים

ב-GKE, עומסי עבודה של המערכת פועלים בצומתי עובדים כדי לתמוך ביכולות ספציפיות של אשכולות. לדוגמה, עומס העבודה של המערכת gke-metadata-server תומך באיחוד זהויות של עומסי עבודה ל-GKE. ‫GKE אחראי לתקינות של עומסי העבודה האלה. כדי לקבל מידע נוסף על הרכיבים האלה, עיינו במסמכי התיעוד של היכולות המשויכות.

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

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