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

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

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

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

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

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

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

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

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

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

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

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

• מוודאים שיש לכם אשכול קיים במצב Autopilot או במצב Standard. כדי ליצור אשכול חדש, אפשר לעיין במאמר יצירת אשכול 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, אם הגרסה הזו עדיין זמינה.
• חזרה לגרסה קודמת במהלך שדרוג משני של מישור הבקרה בשני שלבים (גרסת Preview): אפשר לשנמך את מישור הבקרה של אשכול Kubernetes לגרסה משנית קודמת רק אחרי שדרוג בינארי של שדרוג משני של מישור הבקרה בשני שלבים עם בטיחות חזרה לגרסה קודמת. אם GKE כבר השלים את השלב השני של השדרוג הדו-שלבי – שדרוג הגרסה המדומה – אי אפשר לחזור לגרסה המשנית הקודמת.
• חזרה לגרסה קודמת של מאגר צמתים: אפשר לחזור לגרסה קודמת של תיקון או לגרסה משנית קודמת של שדרוג מאגר צמתים שהושלם באופן חלקי.
• הורדת רמה של מאגר צמתים: אפשר להוריד את הרמה של מאגר צמתים לגרסת תיקון או לגרסה משנית קודמת, למשל כדי לבטל שדרוג של מאגר צמתים שהושלם וגרם לבעיות בעומסי העבודה. חשוב לוודא שלא משדרגים לאחור את הצמתים לגרסה שמפגרת ביותר משתי גרסאות משניות אחרי גרסת מישור הבקרה של האשכול.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

gcloud beta container clusters 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 משדרג אוטומטית רק מאגר צמתים אחד בכל פעם. כדי לשדרג אוטומטית כמה מאגרי צמתים בו-זמנית, אפשר להגדיר שדרוגים מקבילים של מאגרי צמתים (גרסת Preview).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  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.

אם יש פחות מ-5,000 פעולות, אפשר לראות רשימה של כל הפעולות שפועלות ושל כל הפעולות שהושלמו באשכול מ-12 הימים האחרונים, או מ-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

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

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

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

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

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.

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

upgradeSettings:
  blueGreenSettings:
    nodePoolSoakDuration: 1800s
    standardRolloutPolicy:
      batchNodeCount: 1
      batchSoakDuration: 10s
  strategy: 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 מוסבר מה קורה כשמבטלים שדרוג כזה.

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

   gcloud container operations list \
         --location=CONTROL_PLANE_LOCATION
   

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

   gcloud container operations cancel OPERATION_ID \
         --location=CONTROL_PLANE_LOCATION
   

אפשר לעיין במסמכי התיעוד של gcloud container operations cancel.

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

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

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

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

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

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מסמכי העזרה.

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

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

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

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

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.

פתרון בעיות

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

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

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