הגדרת Pod bursting ב-GKE

בדף הזה מוסבר איך להגדיר Pods כדי להגדיל את נפח התעבורה לקיבולת פנויה לא מנוצלת בצמתים של Google Kubernetes Engine ‏ (GKE).

מהו שימוש חורג?

Bursting מתאר את הפעולה של Pods שמשתמשים באופן זמני ביותר קיבולת מחשוב בצומת ממה שהם ביקשו במקור.

ב-Kubernetes אפשר לבקש קיבולות ספציפיות של משאבים כמו CPU או זיכרון עבור ה-Pods. אתם מגדירים את הבקשות האלה במניפסט של ה-Pod. מתזמן Kubernetes ממקם את ה-Pods בצמתים שיש בהם מספיק קיבולת כדי להכיל את בקשות המשאבים האלה.

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

מידע נוסף על התהליך הזה ב-GKE זמין בקטע קיבולת מתפרצת ב-GKE בדף הזה.

היתרונות של הרחבת קיבולת ה-Pod

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

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

התכונה Bursting מאפשרת לכם לבקש רק את המשאבים שנדרשים ל-Pod לרוב זמן הריצה שלו, ועוזרת לו לצרוך יותר משאבים אם יש צורך בכך. היתרונות של שימוש ב-bursting כוללים:

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

מתי לא כדאי להשתמש בשיטת ה-bursting

מערכת Kubernetes מקצה את המחלקה Burstable Quality of Service (QoS) ל-Pods שבהם צוינו מגבלות משאבים גבוהות יותר מהבקשות שלהם. יש סיכוי גבוה יותר שקבוצות Pod של Burstable QoS יסולקו כש-Kubernetes צריך לפנות משאבים בצומת. מידע נוסף זמין במאמר בנושא סיווג QoS עם יכולת התפרצות במאמרי העזרה של Kubernetes.

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

לפני שמתחילים, חשוב לוודא שביצעתם את הפעולות הבאות:

• מפעילים את ממשק Google Kubernetes Engine API.
הפעלת Google Kubernetes Engine API
• כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את gcloud CLI. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.

• מוודאים שיש לכם אשכול GKE Autopilot שפועלת בו גרסה 1.30.2-gke.1394000 ואילך, או כל גרסה של אשכול GKE Standard. כדי ליצור אשכול חדש, אפשר לעיין במאמר בנושא יצירת אשכול Autopilot.

זמינות של פרץ תעבורה ב-GKE

עומסי עבודה יכולים להגיע לשיא במצבים הבאים:

מגבלות

• עומסי עבודה של Autopilot יכולים להשתמש ב-bursting רק לבקשות של CPU וזיכרון.

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

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

  1. בודקים אם בכל הצמתים פועלת גרסה 1.30.2-gke.1394000 ואילך:

     kubectl get nodes
     

     הפלט אמור להיראות כך:

     NAME                                          STATUS   ROLES    AGE     VERSION
     gk3-ap-cluster-1-default-pool-18092e49-mllk   Ready    <none>   4m26s   v1.30.2-gke.1349000
     

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

  2. מוודאים שקבוצת השרתים מריצה cgroupv2. הוראות מפורטות מופיעות במאמר בדיקת מצב cgroup.

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

     gcloud container clusters upgrade CLUSTER_NAME --master \
         --cluster-version CURRENT_CLUSTER_VERSION
     

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

     • ‫CLUSTER_NAME: השם של האשכול הקיים.
     • ‫CURRENT_CLUSTER_VERSION: הגרסה שמופעלת באשכול.

התחברות לאשכול

מריצים את הפקודה הבאה:

gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION

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

• ‫CLUSTER_NAME: השם של האשכול הקיים.
• ‫LOCATION: המיקום של האשכול.

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

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

עומסי העבודה הבאים של Autopilot יכולים להשתמש ב-Burst רק אם DaemonSet בניהול GKE בשם efficiency-daemon פועל באשכול:

• ‫Pods ב-Autopilot שמבקשים את Scale-Out או את Balanced מחלקות המחשוב המוגדרות מראש.
• ‫Autopilot Pods שלא מבקשים מחלקת מחשוב.

