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

במסמך הזה מוסבר איך מתבצעים שדרוגים אוטומטיים וידניים באשכולות 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 משדרג אוטומטית את האשכול או כשמבצעים שדרוג ידני.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שדרוגים של Surge

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

שדרוגים כחול-ירוק

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

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

שדרוגים אוטומטיים של כחול-ירוק

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

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

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

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

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

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

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

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

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

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

אם רושמים את האשכול בערוץ הפצה, הצמתים תמיד מריצים את אותה גרסה של 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.
  • צמתים חדשים של תנועה לא נרשמו ברמת הבקרה של האשכול.
  • היה צורך בזמן רב מדי כדי להוציא את העומס מהצמתים, או כדי למחוק אותם.

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

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

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

‫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 מריצה עומסי עבודה (workloads) בצמתי עובדים כדי לתמוך ביכולות ספציפיות של אשכולות. לדוגמה, עומס העבודה של מערכת gke-metadata-server תומך באיחוד שירותי אימות הזהות של עומסי עבודה ב-GKE. ‫GKE אחראי לתקינות של עומסי העבודה האלה. למידע נוסף על הרכיבים האלה, אפשר לעיין במסמכי התיעוד של היכולות המשויכות.

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

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