מידע על ComputeClasses ב-GKE

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

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

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

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

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

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

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

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

היתרונות של ComputeClasses

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

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

‫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 ליצור צמתים גם אם הפודים מבקשים משפחות של מכונות Compute Engine שלא נכללות בכללי העדיפות של מחלקת ברירת המחדל ברמת האשכול. אם רוצים להכריח את ה-Pods האלה להשתמש בסוגי המכונות שנמצאים ב-ComputeClass שמוגדר כברירת מחדל, צריך להגדיר את השדה הזה ל-DoNotScaleUp.
  • כדי להגביל את השינויים ב-default ComputeClass, משתמשים ב-RBAC ClusterRole כדי להגביל את הפעולות update,‏ patch,‏ delete ו-create במשאב ComputeClass שנקרא default.
  • כדי לשנות את פרמטרי ברירת המחדל של איחוד הצמתים של Cluster Autoscaler, משתמשים בשדה spec.autoscalingPolicy במפרט ComputeClass. הפרמטרים שמציינים בשדה הזה ב-ComputeClass שמוגדר כברירת מחדל ברמת האשכול חלים על כל הצמתים באשכול. מידע נוסף זמין במאמר הגדרת פרמטרים של שינוי גודל אוטומטי לאיחוד צמתים.

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