האצת הפעלת האפליקציה באמצעות הגברת מהירות ההפעלה של המעבד

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

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

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

יתרונות

היתרונות של שימוש בהגברת מהירות ההפעלה של המעבד:

• הפעלה מהירה יותר: האצת האתחול של אפליקציות עתירות משאבים, כמו אלה שנכתבו ב-Java, ב-Node.js או ב-Python.
• יעילות בעלויות: הימנעות מהקצאת יתר של CPU לפעולה במצב יציב, תוך עמידה בדרישות ההפעלה. פעולה במצב יציב היא התקופה שמתחילה אחרי שאפליקציה מסיימת את ההפעלה הראשונית שלה והשימוש במשאבים שלה מתייצב.
• ללא שיבושים: אפשר להקטין את המשאבים לרמות הבסיסיות באמצעות שינוי גודל של Pod ב-Kubernetes (IPPR) בלי להפעיל מחדש את הקונטיינרים.
• פחות מאמץ ידני: צמצום בזבוז המשאבים והמאמץ הידני שנדרש כדי להתאים את גודל עומסי העבודה.

דרישות

כדי להשתמש בהגדרה 'הגדלת מהירות ההפעלה של CPU', אתם צריכים לעמוד בדרישות הבאות:

• גרסת GKE: צריך להשתמש בגרסה 1.36.0-gke.4447000 ואילך גם באשכולות Standard וגם באשכולות Autopilot.
• ‫VPA enabled: הפעלת התאמה אנכית של קבוצות Pod לעומס באשכולות רגילים. ב-GKE,‏ VPA מופעל כברירת מחדל באשכולות Autopilot. אפשר להשתמש ב-VPA באופן בלעדי כדי להגביר את מהירות ההפעלה של ה-CPU על ידי בחירת מצב עדכון ספציפי. כדי להפעיל ולהגדיר VPA, אפשר לעיין במאמר הגדרה אוטומטית של בקשות למשאבי Pod.
• סוג עומס העבודה: שימוש בבקר, כמו Deployment או StatefulSet, כדי לנהל את עומס העבודה.
• קיבולת הצומת: מוודאים שלקלאסטרים רגילים יש קיבולת מספקת ל-Pod המשופר. אם הקיבולת לא מספיקה, GKE מגבילה את הבקשה להגברת ה-Pod כך שתתאים לצומת.

איך פועל שיפור ההפעלה של המעבד

מידע נוסף על מחזור החיים של ההגדלה ועל האופן שבו ההגדלה של משאבי ה-CPU לצורך הפעלה מהירה מחשבת את העלייה במשאבים זמין במאמר איך פועלת ההגדלה של משאבי ה-CPU לצורך הפעלה מהירה.

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

לפני שמתחילים, מוודאים שבחרתם את Cloud de Confiance by S3NS הפרויקט שמכיל את האשכול שרוצים להגדיל, וביצעתם את המשימות הבאות:

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

• מגדירים את ה-CLI של gcloud כך שישתמש בפרויקט שבחרתם:

  gcloud config set project PROJECT_ID
  

  מחליפים את PROJECT_ID במזהה הפרויקט.

• מוודאים שיש לכם אשכול GKE קיים. אם אין לכם, אפשר לעיין במאמר בנושא יצירת אשכול.

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות להפעלה ולשימוש בהגברת מהירות ההפעלה של מעבד (CPU), צריך לבקש מהאדמין להקצות לכם בפרויקט את תפקידי ה-IAM הבאים:

• אדמין ב-Kubernetes Engine (roles/container.admin)
• ‫Kubernetes Engine Developer (roles/container.developer)

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

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

הפעלת שיפור הביצועים של המעבד בזמן ההפעלה

כדי להפעיל את התכונה 'הגברת מהירות ההפעלה של CPU', מוסיפים בלוק הגדרות startupBoost למניפסט של VerticalPodAutoscaler ‏ (VPA). אתם יכולים להגדיר את ההגדלה כך שתחול על כל המאגדים ב-Pod, או לטרגט מאגדים ספציפיים עם הגדלות ספציפיות של משאבים.