‫GKE פורס את efficiency-daemon DaemonSet כשאשכול Autopilot עומד בדרישות לשימוש ב-Bursting, כפי שמתואר בקטע זמינות של Bursting ב-GKE.

כדי לבדוק אם DaemonSet של efficiency-daemon קיים באשכול, מריצים את הפקודה הבאה:

kubectl get daemonset --namespace=kube-system efficiency-daemon

הפלט אמור להיראות כך:

NAME                DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
efficiency-daemon   1         1         1       1            1           <none>          105d

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

פריסת עומס עבודה עם יכולת התפרצות

1. שומרים את קובץ המניפסט הבא בשם burstable-deployment.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: helloweb
     labels:
       app: hello
   spec:
     selector:
       matchLabels:
         app: hello
         tier: web
     template:
       metadata:
         labels:
           app: hello
           tier: web
       spec:
         containers:
         - name: hello-app
           image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
           ports:
           - containerPort: 8080
           resources:
             requests:
               cpu: 250m
             limits:
               cpu: 350m
   

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

   • ‫resources.requests: המשאבים שהקונטיינר צריך כדי לפעול. מגדירים את הערך הזה לקיבולת שמאגר התגים יצטרך במצב יציב.
   • ‫resources.limits: קיבולת המשאבים המקסימלית שהקונטיינר יכול להשתמש בה. אם מגדירים את המגבלות גבוה יותר מהבקשות, אפשר להגדיל את ה-Pods עד למגבלה שצוינה, אם הקיבולת הזו זמינה בצומת. אם לא מציינים את השדה הזה, ה-Pods יכולים להשתמש בקיבולת הזמינה של ה-Node. המכסה הזו מחושבת כך:
     • מצב Autopilot: קיבולת לא בשימוש בסכום של בקשות המשאבים של ה-Pods בצומת.
     • מצב רגיל: קיבולת לא מנוצלת במשאבי הצומת.
   • ‫spec.nodeSelector ו-spec.tolerations: אופציונליים. מוסיפים את השדות האלה עם תוויות מותאמות אישית כמו pod-type: "non-critical" כדי להנחות את GKE ליצור צמתים חדשים להפעלת ה-Pods עם יכולת ההתפרצות. ‫GKE מחיל taints על הצמתים החדשים האלה כדי למנוע הפעלה של Pods אחרים, כמו עומסי עבודה קריטיים, באותם צמתים. במצב Autopilot, יש דרישות מינימום גבוהות יותר למשאבים עבור Pods שמשתמשים בהפרדה של עומסי עבודה. פרטים נוספים זמינים במאמרים הגדרת הפרדה בין עומסי עבודה ב-GKE ובקשות למשאבים ב-Autopilot.

2. פורסים את עומס העבודה:

   kubectl apply -f burstable-deployment.yaml
   

   יכול להיות שיעברו כמה דקות עד שהעומס יתחיל.

3. כדי לבדוק את מחלקת ה-QoS של Pod:

   kubectl describe pod helloweb | grep -m 1 "QoS"
   

   הפלט שיתקבל:

   QoS Class: Burstable
   

קיבולת משתנה ב-GKE

כדי לאפשר את התכונה Pod bursting, ‏ GKE מחשב את הקיבולת שניתן להשתמש בה לכל צומת באשכול. החישוב של צומת ספציפי מתבצע באופן הבא:

• אשכולות בטייס אוטומטי:

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

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

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

שיטות מומלצות לשימוש ב-bursting

כדאי להשתמש בשיטות הבאות עם Pod bursting:

• מגדירים את בקשות המשאבים כך שיהיו שוות למגבלות של כל Pod שמספק פונקציונליות קריטית בסביבה. הגישה הזו עוזרת לוודא שה-Pods האלה מקבלים את מחלקת Guaranteed איכות השירות (QoS) של Kubernetes.
• חשוב להקפיד להגדיר זיכרון זמני רק ב-Pods שיכולים להתמודד עם פינוי כש-Kubernetes צריך לפנות זיכרון בצומת.
• תמיד צריך לבקש מספיק זיכרון כדי להפעיל את ה-Pod. אל תסתמכו על פרצי זיכרון כדי לעמוד בדרישות האתחול.
• כדי למנוע מצבי פרץ של Pods שמתרחשים באופן עקבי בכפולות של בקשות ה-CPU שלהם, ועלולים לשבש עומסי עבודה קריטיים, מומלץ להשתמש בהפרדה של עומסי עבודה כדי להימנע מהצבת ה-Pods האלה לצד ה-Pods הקריטיים.

