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

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

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

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

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

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

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

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

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

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

תמחור

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

מידע נוסף מפורט במאמר תמחור GKE.

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

בקטע הזה מתוארים סוגי המכונות ותרחישי השימוש במחלקות Balanced ו-Scale-Out. אם לא מבקשים ComputeClass ב-Pods,‏ Autopilot מציב את ה-Pods בפלטפורמת מחשוב שעברה אופטימיזציה לקונטיינרים כברירת מחדל. לפעמים יכול להיות שתראו את הערך ek בסדרת המכונות של הצומת בצמתים של Autopilot שמשתמשים בפלטפורמת מחשוב שמותאמת לקונטיינרים. מכונות EK הן סוגי מכונות E2 שזמינות רק ב-Autopilot.

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

‫ComputeClasses מאוזנות וניתנות להרחבה
Balanced

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

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

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

  • שרתי אינטרנט
  • מסדי נתונים בינוניים עד גדולים
  • שמירה במטמון
  • סטרימינג והצגת מדיה
  • Hyperdisk Throughput and 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.
  • הוספה אוטומטית של תוויות צמתים וכתמים לצמתים החדשים כדי למנוע תזמון של פודים אחרים בצמתים האלה. ה-taints ייחודיים לכל ComputeClass. אם בוחרים גם ארכיטקטורת CPU, ‏ GKE מוסיף כתם נפרד שייחודי לארכיטקטורה הזו.
  • הכלי מוסיף באופן אוטומטי סבילות שמתאימות לכתמי הרעל שהוחלו על ה-Pods שנפרסו, וכך מאפשר ל-GKE למקם את ה-Pods האלה בצמתים החדשים.

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

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

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

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

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

במקרים מסוימים, יכול להיות שעומסי העבודה שלכם מיועדים לארכיטקטורה ספציפית, כמו 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 CPU. צמתי Arm הם חסכוניים יותר מצמתי x86 דומים, וגם משפרים את הביצועים. הוראות לבקשת צמתים של Arm מופיעות במאמר פריסת עומסי עבודה של Autopilot בארכיטקטורת Arm.

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

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

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

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