הגדרת Pod bursting ב-GKE

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

מה זה Bursting?

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

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

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

למידע נוסף על התהליך הזה ב-GKE, קראו את הקטע קיבולת מתפרצת (burstable) ב-GKE בדף הזה.

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

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

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

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

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

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

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

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

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

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

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

זמינות של Bursting ב-GKE

עומסי עבודה יכולים לעבור למצב Burst במצבים הבאים:

מגבלות

• עומסי עבודה ב-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: המיקום של האשכול.

איך מוודאים שהאשכול תומך ב-bursting

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

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

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

‫GKE פורס את ה-DaemonSet של efficiency-daemon כשאשכול 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 בצומת.
     • מצב רגיל: קיבולת שלא נוצלה במשאבי הצומת.
   • ‫spec.nodeSelector ו-spec.tolerations: אופציונלי. מוסיפים את השדות האלה עם תוויות בהתאמה אישית כמו pod-type: "non-critical" כדי להורות ל-GKE ליצור צמתים חדשים להרצת הפודים הניתנים להרחבה. ‫GKE מחיל טאג'ים על הצמתים החדשים האלה כדי למנוע מפודים אחרים, כמו עומסי עבודה קריטיים, לפעול באותם צמתים. ב-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
   

קיבולת מתפרצת (burstable) ב-GKE

כדי לאפשר את ההתפרצות של Pod, ‏GKE מחשב את הקיבולת המתפרצת (burstable) לכל צומת באשכול. החישוב של צומת ספציפי הוא:

• אשכולות Autopilot:

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

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

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

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

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

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

אופטימיזציה של קיבולת מתפרצת (burstable) בצומתי Autopilot

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

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

דוגמה לאופן שבו פועל ה-bursting

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

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

שני ה-Pods פועלים באותו צומת. הקיבולת המתפרצת הכוללת בצומת היא 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 יש מגבלת מעבד של 250m, והוא לא יכול לחרוג ממנה.

איך GKE מטפל ב-Pods שחורגים מהקיבולת המתפרצת (burstable)

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

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

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

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

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

התפרצות פודים באשכולות GKE Standard

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

באשכולות רגילים:

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

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

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

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