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

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

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

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

אם יש לכם עומסי עבודה עם דרישות חומרה ייחודיות (למשל, ביצוע משימות של למידת מכונה או 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 משתמש בהם כדי להגדיר צמתים חדשים באשכול. לדוגמה, באמצעות ComputeClass מותאם אישית אפשר לפרוס עומסי עבודה באותו חומרה כמו ComputeClass‏ 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 ו-Extreme storage
Scale-Out

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

  • יחידות עיבוד מרכזיות (CPU) זמינות: 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 מוסיף כתם נפרד שייחודי לארכיטקטורה הזו.
  • הכלי מוסיף באופן אוטומטי סבילות שמתאימות לכתמי הרעל שהוחלו על ה-Pods שנפרסו, וכך מאפשר ל-GKE למקם את ה-Pods האלה בצמתים החדשים.

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

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

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

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

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

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

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