מידע על Balanced ו-Scale-Out ComputeClasses באשכולות של Autopilot

אתם יכולים להשתמש ב-ComputeClasses‏ Balanced ו-Scale-Out באשכולות של Google Kubernetes Engine (GKE) Autopilot כדי להריץ עומסי עבודה שדורשים קיבולת מחשוב נוספת או הגדרות מיוחדות של מעבד (CPU). הדף הזה מיועד לאדמינים של אשכולות שרוצים אפשרויות מחשוב גמישות יותר מאלה שמוגדרות כברירת מחדל באשכול Autopilot.

סקירה כללית על Balanced ו-Scale-Out ComputeClasses

כברירת מחדל, Pods באשכולות GKE Autopilot פועלים בפלטפורמת מחשוב שמותאמת לקונטיינרים. הפלטפורמה הזו מתאימה לעומסי עבודה (workloads) למטרות כלליות, כמו שרתי אינטרנט ומשימות באצווה בעצימות בינונית. פלטפורמת המחשוב שמותאמת לקונטיינרים מספקת הגדרת חומרה אמינה, ניתנת להתאמה וחסכונית, שיכולה להתמודד עם הדרישות של רוב עומסי העבודה.

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

רק באשכולות Autopilot, ‏GKE מספק את ה-ComputeClasses הבאים, שמאפשרים להריץ Pods שצריכים יותר גמישות מפלטפורמת המחשוב שמותאמת לקונטיינרים כברירת מחדל:

  • ‫Balanced: מספקת קיבולת מקסימלית גבוהה יותר של מעבד וזיכרון בהשוואה לפלטפורמת המחשוב שמותאמת לקונטיינרים.
  • ‫Scale-Out: משביתה את ה-SMT (ריבוי הליכים בו-זמני) ומותאמת להרחבה אופקית בהתאם לעומס (scale out).

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

‫ComputeClasses בהתאמה אישית לגמישות נוספת

אם ה-ComputeClasses מסוג Balanced או Scale-Out באשכולות Autopilot לא עומדים בדרישות של עומס העבודה, אתם יכולים להגדיר ComputeClasses משלכם. פורסים משאבים בהתאמה אישית של ComputeClass Kubernetes באשכולות עם קבוצות של מאפייני צמתים, שבהם GKE משתמש כדי להגדיר צמתים חדשים באשכול. לדוגמה, באמצעות ה-ComputeClasses האלה בהתאמה אישית אתם יכולים לפרוס עומסי עבודה באותה חומרה כמו ה-ComputeClasses מסוג Balanced או Scale-Out בכל אשכול של GKE Autopilot או Standard. מידע נוסף זמין במאמר מידע על עומסי עבודה במצב אוטומטי ב-GKE Standard.

תמחור

פודים שמשתמשים ב-ComputeClasses מסוג Balanced או Scale-Out מחויבים על סמך המק"טים הבאים:

למידע נוסף, קראו את התמחור של GKE.

פרטים טכניים על Balanced ו-Scale-Out

בקטע הזה מתוארים סוגי המכונות ותרחישי השימוש של הסדרות Balanced ו-Scale-Out. אם לא תבקשו ComputeClass ב-Pods, כברירת מחדל Autopilot ימקם את ה-Pods בפלטפורמת המחשוב שמותאמת לקונטיינרים. פלטפורמת המחשוב שמותאמת לקונטיינרים משתמשת בכל אחת מסדרות המכונות ממשפחת המכונות לשימוש כללי של Compute Engine, עם העדפה לסוגי מכונות שניתן לשנות את הגודל שלהן. מכיוון שסדרת המכונות הבסיסית לא קבועה, הביצועים לכל מעבד משתנים בהתאם לסדרת המכונות שבה GKE מתזמן את ה-Pod.

