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

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

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

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

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

כדי לשדרג אשכול, GKE מעדכן את הגרסה שרצתה ברמת הבקרה ובצמתים, בפעולות נפרדות. השדרוג של האשכולות הוא לגרסה משנית חדשה יותר (לדוגמה, מ-1.33 ל-1.34) או לגרסה חדשה יותר עם תיקון (לדוגמה, מ-1.33.4-gke.1350000 ל-1.33.5-gke.1080000). מישור הבקרה והצמתים של אשכול לא בהכרח מריצים את אותה גרסה בכל רגע נתון. מידע נוסף על גרסאות זמין במאמר ניהול גרסאות ותמיכה ב-GKE.

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

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

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

לפני שמתחילים

לפני שמתחילים, חשוב לוודא שביצעתם את המשימות הבאות:

• מפעילים את ממשק ה-API של Google Kubernetes Engine.
הפעלת Google Kubernetes Engine API
• כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז לאתחל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.

• מוודאים שיש לכם אשכול קיים במצב Autopilot או במצב רגיל. כדי ליצור אשכול חדש, קראו את המאמר יצירת אשכול Autopilot.

מידע על שדרוג

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

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

מגבלות

אי אפשר לשדרג אשכולות אלפא.

גרסאות נתמכות

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

gcloud container get-server-config \
    --location=CONTROL_PLANE_LOCATION

מחליפים את CONTROL_PLANE_LOCATION במיקום (אזור או תחום) של מישור הבקרה, למשל us-central1 או us-central1-a.

אם האשכול רשום לערוץ הפצה, אתם יכולים לשדרג לגרסת תיקון בערוץ הפצה אחר עם אותה גרסה משנית כמו של מישור הבקרה. לדוגמה, אתם יכולים לשדרג את האשכול מגרסה ‎1.33.4-gke.1350000 בערוץ הרגיל לגרסה ‎1.33.5-gke.1162000 בערוץ המהיר. מידע נוסף זמין במאמר הפעלת גרסאות תיקון מערוץ חדש יותר. כל אשכולות Autopilot רשומים לערוצי הפצה.

מידע על שדרוג לאחור

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

• שדרוג לאחור של תיקון ברמת הבקרה: כדי לצמצם את הסיכון לשדרוג לא מוצלח של רמת הבקרה של האשכול, אפשר לשדרג לאחור את רמת הבקרה לגרסת תיקון קודמת אם הגרסה היא גרסת תיקון קודמת באותה גרסה משנית. לדוגמה, אם מישור הבקרה של האשכול שלכם מריץ את GKE 1.33.5-gke.1080000, אתם יכולים לשנמך את מישור הבקרה ל-1.33.4-gke.1350000, אם הגרסה הזו עדיין זמינה.
• חזרה לגרסה קודמת במהלך שדרוג בשני שלבים של גרסה משנית של מישור הבקרה: אפשר לשדרג לאחור את מישור הבקרה של אשכול Kubernetes לגרסה משנית קודמת רק אחרי השדרוג הבינארי של שדרוג בשני שלבים של גרסה משנית של מישור הבקרה עם בטיחות החזרה לגרסה קודמת. אם GKE כבר השלים את השלב השני של השדרוג הדו-שלבי – שדרוג הגרסה המדומה – אי אפשר לחזור לגרסה המשנית הקודמת.
• חזרה לגרסה קודמת של מאגר צמתים: אפשר לחזור לגרסה קודמת של תיקון או לגרסה משנית קודמת של שדרוג מאגר צמתים שהושלם באופן חלקי.
• שדרוג לאחור של מאגר צמתים: אתם יכולים לשדרג לאחור מאגר צמתים לגרסת תיקון או לגרסה משנית קודמת, למשל כדי לבטל שדרוג של מאגר צמתים שגרם לבעיות בעומסי העבודה. חשוב לוודא שאתם לא משנמכים את הצמתים לגרסה שנמוכה ביותר משתי גרסאות משניות מגרסת מישור הבקרה של האשכול.

אי אפשר לשדרג לאחור אשכול, חוץ מהתרחישים שמתוארים בנקודות הקודמות. אי אפשר לשדרג לאחור את רמת הבקרה של אשכול לגרסה משנית קודמת, גם אחרי שדרוג משני של רמת הבקרה בשלב אחד. לדוגמה, אם במישור הבקרה פועלת גרסה 1.34 של GKE, אי אפשר לשדרג לאחור לגרסה 1.33. אם תנסו לעשות את זה, תופיע הודעת השגיאה הבאה:

