מידע על ComputeClasses ב-GKE

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

המידע הזה מיועד לאנשים הבאים:

• מומחי Cloud Architect ומהנדסי פלטפורמות שרוצים לצמצם את התקורה שקשורה לניהול התשתית של האשכולות.
• מפעילי אפליקציות ומהנדסי SRE שרוצים להתמקד בהפעלת עומסי עבודה בלי לחשוב על התשתית הבסיסית.

מידע על ComputeClasses והתאמה אוטומטית של גודל האשכול

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

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

יכולות ותכונות ספציפיות של GKE זמינות רק עם ComputeClasses, כמו:

• Fallback compute priorities: הגדרה של כמה קבוצות של הגדרות תשתית ב-ComputeClass, עם עדיפות לפי ההעדפות שלכם. במהלך שינוי קנה המידה, אם ההגדרה המועדפת ביותר לא זמינה, GKE חוזר להגדרה הבאה.
• העברה פעילה לצמתים בעדיפות גבוהה יותר: אם האפשרות הזו מוגדרת, GKE מחליף באופן אוטומטי צמתים שנמצאים במקום נמוך יותר ברשימת העדיפויות של הגיבוי בצמתים שנמצאים במקום גבוה יותר ברשימה הזו, לאורך זמן. כתוצאה מכך, בסופו של דבר ה-Pods פועלים בצמתים המועדפים ביותר ב-ComputeClass, גם אם החומרה הזו לא הייתה זמינה כשיצרתם את עומס העבודה.
• ‫Autopilot ב-GKE Standard: הפעלת עומסי עבודה במצב Autopilot ב-GKE כדי להשתמש בתכונות של Autopilot, כמו פלטפורמת מחשוב שמותאמת לקונטיינרים וחיוב מבוסס-Pod, גם באשכולות Standard. ‫GKE מנהל את הצמתים ועומסי העבודה האלה, ומספק לכם את היתרונות של מצב Autopilot בכל אשכול.

היתרונות של ComputeClasses

היתרונות של ComputeClasses לאדמינים ולמפעילים של פלטפורמות כוללים:

• גמישות, יעילות וזמינות משופרות של קיבולת המחשוב: ComputeClasses מרחיבים את היכולות של התאמה אוטומטית לעומס (scaling) של אשכולות GKE. תכונות של ComputeClass כמו סדרי עדיפויות של חזרה לאחור ופרמטרים של איחוד צמתים יכולות להקטין את הסיכון של פודים שנתקעים בסטטוס 'בהמתנה' ולהגדיל את מגוון האפשרויות שבהן אפשר להשתמש כדי לשנות את גודל הצמתים.
• הגדרה דקלרטיבית ברמת הפלטפורמה: באמצעות ComputeClasses, מהנדסי פלטפורמה יכולים לתאר באופן דקלרטיבי את תצורות הצמתים עבור סוגים שונים של עומסי עבודה. ההתאמה האוטומטית לעומס ב-GKE מנהלת את היצירה וההגדרה של צמתים ומאגרי צמתים. אתם יכולים לשלב את ComputeClasses בצינורות עיבוד הנתונים של CI/CD כדי לשמור על עקביות בתשתית המוקצית בפלטפורמה.
• פחות תקורה ניהולית: בעזרת ComputeClasses אפשר לנהל בקלות רבה יותר את התשתית ואת עומסי העבודה בקנה מידה נרחב. מהנדסי פלטפורמה מצהירים על סוגי תשתית, ומפעילי אפליקציות בוחרים סוג רלוונטי בעומס עבודה. ‫GKE מנהל את קנה המידה, את הגדרת החומרה של הצמתים ומחיל taints,‏ tolerations ותוויות.

מידע על המשאב המותאם אישית ComputeClass

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

במניפסט לדוגמה הבא מוגדר ComputeClass בשם n4:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: n4
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineFamily: n4
  - machineFamily: n2
  whenUnsatisfiable: DoNotScaleUp

כש-Pod בוחר ב-ComputeClass הזה, GKE מבצע את הפעולות הבאות כשהוא יוצר צמתים חדשים:

1. ‫GKE יוצר צמתים שמשתמשים בסדרת המכונות N4.
2. אם סדרת מכונות N4 לא זמינה, GKE יוצר צמתים שמשתמשים בסדרת מכונות N2 במקום זאת.
3. אם סדרת המכונות N2 לא זמינה, GKE ממתין עד שהמשאבים יהיו זמינים כדי לתזמן את ה-Pod.

