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