ERROR: (gcloud.container.clusters.upgrade) ResponseError: code=400,
message=Master cannot be upgraded to "1.33.4-gke.1350000": specified version is
not newer than the current version.

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

שדרוג מישור הבקרה של האשכול

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

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

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

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

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

אתם יכולים לשדרג ידנית את מישור הבקרה של Autopilot או Standard באמצעות מסוף Cloud de Confiance או Google Cloud CLI.

gcloud container get-server-config \
    --location=CONTROL_PLANE_LOCATION

gcloud container clusters upgrade CLUSTER_NAME \
    --master \
    --location=CONTROL_PLANE_LOCATION

gcloud container clusters upgrade CLUSTER_NAME \
    --master \
    --location=CONTROL_PLANE_LOCATION \
    --cluster-version=VERSION

אחרי שמשדרגים את מישור הבקרה של Standard, אפשר לשדרג את הצמתים שלה. כברירת מחדל, השדרוג האוטומטי מופעל בצמתים רגילים שנוצרו באמצעות מסוף Cloud de Confiance , כך שהשדרוג מתבצע באופן אוטומטי. ב-Autopilot, הצמתים תמיד משודרגים באופן אוטומטי.

שדרוג מינורי של מישור הבקרה בשני שלבים עם בטיחות החזרה למצב קודם

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

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

שדרוגים בשני שלבים פועלים באופן הבא:

1. שדרוג בינארי: GKE משדרג את הקובץ הבינארי של מישור הבקרה לגרסה המשנית החדשה, אבל מדמה את הגרסה המשנית הקודמת:

   • הדמיה של הגרסה הקודמת: האשכול מריץ את הקובץ הבינארי החדש, אבל ממשיך לדמות את ההתנהגות של ה-API של גרסת המשנה הקודמת. לדוגמה, אפשר להפעיל ממשקי API שהוסרו בגרסה המשנית החדשה, אבל עדיין זמינים בגרסה המשנית הקודמת.
   • בדיקת קובץ בינארי חדש: אתם יכולים לבדוק את הקבצים הבינאריים החדשים כדי לזהות רגרסיות, תיקונים ושינויים בביצועים לפני שאתם מאפשרים גישה לתכונות של Kubernetes שזמינות בגרסה המשנית החדשה. מעקב אחרי מדדי האפליקציה, היומנים, סטטוסים של Pod, שיעורי השגיאות וזמן האחזור.
   • המתנה: ממתינים בין 6 שעות ל-7 ימים (24 שעות לשדרוגים אוטומטיים) כדי לבדוק ולעקוב אחרי השינויים. אחרי פרק הזמן הזה, GKE מבצע את השדרוג לגרסה המדומה.
   • החזרה לגרסה קודמת או השלמת השדרוג: אפשר לחזור לגרסה קודמת, אם צריך. לחלופין, אם אתם בטוחים בגרסה המשנית החדשה, לא רוצים לחכות עד לסיום זמן הטבילה ומוכנים להתחיל להשתמש בתכונות החדשות ובשינויים ב-API, אתם יכולים להתקדם לשלב הבא.

2. שדרוג גרסת האמולציה: GKE מעדכן את גרסת האמולציה כך שתתאים לגרסה הבינארית החדשה.

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

במהלך הפעולה הזו, חלות המגבלות הבאות:

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

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

התחלת שדרוג בשני שלבים

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

gcloud beta container clusters upgrade CLUSTER_NAME \
  --location=CONTROL_PLANE_LOCATION \
  --cluster-version VERSION \
  --control-plane-soak-duration SOAK_DURATION \
  --master

מחליפים את מה שכתוב בשדות הבאים:

• ‫CLUSTER_NAME: שם האשכול.
• ‫CONTROL_PLANE_LOCATION: המיקום (אזור או תחום) של מישור הבקרה, למשל us-central1 או us-central1-a.
• ‫VERSION: תיקון ספציפי של הגרסה המשנית הבאה. לדוגמה, אם האשכול שלכם פועל בגרסה 1.33, 1.34.1-gke.1829001.
• ‫SOAK_DURATION: משך הזמן שצריך להמתין בשלב הבטוח להחזרה למצב קודם. אפשר להגדיר את הערך הזה למינימום של 6 שעות ולמקסימום של 7 ימים, באמצעות Absolute duration formats, כפי שמוסבר במאמר העזרה בנושא gcloud topic datetimes. לדוגמה, משתמשים ב-2d1h לזמן השהייה של יומיים ושעה.

