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

טייס אוטומטי רגילה

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

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

מידע על ComputeClasses בהתאמה אישית

‫ComputeClasses מותאמים אישית הם משאבים מותאמים אישית של Kubernetes, שמאפשרים להגדיר עדיפויות ל-GKE כדי שיפעל לפיהן כשמוקצים צמתים להרצת עומסי העבודה. אתם יכולים להשתמש ב-ComputeClass מותאם אישית כדי:

• נותנים ל-GKE קבוצה של עדיפויות לפעולות רצופות כשמקצים צמתים, כל אחד עם פרמטרים ספציפיים כמו סדרת מכונות של Compute Engine או קיבולת משאבים מינימלית
• הגדרת ספי התאמה אוטומטית לעומס ופרמטרים להסרת צמתים שלא מנוצלים מספיק ואיחוד עומסי עבודה ביעילות בקיבולת מחשוב קיימת
• הנחיה ל-GKE להחליף באופן אוטומטי תצורות צמתים פחות מועדפות בתצורות צמתים מועדפות יותר, כדי להשיג ביצועים אופטימליים של עומס העבודה

כדי להבין את כל אפשרויות ההגדרה ואת האינטראקציה ביניהן ובין מצב GKE Autopilot ומצב GKE Standard, אפשר לעיין במאמר מידע על ComputeClasses בהתאמה אישית.

תמחור

המשאב המותאם אישית ComputeClass מסופק ללא עלות נוספת ב-GKE. השיקולים הבאים רלוונטיים לתמחור:

• מצב GKE Autopilot: החיוב מתבצע באמצעות מצב החיוב מבוסס-הצמתים. פרטים נוספים זמינים במאמר בנושא תמחור במצב אוטומטי.

• מצב Standard ב-GKE: אפשר לעיין בתמחור של מצב Standard.

מגבלות

השם של ComputeClass לא יכול להתחיל ב-gke או ב-autopilot.

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

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

• מפעילים את ממשק Google Kubernetes Engine API.
הפעלת Google Kubernetes Engine API
• אם רוצים להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
  הערה: אם כבר התקנתם את ה-CLI של gcloud, הקפידו להגדיר את compute/region המאפיין. אם אתם משתמשים בעיקר באשכולות אזוריים, הגדירו במקום זאת את compute/zone. אם מגדירים מיקום ברירת מחדל, אפשר להימנע משגיאות ב-CLI של gcloud כמו השגיאה הבאה: One of [--zone, --region] must be supplied: Please specify location. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

• מוודאים שיש לכם אשכול GKE קיים שפועלת בו גרסה ‎1.30.3-gke.1451000 ואילך. מידע נוסף זמין במאמר בנושא יצירת אשכול Autopilot.

• אם אתם משתמשים באשכול במצב רגיל, אתם צריכים לוודא שאתם עומדים באחת מהדרישות הבאות:

  • מפעילים מידרוג אוטומטי לפחות במאגר צמתים אחד באשכול.
  • אם באשכול הרגיל שלכם פועלת גרסה מוקדמת יותר מ-1.33.3-gke.1136000 והוא לא רשום לערוץ ההפצה המהירה, צריך להפעיל הקצאת משאבים אוטומטית של צמתים ברמת האשכול.

תרחיש לדוגמה ל-ComputeClasses

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

לדוגמה, נבחן את התרחיש הבא:

• המטרה שלכם היא לבצע אופטימיזציה של עלויות ההפעלה של עומסי העבודה
• עומסי העבודה שלכם סובלניים לתקלות ולא דורשים כיבוי מסודר או זמן ריצה ממושך
• כדי שהעומסים שלכם יפעלו בצורה אופטימלית, הם צריכים לפחות 64 vCPU
• אתם מוגבלים לסדרת המכונות N4 ב-Compute Engine

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

