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

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

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

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

יתרונות

השימוש בהגברת מהירות ההפעלה של המעבד (CPU) מספק את היתרונות הבאים:

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

דרישות

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

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

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

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

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

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

• מפעילים את ממשק Google Kubernetes Engine API.
הפעלת Google Kubernetes Engine API
• כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את gcloud CLI. אם התקנתם בעבר את ה-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 באותו אופן. אפשר להגדיר את ההגדלה של מהירות העיבוד של ה-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 מופעלים

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

הסרת המשאבים

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

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

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

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

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

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

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

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

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