בדיקת הקובץ הבינארי החדש במהלך שדרוג דו-שלבי

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

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

מעקב אחרי השדרוג

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

• כדי לראות פרטים על השדרוג, פועלים לפי ההוראות לקבלת מידע על שדרוגים ברמת האשכול.
• שימוש בהתראות לגבי אשכולות. ‫GKE שולח התראה מסוג UpgradeEvent כשהשדרוג הבינארי מתחיל, והתראה מסוג UpgradeInfoEvent עם ההודעה Upgrade operation is complete כשהשדרוג הבינארי מסתיים ומתחיל זמן הטבילה.
• כדי לראות פרטים על האשכול, כולל על השדרוג שמתבצע, מריצים את הפקודה gcloud container clusters describe.
• אפשר לראות את היומנים הרלוונטיים ב-Cloud Logging.

חזרה משדרוג דו-שלבי אחרי שדרוג הגרסה הבינארית

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

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

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

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

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

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

   gcloud container clusters upgrade CLUSTER_NAME \
     --location=CONTROL_PLANE_LOCATION \
     --cluster-version VERSION
     --master
   

   הערך של מאפיין VERSION חייב להיות זהה לגרסת התיקון (patch) שבה נעשה שימוש קודם. שמרתם את הגרסה הזו בשלב הקודם.

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

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

השלמת השדרוג בשני שלבים

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

gcloud beta container clusters complete-control-plane-upgrade CLUSTER_NAME  \
  --location=CONTROL_PLANE_LOCATION

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

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

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

2. החזרה לגרסה קודמת של תיקון ברמת הבקרה של האשכול:

    gcloud container clusters upgrade CLUSTER_NAME \
        --master \
        --location=CONTROL_PLANE_LOCATION \
        --cluster-version=VERSION
   

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

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

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

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

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

gcloud container operations list --filter="TYPE:UPGRADE_MASTER AND TARGET:CLUSTER_NAME" \
    --location=CONTROL_PLANE_LOCATION

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

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

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

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

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

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

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

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

מופעי הצמתים החדשים מריצים את הגרסה החדשה של Kubernetes, וגם את הפעולות הבאות:

• תמונת הצומת
• kubelet
• kube-proxy

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

שמירת הנתונים בדיסקי אחסון מתמידים (persistent disk) לפני השדרוג

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

ההגבלות הבאות חלות על דיסקים לאחסון מתמיד:

• הצמתים שבהם פועלים הפודים חייבים להיות מכונות וירטואליות של Compute Engine.
• המכונות הווירטואליות האלה צריכות להיות באותו פרויקט ובאותו אזור ב-Compute Engine שבו נמצא דיסק אחסון מתמיד (persistent disk).

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

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

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

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

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

לפני שמשדרגים ידנית את מאגר הצמתים, חשוב לשים לב לתנאים הבאים:

• שדרוג של מאגר צמתים עלול לשבש את עומסי העבודה שפועלים במאגר הזה. כדי להימנע מכך, אפשר ליצור מאגר צמתים חדש עם הגרסה הנדרשת ולהעביר את עומס העבודה. אחרי ההעברה, אפשר למחוק את מאגר הצמתים הישן.
• אם משדרגים מאגר צמתים עם Ingress במצב שגיאה, קבוצת המכונות לא מסתנכרנת. כדי לעקוף את הבעיה, קודם בודקים את הסטטוס באמצעות הפקודה kubectl get ing. אם קבוצת המופעים לא מסונכרנת, אפשר לפתור את הבעיה על ידי הפעלה מחדש של המניפסט ששימש ליצירת ה-ingress.

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

• במאגרי צמתים רגילים, אפשר להשתמש במסוף Cloud de Confiance או ב-Google Cloud CLI.

• במאגרי צמתים שמנוהלים על ידי Autopilot, אפשר להשתמש רק ב-Google Cloud CLI.

gcloud container clusters upgrade CLUSTER_NAME \
  --node-pool=NODE_POOL_NAME \
  --location=CONTROL_PLANE_LOCATION

gcloud container clusters upgrade CLUSTER_NAME \
  --node-pool=NODE_POOL_NAME \
  --location=CONTROL_PLANE_LOCATION \
  --cluster-version VERSION

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

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

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

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

שינוי הפרמטרים של שדרוג מתח

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

הגדרת שדרוגים בו-זמניים של מאגרי צמתים

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

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