אופטימיזציה של קיבולת שניתנת להרחבה בצמתים של Autopilot

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

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

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

בדוגמה הבאה נעשה שימוש בפריסה עם התפרצות של Pods כדי להדגים איך התפרצות של Pods פועלת באשכולות GKE Autopilot:

• ‫Pod 1 מבקש 250m CPU ואין לו מגבלת CPU. ‫Pod 1 משתמש ב-100m CPU כדי לפעול.
• ‫Pod 2 מבקש 200m CPU ויש לו מגבלת CPU של 250m. הפוד השני משתמש ב-100m CPU כדי לפעול.

שני ה-Pods פועלים באותו צומת. הקיבולת הכוללת של ה-CPU שניתן להשתמש בה בבת אחת בצומת היא 450m CPU (סכום בקשות המשאבים). כל Pod משתמש רק ב-100m CPU כדי לפעול, מה שאומר שלצומת יש קיבולת זמנית זמינה של 250m.

כדאי לעיין בתרחישים הבאים שבהם יש עלייה חדה בתנועה:

• ‫Pod 1 צריך עוד 300m CPU: הוא יכול להשתמש ב-250m CPU, שהם הקיבולת הזמינה של burstable. לצומת אין יותר קיבולת זמינה.
• ל-Pod 2 נדרש מעבד נוסף של 150m: הוא יכול להשתמש במעבד נוסף של 150m. בצומת נשארת קיבולת זמינה של 100m CPU.
• ל-Pod 2 נדרשים עוד 200m CPU: הוא יכול להשתמש ב-150m CPU, כך שהשימוש הכולל יהיה 250m CPU ל-Pod 2. ל-Pod 2 יש מגבלת CPU של 250 מטר, והוא לא יכול לחרוג מהמגבלה הזו.

איך GKE מטפל ב-Pods שחורגים מהקיבולת הזמנית

אם ה-Pods עם יכולת התפרצות מנסים להשתמש ביותר משאבים מהקיבולת עם יכולת התפרצות בצומת, GKE מבצע את הפעולות הבאות:

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

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

שימוש ב-Pod bursting עם הקצאת קיבולת פנויה

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

הגדלת נפח האחסון הזמני של Pods באשכולות GKE Standard

בנוסף, באשכולות GKE Standard יש תמיכה ב-Pod bursting. כדי להשתמש בתכונה הזו, צריך להגדיר את המגבלות גבוהות יותר מהבקשות או להשמיט את המגבלות. עם זאת, באשכולות רגילים, צריך ליצור ולשנות את ההגדרות של מאגרי צמתים עם קיבולת משאבים מתאימה כדי לתמוך בשימוש חורג. כדי להפחית את העלויות הפוטנציאליות של תרמילי Pods עם יכולת התפרצות באשכולות רגילים, צריך לתכנן את הצמתים ולבצע bin-packing של ה-Pods בצורה מדויקת יותר, כי אתם משלמים על המכונות הווירטואליות הבסיסיות של Compute Engine.

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

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

• בדרך כלל, השימוש במשאבי הצמתים באשכולות Standard מגיע לסף ההוצאה של Kubernetes כי GKE לא מגביל אוטומטית את צריכת המשאבים אם לא מציינים מגבלות. לכן, יש סיכוי גבוה יותר ש-Pods שמתפרצים לזיכרון יופסקו על ידי node-pressure eviction של Kubernetes.

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

• איך מקצים קיבולת מחשוב נוספת להרחבת Pod מהירה
• איך מתאימים את גודל עומסי העבודה ב-GKE Standard בהתאם לצרכים
• פתרון בעיות באשכולות של Autopilot