הגדרת Pod bursting ב-GKE

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

מהי התפרצות?

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

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

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

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

היתרונות של Pod bursting

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

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

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

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

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

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

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

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

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

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

זמינות של Bursting ב-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 ממחלקות מחשוב מוגדרות מראש.
• ‫Pods של Autopilot שלא מבקשים מחלקת מחשוב.

‫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
   

   המניפסט הזה כולל את השדות הבאים להפעלת התפרצות (bursting):

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

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

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

שיטות מומלצות לשימוש בתכונה 'הצגת מודעות בהיקף נרחב'

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

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

אופטימיזציה של קיבולת שניתנת להרחבה בצמתים של 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. ‫Pod 2 משתמש ב-100m CPU כדי לפעול.

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

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

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

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

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

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

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

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

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

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