עדכון מאגר צמתים

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

  • כדי לשדרג את הגרסה של מאגר הצמתים
  • כדי לשנות את מספר הצמתים במאגר הצמתים
  • כדי לשנות את ההערות של מאגר הצמתים (אפשר לעדכן רק דרך ה-API)

אפשר גם לשנות פרמטרים נוספים במאגרי הצמתים שלא מופיעים למעלה. רשימה מלאה של הפרמטרים שאפשר לעדכן מופיעה במאמרי העזרה בנושא gcloud container azure node-pools update וprojects.locations.azureNodePools.patch.

תהליך העדכון

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

עדכון של הגדרות בלבד

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

עדכון בהדרגה (rolling)

כששינוי במאגר צמתים מחייב הפעלה מחדש של מכונות וירטואליות קיימות – למשל, כשמעדכנים את גרסת Kubernetes –‏ GKE on Azure מבצע את השלבים הבאים:

  1. משנים את קבוצת קנה המידה של המכונה הווירטואלית של מאגר הצמתים באמצעות הגדרה חדשה.
  2. בוחרים את המופע הבסיסי של אחד מהצמתים שרוצים לעדכן.
  3. ‫GKE ב-Azure מגדיר את הצומת כ-cordon ומרוקן אותו. בשלב הזה, אי אפשר לתזמן פודים חדשים בצומת היעד. אובייקטים קיימים של Pod בצומת היעד מתוזמנים מחדש בצמתים אחרים. אם אי אפשר לתזמן מחדש פודים באף צומת קיים אחר, הם נשארים בשלב ההמתנה עד שאפשר לתזמן אותם.
  4. מעדכנים את המופע כדי לקבל את ההגדרה העדכנית ביותר מקבוצת קנה המידה של המכונה הווירטואלית.
  5. מבצעים reimage ומפעילים מחדש את המכונה.
  6. מחכים עד שכל הצמתים במאגר הצמתים הזה יהיו תקינים.
  7. אם כל הצמתים במאגר הצמתים הזה תקינים, בוחרים צומת אחר עד שכל הצמתים יעודכנו. אם יש צומת לא תקין, GKE ב-Azure מעביר את מאגר הצמתים למצב DEGRADED. מידע נוסף זמין במאמר בנושא עדכונים שנכשלו.

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

במהלך עדכון בהדרגה (rolling) של מאגר צמתים, GKE on Azure מכבד את ההגדרה של PodDisruptionBudget ‏
למשך שעה לכל היותר אחרי שמתחיל ניקוז של צומת. אחרי שעה, GKE ב-Azure מוחק את כל ה-Pods שנותרו בצומת.

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

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

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

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

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

  • אם המספר המינימלי החדש של הצמתים גבוה ממספר הצמתים הנוכחי במאגר הצמתים, GKE on Azure מוסיף עוד צמתים עד שמאגר הצמתים מגיע לגודל המינימלי החדש.

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

    1. עדכון ההגדרה של התאמה אוטומטית לעומס במערך של מכונות וירטואליות במאגר הצמתים
    2. בחירת צומת להסרה
    3. הגבלת הגישה לצומת וניקוז הנתונים ממנו
    4. מחיקה של מופע המכונה הווירטואלית הבסיסי
    5. ממתינים עד שהמכונה הווירטואלית שנמחקה תיעלם לגמרי
    6. ביצוע בדיקת תקינות של כל מאגר הצמתים
    7. חוזרים על הפעולה עד שמגיעים למספר הצמתים הרצוי.

איך GKE ב-Azure מגן על עומסי עבודה במהלך שינוי הגודל של מאגר הצמתים

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

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

בדיקה של סטטוס עדכון שנכשל

אם GKE ב-Azure מבצע בדיקת תקינות אחרי עדכון ובדיקת התקינות נכשלת, מאגר הצמתים מסומן כDEGRADED. אפשר למצוא מידע על הסטטוס של האשכול באמצעות הפקודה הבאה של Google Cloud CLI:

gcloud container azure node-pools describe NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION

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

  • ‫NODE_POOL_NAME: השם של מאגר הצמתים
  • ‫CLUSTER_NAME: השם של האשכול
  • ‫GOOGLE_CLOUD_LOCATION: האזור Google Cloud שמנהל את האשכול

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

דרישות מוקדמות

כדי לעדכן מאגר צמתים, אתם צריכים הרשאה לניהול זהויות והרשאות גישה (IAM) gkemulticloud.googleapis.com/azureNodePools.update.

עדכון מאגר צמתים

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

gcloud container azure node-pools update NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION \
    --node-version NODE_POOL_VERSION \
    --min-nodes MIN_NODES \
    --max-nodes MAX_NODES

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

  • ‫NODE_POOL_NAME: השם של מאגר הצמתים שרוצים לעדכן
  • ‫CLUSTER_NAME: השם של האשכול שאליו רוצים לצרף את מאגר הצמתים
  • ‫GOOGLE_CLOUD_LOCATION: האזור הנתמך Google Cloud שמנהל את האשכול. לדוגמה, us-west1
  • ‫NODE_POOL_VERSION: הגרסה החדשה של מאגר הצמתים שנתמכת
  • ‫MIN_NODES: מספר הצמתים המינימלי החדש שיכול להיות במאגר הצמתים. הערך חייב להיות 0 ומעלה.
  • ‫MAX_NODES: המספר המקסימלי החדש של הצמתים שיכולים להיות במאגר הצמתים. הערך חייב להיות לפחות 1 וגם הערך של MIN_NODES.

ביטול פעולת עדכון

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

gcloud container azure operations cancel OPERATION_NAME

מחליפים את OPERATION_NAME בשם של פעולת העדכון.

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

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