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

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

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

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

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

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

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

תמחור

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

מגבלות

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

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

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

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

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

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

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

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

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

  • העדיפות היא לצמתי N4 Spot עם לפחות 64 vCPU
  • מאפשר ל-GKE לחזור לצומת Spot N4 כלשהו, ללא קשר לקיבולת החישוב
  • אם אין צמתים מסוג 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, פועלים לפי השלבים הבאים:

  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.

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

עדכון של ComputeClass שהופעל

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

kubectl apply -f PATH_TO_FILE

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

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

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

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