בנוסף, התזמון של Pods עם אחסון מתמיד מצורף תלוי בתאימות של סוג הדיסק:

  • דיסקים לאחסון מתמיד מדור קודם: Pods עם דיסקים לאחסון מתמיד מדור קודם (כמו pd-standard) פועלים רק בסדרות מכונות שתומכות בהם, כמו E2.
  • ‫Hyperdisk: פודים עם אחסון מהדור הבא (כמו hyperdisk-balanced) פועלים בסדרות מכונות חדשות יותר, כמו C3.
  • מצב המתנה: אם מגדירים במפורש Pod לפעול בסדרת מכונות חדשה יותר (לדוגמה, באמצעות בוררי צמתים כדי לבקש צמתים של C3, או על ידי הגדרת ComputeClass בהתאמה אישית) אבל מצרפים Persistent Disk מדור קודם, ה-Pod נשאר במצב Pending ללא הגבלת זמן. זה קורה כי GKE לא מוצא צומת שעומד גם באילוצים של סוג המכונה וגם באילוצים של תאימות הדיסק. כשבוחרים באופן מפורש סדרת מכונות, אתם אחראים לוודא את התאימות של PersistentVolume ושל הדיסק.

בטבלה הבאה מופיעה סקירה טכנית של ComputeClasses ב-Balanced וב-Scale-Out.

‫ComputeClasses מסוג Balanced ו-Scale-Out
Balanced

מספקת יותר קיבולת מעבד וקיבולת זיכרון מאשר הערכים המקסימליים של פלטפורמת המחשוב שמותאמת לקונטיינרים. מספק פלטפורמות נוספות של מעבדים (CPU) ואת היכולת להגדיר פלטפורמת CPU מינימלית לפודים, כמו Intel Ice Lake או גרסאות חדשות יותר.

  • מעבדים זמינים: AMD EPYC Milan, ‏ Intel Ice Lake, ‏ Intel Cascade Lake
  • ארכיטקטורה זמינה: amd64
  • סדרת מכונות: N2 (מעבדי Intel) או סדרת מכונות N2D (מעבדי AMD).

משתמשים במחלקה Balanced לאפליקציות כמו:

  • שרתי אינטרנט
  • מסדי נתונים בינוניים עד גדולים
  • שמירה במטמון
  • סטרימינג והצגת מדיה
  • אחסון ב-Hyperdisk Throughput וב-Hyperdisk Extreme
Scale-Out

מספק מחשוב של שרשור יחיד לכל ליבה וקנה מידה אופקי.

  • מעבדים זמינים: Ampere Altra Arm או AMD EPYC Milan
  • ארכיטקטורה זמינה: arm64 או amd64
  • ‫סדרת מכונות: ‏T2A ‏(Arm) או T2D ‏(x86).
  • תכונות נוספות:
    • ה-SMT מושבת, כך ש-vCPU אחד שווה לליבה פיזית אחת.
    • מהירות שעון מקסימלית של 3.5GHz.

משתמשים במחלקה Scale-Out לאפליקציות כמו:

  • שרתי אינטרנט
  • מיקרו-שירותים (microservices) בקונטיינרים
  • עיבוד של יומני נתונים
  • אפליקציות Java בקנה מידה גדול
  • אחסון ב-Hyperdisk Throughput

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

כדי להשתמש ב-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, כמו Balanced או Scale-Out. אפשר לבחור רק ComputeClass אחד בעומס עבודה.

כשפורסים את עומס העבודה, GKE מבצע את הפעולות הבאות:

  • מקצה באופן אוטומטי צמתים שמגובים על ידי ההגדרות שצוינו כדי להריץ את הפודים.
  • מוסיף באופן אוטומטי תוויות וtaints לצמתים החדשים, כדי למנוע תזמון של Pods אחרים בצמתים האלה. הכתמים ייחודיים לכל ComputeClass. אם בוחרים גם ארכיטקטורת מעבד (CPU),‏ GKE מוסיף טאיינט נפרד שייחודי לארכיטקטורה הזו.
  • מוסיף באופן אוטומטי טולרציות שתואמות לטיינטים שהוחלו על ה-Pods שנפרסו, וכך מאפשר ל-GKE למקם את ה-Pods האלה בצמתים החדשים.