הגדרת בוסט ברמת ה-Pod

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

כדי להגדיר הגברה ברמת ה-Pod, משתמשים באחת מהאפשרויות הבאות.

אפשרות א': הפעלת האצת ההפעלה והשבתת מצב העדכון של VPA

אפשר להשתמש באפשרות הזו כדי להסתמך על VPA באופן בלעדי לשיפור ההפעלה של ה-CPU, בלי להפעיל המלצות רגילות של VPA. בדוגמה הבאה מוגדר מקדם הכפלה של 2 למעבד, והוא נשמר למשך 10 שניות אחרי שה-Pod מגיע למצב Ready:

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "Off"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
      durationSeconds: 10

אפשרות ב': גם מצב העדכון של VPA וגם מצב ההפעלה של Startup Boost מופעלים

אם רוצים ש-GKE ינהל את ההגדרה של האצת ההפעלה ואז ימשיך להתאים באופן אוטומטי את בקשות המשאבים של ה-Pod על סמך השימוש השוטף, צריך להשתמש באפשרות הזו. בדוגמה הבאה מופעלת האפשרות 'הגדלת מהירות ההפעלה' והשדה updateMode מוגדר ל-InPlaceOrRecreate:

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "InPlaceOrRecreate"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
      durationSeconds: 10

הגדרת הגברה ברמת מאגר התגים

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

כדי להגדיר הגברה ברמת מאגר התגים, משתמשים באחת מהאפשרויות הבאות.

אפשרות א': הגדלת נפח של מאגר ספציפי (הפעלת VPA מושבתת)

האפשרות הזו מאפשרת להגדיל את כמות המשאבים של מאגר אחד בלי לשנות את בקשות המשאבים של שאר המאגרים ב-Pod. בדוגמה הבאה של מניפסט נוספים שני מעבדי vCPU לבקשת הבסיס של קונטיינר בשם boosted-container-name:

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: "boosted-container-name"
      mode: "Off"
      startupBoost:
        cpu:
          type: "Quantity"
          quantity: "2"

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

אם הגדרתם הגברה ברמת ה-Pod אבל אתם רוצים להחריג קונטיינר ספציפי, אתם יכולים להשתמש באפשרות הזו. בדוגמה הבאה של מניפסט, מקדם ההכפלה של ה-CPU הוא 2 לכל ה-Pod, אבל ההגדלה מושבתת לקונטיינר בשם disable-cpu-boost-for-this-container, כי המקדם שלו מוגדר כ-1:

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "InPlaceOrRecreate"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
  resourcePolicy:
    containerPolicies:
    - containerName: "disable-cpu-boost-for-this-container"
      startupBoost:
        cpu:
          type: "Factor"
          factor: 1

אימות של שיפור ההפעלה של המעבד

כדי לוודא שה-Pods מקבלים את התוספת, בודקים את הגדרת ה-VPA, את בקשות המשאבים של ה-Pod, את ההערות של ה-Pod ואת אירועי ה-VPA.

אימות ההגדרה של VPA

כדי לבדוק את הפרטים של אובייקט VerticalPodAutoscaler, מריצים את הפקודה הבאה:

kubectl describe vpa VPA_NAME

מחליפים את VPA_NAME בשם של אובייקט ה-VPA.

בדיקת בקשת ה-CPU המוגבר ב-Pod

כדי לבדוק את בקשות המשאבים הנוכחיות של ה-Pod, מריצים את הפקודה הבאה:

kubectl describe pod POD_NAME

מחליפים את POD_NAME בשם ה-Pod.

אימות ההגברה של המעבד באמצעות הערות של Pod

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

kubectl get pod POD_NAME --output yaml

בקטע metadata.annotations, מחפשים הערה בפורמט vpaCpuStartupBoost/CONTAINER_NAME. לדוגמה:

metadata:
  annotations:
    vpaCpuStartupBoost/slow-starter: '{"requests":{"cpu":"50m","memory":"64Mi"},"limits":{"cpu":"200m","memory":"128Mi"}}'