אי אפשר להפעיל את התכונה הזו באשכול שרשום לרצף השקה עם שלבים בהתאמה אישית.

כדי להגדיר שדרוגים בו-זמניים של מאגרי צמתים, מריצים את אחת מהפקודות הבאות:

• יוצרים אשכול חדש עם הגדרה של שדרוגים בו-זמניים של מאגרי צמתים:

  gcloud beta container clusters create CLUSTER_NAME \
      --project=PROJECT_NAME
      --location CONTROL_PLANE_LOCATION \
      --node-pool-upgrade-concurrency-config=max-count=MAX_COUNT
  

• כדי לעדכן אשכול קיים ולשדרג בו-זמנית מאגרי צמתים:

  gcloud beta container clusters update CLUSTER_NAME \
      --project=PROJECT_NAME \
      --location=CONTROL_PLANE_LOCATION \
      --node-pool-upgrade-concurrency-config=max-count=MAX_COUNT
  

מחליפים את מה שכתוב בשדות הבאים:

• ‫CLUSTER_NAME: שם האשכול.
• ‫PROJECT_NAME: שם הפרויקט.
• ‫LOCATION: מיקום המחשוב של האשכול.
• ‫MAX_COUNT: המספר המקסימלי של מאגרי הצמתים לשדרוג בו-זמני. הערך צריך להיות מספר שלם בין 1 ל-100. כדי לחזור להתנהגות הרציפה שמוגדרת כברירת מחדל, מגדירים את הערך הזה כ-1.

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

אפשר לבדוק את סטטוס השדרוג באמצעות gcloud container operations.

כדי להציג רשימה של כל הפעולות שפועלות ושהושלמו באשכול ב-12 הימים האחרונים (אם יש פחות מ-5,000 פעולות) או של 5,000 הפעולות האחרונות:

gcloud container operations list \
    --location=CONTROL_PLANE_LOCATION

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

NAME                              TYPE                ZONE           TARGET              STATUS_MESSAGE  STATUS  START_TIME                      END_TIME
operation-1505407677851-8039e369  CREATE_CLUSTER      us-west1-a     my-cluster                          DONE    20xx-xx-xxT16:47:57.851933021Z  20xx-xx-xxT16:50:52.898305883Z
operation-1505500805136-e7c64af4  UPGRADE_CLUSTER     us-west1-a     my-cluster                          DONE    20xx-xx-xxT18:40:05.136739989Z  20xx-xx-xxT18:41:09.321483832Z
operation-1505500913918-5802c989  DELETE_CLUSTER      us-west1-a     my-cluster                          DONE    20xx-xx-xxT18:41:53.918825764Z  20xx-xx-xxT18:43:48.639506814Z

כדי לקבל מידע נוסף על פעולה ספציפית, מציינים את מזהה הפעולה כמו שמוצג בפקודה הבאה:

gcloud container operations describe OPERATION_ID \
    --location=CONTROL_PLANE_LOCATION

לדוגמה:

gcloud container operations describe operation-1507325726639-981f0ed6
endTime: '20xx-xx-xxT21:40:05.324124385Z'
name: operation-1507325726639-981f0ed6
operationType: UPGRADE_CLUSTER
selfLink: https://container.googleapis.com/v1/projects/.../kubernetes-engine/docs/zones/us-central1-a/operations/operation-1507325726639-981f0ed6
startTime: '20xx-xx-xxT21:35:26.639453776Z'
status: DONE
targetLink: https://container.googleapis.com/v1/projects/.../kubernetes-engine/docs/zones/us-central1-a/clusters/...
zone: us-central1-a

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

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

כדי לראות פרטים על אסטרטגיית השדרוג של הצמתים שמשמשת את מאגרי הצמתים, אפשר להשתמש בפקודה gcloud container node-pools describe. בשדרוגים כחולים-ירוקים, הפקודה מחזירה גם את השלב הנוכחי של השדרוג.

מריצים את הפקודה הבאה:

gcloud container node-pools describe NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

מחליפים את מה שכתוב בשדות הבאים:

• ‫NODE_POOL_NAME: שם מאגר הצמתים שרוצים לתאר.
• ‫CLUSTER_NAME: השם של האשכול של מאגר הצמתים שרוצים לתאר.
• ‫CONTROL_PLANE_LOCATION: המיקום (אזור או תחום) של מישור הבקרה, למשל us-central1 או us-central1-a.

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

upgradeSettings:
  blueGreenSettings:
    nodePoolSoakDuration: 1800s
    standardRolloutPolicy:
      batchNodeCount: 1
      batchSoakDuration: 10s
  strategy: BLUE_GREEN

