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

טייס אוטומטי רגילה

במאמר הזה מוסבר איך לבקש באופן ידני שדרוג או הורדת רמה של מישור הבקרה או הצמתים של אשכול 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 לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
הערה: אם כבר התקנתם את ה-CLI של gcloud, הקפידו להגדיר את compute/region המאפיין. אם אתם משתמשים בעיקר באשכולות אזוריים, הגדירו במקום זאת את compute/zone. אם מגדירים מיקום ברירת מחדל, אפשר להימנע משגיאות ב-CLI של gcloud כמו השגיאה הבאה: One of [--zone, --region] must be supplied: Please specify location. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

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

המסוף

כדי לעדכן ידנית את מישור הבקרה של האשכול:

עוברים לדף Google Kubernetes Engine במסוף Google Cloud .

מעבר אל Google Kubernetes Engine
לוחצים על שם האשכול.
בקטע Cluster basics (יסודות האשכול), לוחצים על Upgrade Available (שדרוג זמין) לצד Version (גרסה).
בוחרים את הגרסה החדשה ולוחצים על שמירת השינויים.

gcloud

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

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

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

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

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

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

מחליפים את VERSION בגרסה שאליה רוצים לשדרג את האשכול. אפשר להשתמש בגרסה ספציפית, כמו 1.32.9-gke.1072000, או בכינוי לגרסה, כמו latest. מידע נוסף מופיע במאמר בנושא ציון גרסת אשכול.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שיטה מומלצת:

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

מידע נוסף על מה צפוי במהלך סיום של צומת באופן כללי זמין בנושא Pods.

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

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

כדי ששדרוג של מאגר צמתים ייחשב להשלמה, צריך ליצור מחדש את כל הצמתים במאגר. אם השדרוג התחיל אבל לא הסתיים והוא במצב של שדרוג חלקי, יכול להיות שהגרסה של מאגר הצמתים לא תשקף את הגרסה של כל הצמתים. מידע נוסף זמין במאמר Some node versions don't match the node pool version after an incomplete node pool upgrade. כדי לוודא ששדרוג מאגר הצמתים הסתיים, בודקים את סטטוס השדרוג של מאגר הצמתים. אם פעולת השדרוג חורגת מתקופת השמירה, צריך לוודא שגרסת כל צומת בודד תואמת לגרסת מאגר הצמתים.

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

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

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

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

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

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

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

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

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

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

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

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

המסוף

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

עוברים לדף Google Kubernetes Engine במסוף Google Cloud .

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

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

gcloud

המשתנים הבאים משמשים בפקודות שבקטע הזה:

‫CLUSTER_NAME: שם האשכול של מאגר הצמתים שיש לשדרג.
‫NODE_POOL_NAME: שם מאגר הצמתים שרוצים לשדרג.
‫CONTROL_PLANE_LOCATION: המיקום (אזור או אזור זמינות) של מישור הבקרה, למשל us-central1 או us-central1-a.
‫VERSION: גרסת Kubernetes שאליה יש לשדרג את הצמתים. לדוגמה, --cluster-version=1.34.1-gke.1293000 או cluster-version=latest.

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

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

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

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

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

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

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

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

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

שיטה מומלצת:

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

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

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

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

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

אפשר לבדוק את סטטוס השדרוג באמצעות 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 מוסבר מה קורה כשמבטלים שדרוג blue-green.

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

gcloud container operations list \
      --location=CONTROL_PLANE_LOCATION

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

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

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

פתרון בעיות

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

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

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

מידע על שדרוג

מגבלות

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

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

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

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

המסוף

gcloud

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

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

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

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

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

השלמת השדרוג הדו-שלבי

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

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

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

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

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

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

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

המסוף

gcloud

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

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

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

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

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

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

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

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

בעיות מוכרות

פתרון בעיות

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

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