בדף הזה מוסבר איך לוודא שאפשר להשתמש בשיטות לשדרוג הצמתים כדי לבצע שינויים בצמתים של האשכול. מומלץ לבדוק אם בפרויקט יש מספיק משאבים כדי לעדכן את מאגרי הצמתים הרגילים של Google Kubernetes Engine (GKE), בהתאם לאסטרטגיה שתבחרו.
משאבים שנדרשים לשדרוג צמתים
יכול להיות ששדרוג הצמתים ידרוש מ-GKE ליצור באופן זמני צמתים נוספים, בהתאם לאסטרטגיית הצמתים ולהגדרה שבחרתם. לכן, יכול להיות ש-GKE ידרוש משאבים נוספים לשדרוג מאגר הצמתים.
כל הצמתים שנוצרים על ידי GKE, כולל צמתים שמשמשים לשדרוגים, כפופים למכסת המשאבים של הפרויקט, לזמינות המשאבים ולקיבולת ההזמנה, עבור מאגרי צמתים עם זיקה ספציפית להזמנה.
אם יש לכם דרישות מיוחדות לסוג המכונה ומגבלות קיבולת, מומלץ מאוד לוודא שיש לכם מספיק משאבים. יכול להיות שתצטרכו להגדיר אסטרטגיה שדורשת פחות משאבים כדי לוודא שתוכלו לשדרג את הצמתים, או לבצע פעולה אחרת כמו יצירת הזמנה. מידע נוסף זמין במאמר בנושא שדרוג בסביבה עם משאבים מוגבלים.
משאבים שנדרשים לאסטרטגיות שדרוג שונות
בקטעים הבאים מתוארים המשאבים הנוספים שנדרשים כדי להשתמש בשיטות השדרוג הזמינות. אם נתקלתם בבעיות בשדרוג, כדאי לבדוק את פעולות השדרוג ולפעול לפי ההוראות כדי לפתור שגיאות שדרוג.
מקורות מידע על שדרוגי מתח
שדרוגי גל הם שיטת השדרוג של הצמתים שמוגדרת כברירת מחדל. כשמבצעים שדרוגים של הגדלת הקיבולת, נוצרות מכונות וירטואליות נוספות – אם הערך של maxSurge גדול מאפס – לפני שמרוקנים ומוחקים את הצמתים הישנים. לכן, השדרוגים עלולים להיכשל אם בפרויקט אין מספיק משאבים.
אם המשאבים הזמינים קטנים ממספר הצמתים שצוין ב-maxSurge, מספר השדרוגים המקבילים יהיה קטן מ-maxSurge ועוד maxUnavailable. אם אין לכם קיבולת נוספת, תוכלו לקרוא איך לשדרג בסביבה עם מגבלות על משאבים.
בטבלה הבאה מפורטות דוגמאות שממחישות התנהגויות שונות של שדרוג:
| עדכון ההגדרות | מספר הצמתים הנוספים שמותרים לפי המשאבים הזמינים | תוצאה |
|---|---|---|
| maxSurge: 5 maxUnavailable: 0 | 5 | שדרוג של 5 צמתים במקביל. |
| maxSurge: 5 maxUnavailable: 0 | 2 | השדרוגים מתבצעים רק ב-2 צמתים במקביל. |
| maxSurge: 5 maxUnavailable: 0 | 0 | השדרוג נכשל, כי אי אפשר להפעיל צמתים נוספים והגדרות השדרוג אוסרות על הפעלה מחדש של צמתים קיימים. מערכת GKE ממשיכה לנסות לשדרג באופן אוטומטי עד שהפעולה מצליחה. |
| maxSurge: 5 maxUnavailable: 1 | 5 | משדרג 6 צמתים במקביל, תוך הקפדה על כך שמאגר הצמתים יאבד רק צומת אחד באופן זמני בגלל השדרוג. |
| maxSurge: 5 maxUnavailable: 1 | 2 | השדרוגים מתבצעים רק ב-3 צמתים במקביל, תוך הקפדה על כך שמאגר הצמתים לא יחסר יותר מצומת אחד בגלל השדרוג. |
| maxSurge: 5 maxUnavailable: 1 | 0 | השדרוגים מתבצעים רק בצומת אחד בכל פעם, על ידי יצירה מחדש של כל צומת בשיטת שדרוג מתגלגל. |
מקורות מידע לשדרוגים מסוג כחול-ירוק
שדרוגים מסוג blue-green מכפילים באופן זמני את מספר הצמתים במאגר הצמתים, כלומר מאגר הצמתים צריך באופן זמני כמות כפולה של משאבים. אם אין לכם מספיק משאבים זמינים והגדרתם את מאגר הצמתים לשימוש בשיטה הזו, תוכלו להגדיר שדרוגים בכמות גדולה במקום זאת, אם אתם צריכים לבטל את החסימה של השדרוגים. כשמגדירים את האסטרטגיה הזו, חשוב להגדיר פרמטרים לשדרוג מהיר שיפעלו עם המשאבים הזמינים לצמתים של מאגר הצמתים. מידע נוסף זמין בקטע הקודם, משאבים לשדרוגים בתקופות של עומס.
בדיקת פעולות שדרוג שקשורות למשאבים שנכשלו
אפשר למצוא מידע נוסף על פעולות השדרוג, וגם מידע על שדרוגים שנכשלו (אם יש כאלה) והסיבות לכך, על ידי בדיקת אובייקטים של פעולות השדרוג. כדי להציג את האובייקטים של פעולת השדרוג, מריצים את הפקודה הבאה:
gcloud container operations list \
--filter="STATUS=DONE AND TYPE=UPGRADE_NODES AND targetLink:https://container.googleapis.com/v1/projects/PROJECT_ID/zones/COMPUTE_ZONE/clusters/CLUSTER_NAME"
מחליפים את מה שכתוב בשדות הבאים:
-
PROJECT_ID: מזהה הפרויקט ב- Google Cloud . -
COMPUTE_ZONE: האזור של Compute Engine שבו נמצא האשכול. -
CLUSTER_NAME: השם של האשכול.
אם השדרוג האחרון נכשל בגלל מכסת משאבים לא מספיקה, הפלט ייראה כך:
gcloud container operations describe operation-1234567891234-1abc2d3e
detail: "Insufficient quota to satisfy the request: waiting on IG: instance https://www.googleapis.com/compute/v1/projects/my-project-123/zones/us-central1-a/instances/gke-my-cluster-default-pool-123ab45c-de67\
\ is still CREATING. Last attempt errors: [QUOTA_EXCEEDED] Instance 'gke-my-cluster-default-pool-123ab45c-de67'\
\ creation failed: Quota 'IN_USE_ADDRESSES' exceeded. Limit: 50.0 in region us-central1.\
...
אם הסיבה היא שלא הייתה הזמנה מספקת, הפלט ייראה כך:
gcloud container operations describe operation-1234567891234-1abc2d3e
detail: "Reservation does not have enough resources for the request: waiting on IG:\
\ instance https://www.googleapis.com/compute/v1/projects/my-project-123/zones/us-central1-a/instances/gke-my-cluster-default-pool-123ab45c-de67\
\ is still CREATING. Last attempt error: [CONDITION_NOT_MET] Instance 'gke-my-cluster-default-pool-123ab45c-de67'\
\ creation failed: Specified reservation 'foo' does not have available resources\
\ for the request."
אם הסיבה היא חוסר קיבולת, יוצגו הודעות שגיאה לגבי זמינות המשאבים.
פתרון שגיאות בשדרוג
אם השדרוג נכשל בגלל מחסור במשאבים, אפשר לנסות את השלבים הבאים:
- כדאי לשקול אסטרטגיית שדרוג שדורשת פחות משאבים. אם אתם משתמשים בשדרוגים מסוג blue-green, כדאי לשקול שדרוגים מסוג surge.
- בודקים אם יש בפרויקט משאבים של Compute Engine שצורכים משאבים ושכבר לא צריך אותם. אם מוצאים כאלה, מסירים אותם ומנסים לשדרג שוב.
- אם שני השלבים הראשונים לא פותרים את הבעיה, אפשר לבקש להגדיל את המכסה או להגדיל את הגודל של ההזמנה הספציפית.
- אם אתם פועלים בסביבה עם מגבלות על משאבים, למשל דרישות מיוחדות לסוג המכונה ומגבלות על הקיבולת, כדאי לעיין בקטע הבא כדי לראות איך לבטל את החסימה של השדרוגים.
שדרוג בסביבה עם מגבלות על משאבים
אם ל- Google Cloud יש קיבולת מוגבלת למשאב ספציפי (לדוגמה, GPU או TPU) שמאגר הצמתים שלכם משתמש בו, מומלץ להשתמש בהזמנה כדי לוודא שיש לכם מספיק משאבים. אם אין לכם מספיק משאבים, יכול להיות שלא תוכלו לשדרג את הצמתים עד שתהיה לכם גישה ליותר קיבולת, אלא אם יש לכם הזמנה לקיבולת הקיימת.
אם אי אפשר להגדיל את הקיבולת, אי אפשר להשתמש בשדרוגים מסוג blue-green. לשדרוגים של עומס תנועה,
maxSurge
נדרשים צמתים נוספים.
maxUnavailable,
אם הקיבולת לא מגיעה מהזמנה, GKE משחרר באופן זמני את הקיבולת של הצומת במהלך השדרוג, כלומר אם הקיבולת מוגבלת, אתם עלולים לאבד אותה.
בהתאם לכך, אם יש לכם הזמנה למאגר הצמתים שצריך לשדרג, אתם יכולים להיעזר בהנחיות הבאות.
שדרוג עם קיבולת מוגבלת ללא הזמנה
אם אין לכם הזמנה לצמתים של מאגר הצמתים, מומלץ ליצור הזמנה. עם זאת, אם אתם לא יכולים, מומלץ להשתמש בשדרוגים מהירים עם הגדרת ברירת המחדל של maxSurge=1;maxUnavailable=0. בשיטה הזו לא מסתכנים באובדן של הקיבולת הקיימת. עם זאת, שדרוגים של עומס תנועה יוצרים צומת של עומס תנועה רק אם יש קיבולת זמינה. לכן, אם אין קיבולת זמינה, יכול להיות שהשדרוגים יימשכו זמן רב יותר, ושהמאגר של צמתי העבודה יישאר במצב של שדרוג חלקי עד שתהיה קיבולת זמינה לשדרוג כל צומת.
מומלץ ליצור הזמנה או להגדיל את הגודל של הזמנה קיימת.
שדרוג עם קיבולת מוגבלת באמצעות הזמנה
אם יש לכם הזמנה לצמתים במאגר הצמתים, אתם יכולים לשדרג את מאגרי הצמתים בסביבה עם מגבלות קיבולת. לשם כך, אתם יכולים לשנות את ההגדרות של השדרוג המצטבר כדי לשפר את המהירות והאמינות.
אם יש לכם קיבולת נוספת בהזמנה, אתם יכולים להשתמש ב-maxSurge כדי ליצור צמתים של תנועה גבוהה. מגדירים את maxSurge בהתאם למספר הצמתים שרוצים לשבש בכל פעם, ולנפח הנוסף שיש לכם. לדוגמה, מגדירים את maxSurge=1;maxUnavailable=0 אם רוצים לשבש רק צומת אחד בכל פעם, או אם יש לכם קיבולת ליצירת צומת נוסף אחד בלבד.
אם אין לכם קיבולת נוספת, אתם יכולים להשתמש ב-maxUnavailable עם הגדרה כמו maxSurge=0;maxUnavailable=1, כי הקיבולת שמורה. ההגדרה הזו משבשת צומת אחד בכל פעם, ויוצרת מחדש את הצומת כדי לעדכן אותו. אנחנו ממליצים על הגישה הזו לביצוע תחזוקת מארח לצמתים שמריצים עומסי עבודה של אימון והסקת מסקנות.