אם אתם משתמשים באסטרטגיית השדרוג blue-green, הפלט כולל גם פרטים על הגדרות השדרוג blue-green והשלב הביניים הנוכחי שלו. בדוגמה הבאה אפשר לראות איך זה נראה:

updateInfo:
  blueGreenInfo:
    blueInstanceGroupUrls:
    - https://www.googleapis.com/compute/v1/projects/{PROJECT_ID}/zones/{LOCATION}/instanceGroupManagers/{BLUE_INSTANCE_GROUP_NAME}
    bluePoolDeletionStartTime: {BLUE_POOL_DELETION_TIME}
    greenInstanceGroupUrls:
    - https://www.googleapis.com/compute/v1/projects/{PROJECT_ID}/zones/{LOCATION}/instanceGroupManagers/{GREEN_INSTANCE_GROUP_NAME} 
    greenPoolVersion: {GREEN_POOL_VERSION}
    phase: DRAINING_BLUE_POOL

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

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

1. מאחזרים את מזהה הפעולה של השדרוג:

   gcloud container operations list \
         --location=CONTROL_PLANE_LOCATION
   

2. ביטול השדרוג:

   gcloud container operations cancel OPERATION_ID \
         --location=CONTROL_PLANE_LOCATION
   

אפשר לקרוא מידע נוסף במאמרי העזרה של gcloud container operations cancel.

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

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

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

למידע נוסף על מה שקורה כשממשיכים שדרוג, קראו את המאמרים המשך של שדרוג מתח ושדרוג כחול-ירוק.

כדי להמשיך בשדרוג, משתמשים בפקודה הבאה:

gcloud container clusters upgrade CLUSTER_NAME \
  --node-pool=NODE_POOL_NAME \
  --location=CONTROL_PLANE_LOCATION \
  --cluster-version VERSION

מחליפים את מה שכתוב בשדות הבאים:

• ‫NODE_POOL_NAME: שם מאגר הצמתים שרוצים להמשיך את השדרוג שלו.
• ‫CLUSTER_NAME: שם האשכול של מאגר הצמתים שרוצים להמשיך את השדרוג שלו.
• ‫CONTROL_PLANE_LOCATION: המיקום (אזור או תחום) של מישור הבקרה, למשל us-central1 או us-central1-a.
• ‫VERSION: גרסת היעד של שדרוג מאגר הצמתים שבוטל.

מידע נוסף מופיע במאמרי העזרה בנושא gcloud container clusters upgrade.

חזרה לגרסה קודמת של מאגר צמתים

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

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

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

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

gcloud container node-pools rollback NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

מחליפים את מה שכתוב בשדות הבאים:

• ‫NODE_POOL_NAME: שם מאגר הצמתים שרוצים להחזיר לגרסה קודמת.
• ‫CLUSTER_NAME: שם האשכול של מאגר הצמתים שרוצים להחזיר לגרסה הקודמת.
• ‫CONTROL_PLANE_LOCATION: המיקום (אזור או תחום) של מישור הבקרה, למשל us-central1 או us-central1-a.

אפשר לקרוא מידע נוסף במאמרי העזרה של gcloud container node-pools rollback.

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

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

במאמר השלמת שדרוג של מאגר צמתים מוסבר איך משלימים שדרוג של מאגר צמתים.

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

gcloud container node-pools complete-upgrade NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

מחליפים את מה שכתוב בשדות הבאים:

• ‫NODE_POOL_NAME: שם מאגר הצמתים שרוצים לשדרג.
• ‫CLUSTER_NAME: שם האשכול של מאגר הצמתים שרוצים לשדרג.
• ‫CONTROL_PLANE_LOCATION: המיקום (אזור או תחום) של מישור הבקרה, למשל us-central1 או us-central1-a.

אפשר לקרוא מידע נוסף במאמרי העזרה של gcloud container node-pools complete-upgrade.

בעיות מוכרות

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

כדי לראות את כל האובייקטים מסוג PodDisruptionBudget שלא מאפשרים שיבושים:

kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'

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

פתרון בעיות

למידע על פתרון בעיות, ראו פתרון בעיות בשדרוג אשכולות.

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

• מידע על אסטרטגיות לשדרוג צמתים
• מידע ולמידה על שדרוגי אשכולות
• מידע ולמידה על שדרוגים אוטומטיים של צמתים
• מידע נוסף על חלונות זמן לתחזוקה והחרגות