‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כדי לבצע Rollback, אם אפשר:

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

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

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

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

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

 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).

שיטה מומלצת:

כדי שהאשכול ייהנה מהשדרוגים שמפורטים בפסקה הקודמת, מומלץ לא להשבית את השדרוגים האוטומטיים של הצמתים ב-Standard node pools.

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

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

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

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

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

שיטה מומלצת:

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

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

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

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

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

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

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

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

שיטה מומלצת:

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

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

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

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

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

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

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

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

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

אם אתם משתמשים באסטרטגיית השדרוג 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.

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

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

משתמשים בפקודה 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

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

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

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

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

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

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

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

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

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

בעיות מוכרות

פתרון בעיות

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

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