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

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

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

הגדרה של כמה סביבות

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

מומלץ להשתמש בסביבות הבאות:

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

רישום אשכולות לערוצי הפצה

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

כדי שהאשכולות יהיו מעודכנים עם העדכונים האחרונים של GKE ו-Kubernetes, ריכזנו כאן כמה סביבות מומלצות וערוצי ההפצה המתאימים שאליהם צריך לרשום את האשכולות:

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

רמות הבקרה של אשכולות משודרגות באופן קבוע, גם אם האשכול רשום בערוץ הפצה וגם אם לא.

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

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

  • התיקונים מופצים בהדרגה למישור הבקרה ולצמתים בכל הערוצים, ומצטבר זמן טבילה בערוצים 'מהיר' ו'רגיל' לפני שהם מגיעים לערוץ 'יציב'.
  • מישור הבקרה משודרג קודם, ואחריו הצמתים, בהתאם למדיניות Kubernetes OSS שלפיה הגרסה של kubelet לא יכולה להיות חדשה יותר מגרסה kube-apiserver.
  • ‫GKE יפיץ תיקונים לערוצים באופן אוטומטי על סמך רמת הקריטיות והחשיבות שלהם.
  • בערוץ היציב מתקבלים רק תיקונים קריטיים.

קבלת עדכונים על גרסאות חדשות של GKE

מידע על גרסאות חדשות מתפרסם בדף הראשי של ההערות למוצר של GKE וגם בפיד RSS. לכל ערוץ הפצה יש דף ייעודי ופשוט של הערות על הגרסה (לדוגמה: הערות על הגרסה של הערוץ היציב) עם מידע על גרסת GKE המומלצת לאותו ערוץ.

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

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

בדיקה ואימות של תיקון חדש וגרסאות משניות

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

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

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

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

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

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

בטבלה הבאה מפורטים אירועי ההשקה והפעולות המומלצות:

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

אסטרטגיית שדרוג לגרסאות תיקון

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

  • כל האשכולות רשומים לערוץ היציב.
  • גרסאות חדשות שזמינות מופצות קודם לאשכול ההכנה.
  • אשכול הייצור משודרג אוטומטית לגרסת היעד החדשה של השדרוג האוטומטי.
  • מעקב קבוע אחרי גרסאות חדשות שזמינות ל-GKE.
שעה אירוע מה לעשות?
T - 1 week גרסת תיקון חדשה זמינה. שדרוג סביבת הבמה.
T גרסת התיקון הופכת לגרסת היעד של השדרוג האוטומטי. כדי לשפר את יכולת החיזוי, מומלץ לשדרג את מישור הבקרה של הייצור מראש.
T מערכת GKE תתחיל לשדרג את מישורי הבקרה לגרסת היעד של השדרוג האוטומטי. כדי לשפר את יכולת החיזוי, כדאי לשדרג מראש את מאגרי הצמתים של הייצור.
T + שבוע אחד מערכת GKE תתחיל לשדרג את מאגרי הצמתים באשכול ליעד השדרוג האוטומטי. מערכת GKE תשדרג את האשכולות באופן אוטומטי, ותדלג על האשכולות ששודרגו באופן ידני.

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

הנה אסטרטגיית שדרוג מומלצת לגרסאות משניות חדשות:

שעה אירוע מה לעשות?
T - 3 weeks גרסה משנית חדשה זמינה שדרוג מישור הבקרה של הבדיקה
T - 2 weeks
  1. אם השדרוג של מישור הבקרה הצליח, כדאי לשדרג את מישור הבקרה של הסביבה הפרודקטיבית מראש.
  2. שדרוג מאגרי צמתים לבדיקה.
T - 1 week אם השדרוג הצליח, כדאי לשדרג את מאגרי הצמתים של הסביבה הפרודקטיבית מראש.
T גרסה משנית הופכת לגרסת היעד של השדרוג האוטומטי.
T ‫GKE יתחיל לשדרג את מישורי הבקרה של האשכולים לגרסת היעד של השדרוג האוטומטי. יצירת חלון החרגה אם נדרשות בדיקות נוספות או פעולות לצמצום הסיכון לפני ההשקה בסביבת הייצור.
T + שבוע אחד מערכת GKE תתחיל לשדרג את מאגרי הצמתים באשכול ליעד השדרוג האוטומטי. ‫GKE ישדרג את האשכולות באופן אוטומטי, וידלג על האשכולות ששודרגו באופן ידני.

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

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

תזמון של חלונות תחזוקה והחרגות

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

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

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

הגדרת רמת הסבילות להפרעות

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

בתקציב לשיבוש Pod, אפשר להגדיר מספר (או אחוז) של Pods שאפשר לסיים את הפעולה שלהם, גם אם סיום הפעולה של ה-Pods מביא את מספר הרפליקות הנוכחי מתחת לערך הרצוי. התהליך הזה עשוי להאיץ את ניקוי הצמתים, כי לא צריך לחכות עד שהפודים שהועברו יהיו פעילים באופן מלא. במקום זאת, הפקודה drain מוציאה את הפודים מצומת לפי הגדרת ה-PDB, וכך מאפשרת לפריסה לפרוס פודים חסרים בצמתים זמינים אחרים. אחרי שמגדירים את ה-PDB,‏ GKE לא ישבית את ה-Pods באפליקציה אם מספר ה-Pods שווה למגבלה שהוגדרה או קטן ממנה. ‫GKE פועל לפי PDB למשך עד 60 דקות.

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

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

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

במקרים של אשכולות גדולים שבהם תהליך השדרוג עשוי להימשך זמן רב יותר, אפשר לשדרג כמה צמתים בו-זמנית כדי לקצר את משך השדרוג. משתמשים בשדרוג מתח עם maxSurge=20, ‏ maxUnavailable=0 כדי להנחות את GKE לשדרג 20 צמתים בכל פעם, בלי להשתמש בקיבולת קיימת.

שימוש בערוץ Extended כשצריכים תמיכה לטווח ארוך

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

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

הארכת השימוש בגרסה משנית באופן זמני

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

שדרוגים של גרסאות משניות פעם או פעמיים בשנה

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

  • הרשמה של אשכול לערוץ המורחב.
  • מבצעים שדרוגים של גרסאות משניות פעמיים בשנה. לדוגמה, שדרוג מגרסה 1.30 לגרסה 1.31 לגרסה 1.32.

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

מתי לא כדאי להשתמש בערוץ המורחב

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

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

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

סיכום רשימת המשימות

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

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

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