לדוגמה, אם מבקשים את ComputeClass Scale-Out עבור Pod:

  1. במצב Autopilot, המערכת מוסיפה ל-Scale-Out טיינט ספציפי לצמתים האלה.
  2. מצב Autopilot מוסיף עמידות לטעינה הזו לפודים של Scale-Out.

פודים שלא מבקשים Scale-Out לא יקבלו את הסבילות. כתוצאה מכך, GKE לא יתזמן את הפודים האלה בצומתי Scale-Out.

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

אם אתם משתמשים ב-ComputeClasses או מבקשים סדרות מכונות ספציפיות, ודאו שעומסי העבודה שלכם לא משתמשים באחסון לא תואם. לדוגמה, אל תשתמשו בסוגים קודמים של נפחי Persistent Disk, כמו נפחי Persistent Disk רגילים (pd-standard) או נפחי Persistent Disk SSD‏ (pd-ssd), בסדרות של מכונות שלא תומכות בהם. שימוש באחסון לא תואם עלול לגרום לפודים להישאר במצב Pending אם GKE לא יכול למצוא או להקצות צומת שעומד בכל המגבלות. אם Pod מתוזמן אבל האחסון לא מצליח להתחבר או להיטען, ה-Pod נשאר במצב ContainerCreating. מידע נוסף על פתרון בעיות בתאימות האחסון זמין במאמר עומס העבודה מתוזמן בסדרת מכונות ישנה יותר או תקוע במצב Pending בגלל חוסר תאימות של האחסון.

איך מבקשים ארכיטקטורת מעבד (CPU)

במקרים מסוימים, יכול להיות שעומסי העבודה שלכם נוצרו לארכיטקטורה ספציפית, כמו Arm. ‫Scale-Out ComputeClass תומך בכמה ארכיטקטורות מעבד (CPU). אתם יכולים לבקש ארכיטקטורה ספציפית לצד בקשת ComputeClass, על ידי ציון תווית בבורר הצמתים או בכלל הזיקה של הצומת, כמו בדוגמה הבאה:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-arm
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-arm
  template:
    metadata:
      labels:
        app: nginx-arm
    spec:
      nodeSelector:
        cloud.google.com/compute-class: COMPUTE_CLASS
        kubernetes.io/arch: ARCHITECTURE
      containers:
      - name: nginx-arm
        image: nginx
        resources:
          requests:
            cpu: 2000m
            memory: 2Gi

מחליפים את ARCHITECTURE בארכיטקטורת המעבד (CPU) הרצויה, למשל arm64 או amd64. אפשר לבחור רק ארכיטקטורה אחת בעומס העבודה. ה-ComputeClass שבוחרים חייב לתמוך בארכיטקטורה שצוינה.

אם לא מבקשים ארכיטקטורה באופן מפורש, Autopilot משתמש בארכיטקטורת ברירת המחדל של ComputeClass.

ארכיטקטורת Arm ב-Autopilot

ב-Autopilot יש תמיכה בבקשות לצמתים שמשתמשים בארכיטקטורת מעבד (CPU) מסוג Arm. צומתי Arm חסכוניים יותר מצומתי x86 דומים, ומספקים שיפורים בביצועים. במאמר פריסת עומסי עבודה של Autopilot בארכיטקטורת Arm מוסבר איך מבקשים צומתי Arm.

חשוב לוודא שאתם משתמשים בתמונות הנכונות בפריסות שלכם. אם ה-Pods משתמשים בתמונות Arm ולא מבקשים צומתי Arm, ‏Autopilot מתזמן את ה-Pods בצומתי x86 וה-Pods קורסים. באופן דומה, אם תשתמשו בטעות בתמונות x86 אבל תבקשו צומתי Arm לפודים, הפודים יקרסו.

בקשות ברירת מחדל, מינימום ומקסימום למשאבים

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

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