• העדיפות היא לצמתי N4 Spot עם לפחות 64 vCPU
• מאפשר ל-GKE לחזור לכל צומת N4 Spot, ללא קשר לקיבולת החישוב
• אם אין צמתים מסוג N4 Spot זמינים, מערכת GKE משתמשת בצמתים מסוג N4 על פי דרישה
• ההגדרה הזו אומרת ל-GKE להעביר את עומסי העבודה שלכם לצמתי Spot בכל פעם שהם זמינים שוב.

הגדרת ComputeClass במצב Autopilot

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

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

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: cost-optimized
spec:
  priorities:
  - machineFamily: n4
    spot: true
    minCores: 64
  - machineFamily: n4
    spot: true
  - machineFamily: n4
    spot: false
  activeMigration:
    optimizeRulePriority: true
  nodePoolAutoCreation:
    enabled: true

הגדרת ComputeClass במצב רגיל

באשכולות במצב GKE Standard, יכול להיות שתצטרכו לבצע הגדרה ידנית כדי לוודא שהתזמון של ה-Pods של ComputeClass יתבצע כמצופה. ההגדרה הידנית תלויה בשאלה אם מאגרי הצמתים נוצרים אוטומטית, באופן הבא:

• מאגרי צמתים שנוצרו באופן אוטומטי: לא נדרשת הגדרה ידנית. ‫GKE מבצע באופן אוטומטי את שלבי ההגדרה של ComputeClass. פרטים נוספים זמינים במאמר בנושא יצירה אוטומטית של מאגרי צמתים ו-ComputeClasses.
• מאגרי צמתים שנוצרו באופן ידני: נדרשת הגדרה ידנית. כדי לשייך את הצמתים ל-ComputeClass ספציפי, צריך להוסיף תוויות צמתים ו-taints של צמתים למאגרי הצמתים שנוצרו באופן ידני. פרטים נוספים מופיעים במאמר הגדרת מאגרי צמתים שנוצרו באופן ידני לשימוש ב-ComputeClass.

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

כדי לאפשר ל-GKE ליצור באופן אוטומטי מאגרי צמתים עבור ComputeClass, פועלים לפי השלבים הבאים:

1. באשכולות במצב רגיל שמופעלת בהם גרסה קודמת ל-1.33.3-gke.1136000 ושלא רשומים לערוץ ההפצה המהירה, צריך להפעיל הקצאת צמתים אוטומטית (NAP) ברמת האשכול.

2. שומרים את קובץ המניפסט לדוגמה הבא בשם compute-class.yaml:

   apiVersion: cloud.google.com/v1
   kind: ComputeClass
   metadata:
     name: cost-optimized
   spec:
     priorities:
     - machineFamily: n4
       spot: true
       minCores: 64
     - machineFamily: n4
       spot: true
     - machineFamily: n4
       spot: false
     activeMigration:
       optimizeRulePriority: true
     nodePoolAutoCreation:
       enabled: true
   

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

אפשר גם לציין סוג מכונה בהתאמה אישית מדויק בעדיפויות. כדי להשתמש בסוגי מכונות בהתאמה אישית, צריך להשתמש ב-GKE בגרסה 1.33.2-gke.1111000 ואילך. בדוגמה הבאה מוגדר ComputeClass שנותן עדיפות למכונות וירטואליות מסוג Spot עבור סוג המכונה המותאם אישית n4-custom-8-20480, ועובר למכונות וירטואליות על פי דרישה מאותו סוג אם הקיבולת של Spot לא זמינה:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: custom-machine-type
spec:
  priorities:
  - machineType: n4-custom-8-20480
    spot: true
  - machineType: n4-custom-8-20480
    spot: false
  nodePoolAutoCreation:
    enabled: true

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

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

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

   apiVersion: cloud.google.com/v1
   kind: ComputeClass
   metadata:
     name: cost-optimized
   spec:
     priorities:
     - machineFamily: n4
       spot: true
       minCores: 64
     - machineFamily: n4
       spot: true
     - machineFamily: n4
       spot: false
     activeMigration:
       optimizeRulePriority: true
   

