מידע על ComputeClasses ב-GKE

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

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

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

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

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

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

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

  • Fallback compute priorities: define multiple sets of infrastructure configurations in a ComputeClass, prioritized based on your preferences. במהלך שינוי הגודל, אם ההגדרה המועדפת ביותר לא זמינה, GKE חוזר להגדרה הבאה.
  • העברה פעילה לצמתים בעדיפות גבוהה יותר: אם ההגדרה הזו מופעלת, GKE מחליף באופן אוטומטי צמתים שנמצאים בתחתית רשימת העדיפויות של הגיבוי בצמתים שנמצאים בראש הרשימה. כתוצאה מכך, בסופו של דבר, ה-Pods יפעלו בצמתים המועדפים ביותר ב-ComputeClass, גם אם החומרה הזו לא הייתה זמינה כשנוצר עומס העבודה.
  • ‫Autopilot ב-GKE Standard: הפעלת עומסי עבודה במצב Autopilot ב-GKE כדי להשתמש בתכונות של Autopilot כמו פלטפורמת מחשוב שמותאמת לקונטיינרים וחיוב מבוסס-Pod, גם באשכולות Standard. ‫GKE מנהל את הצמתים ועומסי העבודה האלה, ומספק לכם את היתרונות של מצב Autopilot בכל אשכול.

היתרונות של ComputeClasses

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

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

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

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

בדוגמה הבאה של מניפסט מוגדר 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 במניפסט של עומס העבודה באמצעות node selector (בורר צמתים) עבור התווית 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 מהקטע About the ComputeClass custom resource או את autopilot built-in ComputeClass.

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

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

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

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

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

ההשפעות של ComputeClasses שמוגדרים כברירת מחדל
ברירת מחדל ברמת מרחב השמות
  • ‫GKE מחיל את ComputeClass רק על Pods במרחב שמות ספציפי.
  • ‫GKE משנה את ה-Pods כדי להוסיף סלקטור לבחירת צומת עבור מחלקת ברירת המחדל ברמת מרחב השמות.
  • מערכת GKE מרחיבה רק צמתים שיש להם תוויות צמתים וכתמי צמתים עבור ComputeClass, בדומה לכל מחלקת מחשוב אחרת.
  • ‫GKE מוסיף תוויות צמתים וכתמי צמתים לצמתים ש-GKE יוצר עבור מחלקת ברירת המחדל ברמת מרחב השמות.
ברירת מחדל ברמת האשכול
  • ‫GKE מחיל את ComputeClass על Pods בכל מרחב שמות.
  • ‫GKE מחיל את ComputeClass רק על Pods שלא קיים עבורם סלקטור של ComputeClass.
  • ‫GKE לא משנה את המפרטים של ה-Pod כדי להוסיף סלקטור של צומת עבור מחלקת ברירת המחדל ברמת האשכול.
  • צומתי GKE מתרחבים אם הם עומדים באחד מהתנאים הבאים:
    • לצמתים אין תוויות ואין כתמים עבור מחלקה שונה של מחשוב.
    • לצמתים יש תווית צומת cloud.google.com/compute-class: default.
  • ‫GKE מוסיף את התווית cloud.google.com/compute-class: default של הצומת לצמתים ש-GKE יוצר עבור מחלקת ברירת המחדל ברמת האשכול. ‫GKE לא מוסיף כתמי צומת לצמתים האלה.
  • אם מעדכנים אשכול Autopilot לשימוש במחלקת מחשוב בהתאמה אישית כברירת מחדל ברמת האשכול, GKE לא יפעיל Pods בפלטפורמת המחשוב שמותאמת לקונטיינרים של Autopilot כברירת מחדל. ב-GKE מגרסה 1.34.1-gke.1829001 ואילך, אפשר להשתמש בפלטפורמת המחשוב Autopilot עבור Pods ספציפיים על ידי הוספת cloud.google.com/compute-class: autopilot node selector ל-Pods האלה.

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

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

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

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

‫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 שמוגדר כברירת מחדל ברמת האשכול חלים על כל הצמתים באשכול. מידע נוסף זמין במאמר בנושא הגדרת פרמטרים של שינוי גודל אוטומטי לאיחוד צמתים.

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