אתם יכולים לשלוט בהגדרות שונות של הצמתים באמצעות ComputeClasses, כולל מאיצים, הגדרות מערכת של הצמתים, מיקומי הצמתים והתנהגות הגיבוי של GKE כשמשאבי חומרה לא זמינים. למידע נוסף על כל ההגדרות הזמינות ל-ComputeClasses, קראו את המאמר ComputeClass CustomResourceDefinition.

בחירת ComputeClass בעומסי עבודה

כדי להשתמש ב-ComputeClass לעומס עבודה ב-GKE, בוחרים את ה-ComputeClass במניפסט של עומס העבודה באמצעות בורר צמתים לתווית cloud.google.com/compute-class.

במניפסט הפריסה הבא נבחר ComputeClass:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloweb
  labels:
    app: hello
spec:
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      nodeSelector:
        # Replace with the name of a compute class
        cloud.google.com/compute-class: COMPUTE_CLASS 
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: "250m"
            memory: "1Gi"

מחליפים את COMPUTE_CLASS בשם של ComputeClass שקיים באשכול. לדוגמה, אתם יכולים לציין את n4 ComputeClass מהקטע מידע על המשאב המותאם אישית ComputeClass או את autopilot ComputeClass המובנה.

הגדרת צומת במפרטים של עומסי עבודה

באשכולות GKE Autopilot ובאשכולות GKE Standard עם הקצאת צמתים אוטומטית, אפשר להשתמש בבוררי צמתים בתרמילי ה-Pod כדי ליצור צמתים עם מאפיינים ספציפיים כמו משפחות מכונות, VM במודל Spot או מעבדי GPU ו-TPU. בעזרת ComputeClasses אתם יכולים להגדיר את הדרישות האלה באופן מרוכז, במקום להוסיף בוררים נפרדים לכל עומס עבודה.

מידע על החלת ComputeClasses כברירת מחדל

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

בטבלה הבאה מתוארות ההשפעות של הגדרת ComputeClass כברירת המחדל למרחב שמות או לאשכול:

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

העברה פעילה ב-ComputeClasses שמוגדרים כברירת מחדל

אם ComputeClass שמשמש כברירת מחדל ברמת מרחב השמות או ברמת האשכול, השדה activeMigration.optimizeRulePriority מוגדר ל-true, יכול להיות שתראו את ההשפעות הבאות:

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

‫ComputeClasses שמוגדרים כברירת מחדל ברמת האשכול

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

spec:
  whenUnsatisfiable: ScaleUpAnyway
  nodePoolAutoCreation:
    enabled: true

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

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

• כדי למנוע מצב שבו Pods נתקעים במצב Pending, צריך להגדיר את השדה spec.whenUnsatisfiable לערך ScaleUpAnyway. הערך הזה מאפשר ל-GKE ליצור צמתים גם אם ה-Pods מבקשים משפחות של מכונות Compute Engine שלא נכללות בכללי העדיפות של מחלקת ברירת המחדל ברמת האשכול. אם רוצים לאלץ את ה-Pods האלה להשתמש במשפחות המכונות שנמצאות ב-ComputeClass שמוגדר כברירת מחדל, צריך להגדיר את השדה הזה לערך DoNotScaleUp.
• כדי להגביל את השינויים ב-default ComputeClass, משתמשים ב-RBAC ClusterRole כדי להגביל את הפעולות update,‏ patch,‏ delete ו-create במשאב ComputeClass שנקרא default.
• כדי לשנות את הפרמטרים של איחוד הצמתים שמוגדרים כברירת מחדל ב-Cluster Autoscaler, משתמשים בשדה spec.autoscalingPolicy במפרט של ComputeClass. הפרמטרים שאתם מציינים בשדה הזה ב-ComputeClass שמוגדר כברירת מחדל ברמת האשכול חלים על כל הצמתים באשכול. מידע נוסף זמין במאמר בנושא הגדרת פרמטרים של התאמה אוטומטית לעומס לאיחוד צמתים.

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

• שיטות מומלצות לשימוש ב-ComputeClasses
• מידע ולמידה על ComputeClasses מובנים
• מידע ולמידה על ComputeClasses בהתאמה אישית
• קריאת ComputeClass CustomResourceDefinition
• פריסת ComputeClass ובחירה שלו בעומס עבודה