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

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

סקירה כללית על ComputeClass מאוזן ועל ComputeClass עם הרחבה אופקית

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

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

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

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

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

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

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

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

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

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

‫Balanced ו-Scale-Out ComputeClasses
Balanced

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

במקרים מסוימים, יכול להיות שעומסי העבודה שלכם מיועדים לארכיטקטורה ספציפית, כמו Arm. ‫ComputeClass Scale-Out תומך בכמה ארכיטקטורות של מעבדים. אפשר לבקש ארכיטקטורה ספציפית לצד בקשת 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 בארכיטקטורת המעבד הרצויה, כמו arm64 או amd64. אפשר לבחור עד ארכיטקטורה אחת בעומס העבודה. ה-ComputeClass שתבחרו צריך לתמוך בארכיטקטורה שציינתם.

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

ארכיטקטורת Arm בטייס אוטומטי

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

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

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

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

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