הפלט של הפקודה מציין אחת מתוצאות האימות הבאות:

• הגברת הפוסט הצליחה: ההערה vpaCpuStartupBoost/CONTAINER_NAME מופיעה בפוסט.
• ההדגשה לא הצליחה: ההערה חסרה לגמרי. המשמעות היא שבקרת הכניסה התעלמה מההגדלה, אולי בגלל מגבלות על קיבולת הצומת או מגבלות על משאבי Autopilot.

בדיקה של אירועי הקטנת קנה מידה

כדי לוודא ש-GKE הקטין בהצלחה את הקצאת משאבי ה-CPU בחזרה לרמת הבסיס, מריצים את הפקודה הבאה כדי לבדוק את אירועי האשכול:

kubectl get events --field-selector reason=InPlaceResizedByVPA

הפלט של הפקודה מציין אחת מתוצאות האימות הבאות:

• ביטול מוצלח של ההגדלה: מופיע אירוע InPlaceResizedByVPA עם הודעה שמציינת שהגודל של ה-Pod שונה במקום על ידי VPA Updater. כך אפשר לוודא שבקשת ה-CPU חזרה לערך הבסיסי שלה בלי להפעיל מחדש את הקונטיינר.
• ביטול ההדגשה לא הצליח: ההערה vpaCpuStartupBoost/CONTAINER_NAME נשארת ב-Pod הרבה אחרי שתוקף ההדגשה אמור היה לפוג, ואין אירוע InPlaceResizedByVPA.

שיטות מומלצות ומגבלות

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

אינטראקציות עם התאמה אופקית של קבוצות Pod לעומס

אם אתם משתמשים בhorizontal Pod autoscaler‏ (HPA) עם CPU startup boost, כדאי לפעול לפי ההנחיות הבאות:

• הגדרת בדיקות תקינות: צריך להגדיר readinessProbe לעומסי העבודה.
• הגדרת השהיה של משך הזמן: צריך להגדיר את הפרמטר durationSeconds לערך 0. ההגדרה הזו מונעת מ-HPA להרחיב את האפליקציה לפני הזמן בגלל ניצול גבוה של המעבד במהלך ההפעלה.

התאמה לעומס (autoscaling) באשכולות ולולאות של הוצאת נתונים

אם אתם משתמשים במידרוג אוטומטי של אשכולות באשכולות GKE Standard, כדאי לשים לב להתנהגויות הבאות של הצמתים:

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

הפעלה מחדש של מאגר תגים

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

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

הסרת המשאבים

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

• אין צורך למחוק משאבי Kubernetes.
• אם עדיין נדרשים אובייקט VerticalPodAutoscaler או בקרי עומסי עבודה (כמו Deployments או StatefulSets) לפעולות במצב יציב, אל תמחקו אותם.

• אם אתם לא צריכים את ההגדרה 'הגברת מהירות ההפעלה של המעבד', אתם יכולים להשבית רק את ההגדרה הזו באחת מהשיטות הבאות, בהתאם להיקף:

  • השבתת ההגדרה 'שיפור' לכל עומס העבודה: מוחקים את הבלוק startupBoost ממפרט האובייקט VerticalPodAutoscaler ומחילים את המניפסט המעודכן על האשכול.

  • השבתת ההגדלה של משאבי המעבד עבור קונטיינר ספציפי: כדי להחריג קונטיינר ספציפי מהגדלה ברמת ה-Pod, מוסיפים מדיניות קונטיינר בקטע containerPolicies ומגדירים את מקדם הכפל של המעבד ל-1.

      startupBoost:
        cpu:
          type: "Factor"
          factor: 1
    

    מידע נוסף מופיע במאמר בנושא הגדרת הגברה ברמת מאגר התגים.

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

• התאמה של בקשות למשאבי קונטיינר ומגבלות
• הגדרת התאמה אופקית של קבוצות Pod לעומס
• התאמת עומסי עבודה בהיקף נרחב