2. יוצרים מאגר צמתים חדש עם שינוי גודל אוטומטי שמשתמש במכונות וירטואליות מסוג Spot ומקשרים אותו ל-ComputeClass:

   gcloud container node-pools create cost-optimized-pool \
       --location=LOCATION \
       --cluster=CLUSTER_NAME \
       --machine-type=n4-standard-64 \
       --spot \
       --enable-autoscaling \
       --max-nodes=9 \
       --node-labels="cloud.google.com/compute-class=cost-optimized" \
       --node-taints="cloud.google.com/compute-class=cost-optimized:NoSchedule"
   

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

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

3. יוצרים מאגר צמתים חדש עם התאמה אוטומטית לעומס (autoscaling) ומכונות וירטואליות לפי דרישה, ומקשרים אותו ל-ComputeClass:

   gcloud container node-pools create on-demand-pool \
       --location=LOCATION \
       --cluster=CLUSTER_NAME \
       --machine-type=n4-standard-64 \
       --enable-autoscaling \
       --max-nodes=9 \
       --num-nodes=0 \
       --node-labels="cloud.google.com/compute-class=cost-optimized" \
       --node-taints="cloud.google.com/compute-class=cost-optimized:NoSchedule"
   

כשפורסים Pods שמבקשים את ComputeClass הזה וצריך ליצור צמתים חדשים, מערכת GKE נותנת עדיפות ליצירת צמתים בcost-optimized-poolמאגר הצמתים. אם אי אפשר ליצור צמתים חדשים,‏ GKE יוצרת צמתים במאגר הצמתים on-demand-pool.

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

התאמה אישית של ספי התאמה אוטומטית לעומס (autoscaling) לצורך איחוד צמתים

כברירת מחדל, מערכת GKE מסירה צמתים שלא נעשה בהם שימוש מספיק, ומתזמנת מחדש את עומסי העבודה (workloads) בצמתים זמינים אחרים. אפשר להתאים אישית את הספים ואת התזמון שקובעים מתי צומת הופך למועמד להסרה באמצעות השדה autoscalingPolicy בהגדרת ComputeClass, כמו בדוגמה הבאה:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: cost-optimized
spec:
  priorities:
  - machineFamily: n4
    spot: true
    minCores: 64
  - machineFamily: n4
    spot: true
  - machineFamily: n4
    spot: false
  activeMigration:
    optimizeRulePriority: true
  autoscalingPolicy:
    consolidationDelayMinutes : 5
    consolidationThreshold    : 70

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

פריסת ComputeClass באשכול

אחרי שמגדירים ComputeClass, פורסים אותו באשכול:

kubectl apply -f compute-class.yaml

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

בקשה ל-ComputeClass בעומס עבודה

כדי לבקש ComputeClass בעומס עבודה, מוסיפים לבקשת הפריסה (manifest) בורר צמתים (node selector) עבור אותו ComputeClass, כמו בשלבים הבאים:

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

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: custom-workload
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: custom-workload
     template:
       metadata:
         labels:
           app: custom-workload
       spec:
         nodeSelector:
           cloud.google.com/compute-class: cost-optimized
         containers:
         - name: test
           image: registry.k8s.io/pause
           resources:
             requests:
               cpu: 1.5
               memory: "4Gi"
   

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

   kubectl apply -f cc-workload.yaml
   

כשפורסים את עומס העבודה הזה, GKE מוסיף אוטומטית סבילות (toleration) ל-Pods שמתאימה ל-taint של הצומת עבור ComputeClass המבוקש. הסבילות הזו מבטיחה שרק Pods שמבקשים את ComputeClass יפעלו בצמתים של ComputeClass.

עדכון של ComputeClass שנפרס

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

kubectl apply -f PATH_TO_FILE

מחליפים את הערך ב-PATH_TO_FILE בנתיב למניפסט ששיניתם. מוודאים שהערך בשדה name לא משתנה.

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

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

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

• מידע נוסף על ComputeClasses בהתאמה אישית
• החלת ComputeClasses מותאמים אישית על Pods כברירת מחדל