Google Kubernetes Engine (GKE) יכול ליצור ולנהל באופן אוטומטי מאגרי צמתים באשכולות שלכם על סמך ההגדרה של עומסי העבודה. במסמך הזה מוסבר איך פועלת יצירה אוטומטית של מאגר צמתים, מהם פרמטרים של שינוי גודל והתנהגות ברירת המחדל, ומופיעות המלצות שיכולות לעזור לכם לשפר את יכולת ההתאמה לגודל. המסמך הזה מיועד לאדמינים של אשכולות שרוצים לצמצם את העלויות שקשורות לניהול ידני של התשתית באשכולות במצב Standard.
כדאי להכיר את המושגים הבאים:
במצב Autopilot, GKE תמיד יוצר ומנהל צמתים ומאגרי צמתים בשבילכם על סמך עומסי העבודה שלכם. אין צורך להגדיר באופן ידני יצירה אוטומטית של מאגר צמתים עבור אשכולות Autopilot או עבור עומסי עבודה של Autopilot באשכולות Standard. מידע נוסף זמין במאמר סקירה כללית על GKE Autopilot.
מהי יצירה אוטומטית של מאגר צמתים?
ב-GKE, node pools הם קבוצות לוגיות של צמתים. לכל צומת במאגר צמתים יש את אותה הגדרה כמו לכל צומת אחר במאגר הצמתים הזה. יצירה אוטומטית של מאגר צמתים היא מנגנון של התאמה אוטומטית לעומס (autoscaling) בתשתית, שמאפשר ל-GKE ליצור מאגרי צמתים חדשים באשכול שעומדים בדרישות של עומסי העבודה. GKE מנהל את מאגרי הצמתים שנוצרו אוטומטית, ומבצע משימות כמו עדכון מטא-נתונים של צמתים, יצירה ומחיקה של צמתים במאגר הצמתים ומחיקה של מאגר הצמתים כולו כשאין בו יותר צורך. יצירה אוטומטית של מאגר צמתים היא הרחבה של התכונה לשינוי גודל האשכול ב-GKE, שמשנה את גודל הצמתים במאגרי צמתים נפרדים באופן אוטומטי.
התכונה 'יצירה אוטומטית של מאגר צמתים' נועדה לאפשר ל-GKE להקטין את מאגרי הצמתים הריקים ולהסיר אותם מהאשכול באופן אוטומטי. אי אפשר להגדיר מספר מינימלי של צמתים שכל מאגר צמתים שנוצר אוטומטית חייב לכלול, כי מספר מינימלי שגדול מאפס ימנע את ההסרה של מאגרי צמתים ריקים. אם תרחיש השימוש שלכם דורש שמספר מינימלי של צמתים יפעל תמיד באשכול, צריך ליצור מאגר צמתים באופן ידני עם הפעלה של שינוי גודל אוטומטי.
איך זה עובד
התכונה Node pool auto-creation (יצירה אוטומטית של מאגר צמתים) מרחיבה את האפשרויות של התאמה אוטומטית לעומס ב-GKE, ומאפשרת ל-GKE להקצות מאגרי צמתים חדשים שעומדים בדרישות החומרה ובבקשות המשאבים של Pods בהמתנה. אפשר להגדיר את דרישות החומרה בדרכים הבאות:
- משתמשים ב-ComputeClasses, ואז בוחרים אותם בתרמילים שונים באמצעות בורר צמתים. אנחנו ממליצים על השיטה הזו כי אפשר להגדיר באופן מרכזי הגדרות נפוצות של צמתים שבהן אפשר להשתמש בכמה עומסי עבודה.
- כדי לבקש תוויות ספציפיות של צומתי GKE במפרטי Pod, משתמשים בבוררי צמתים או בזיקה לצמתים.
GKE מגדיר מאגרי צמתים חדשים על סמך פרמטרים כמו:
- מעבד (CPU), זיכרון ואחסון זמני בקשות למשאבים ב-Pods ובקונטיינרים, כולל Pods שמנוהלים על ידי DaemonSets.
- בקשות ל-GPU ול-TPU במפרטים של Pod או ב-ComputeClasses.
- דרישות חומרה, כמו סוגי מכונות או סוגי דיסקים לאתחול, במפרטים של Pods בהמתנה או ב-ComputeClasses.
- Tolerations במפרטים של Pods בהמתנה שיש להם בוררי צמתים תואמים.
GKE מגדיר את קיבולת המשאבים של כל צומת במאגר צמתים שנוצר אוטומטית כך שתהיה גדולה או שווה לבקשות המשאבים של ה-Pods בהמתנה. צריך לוודא שהבקשות למשאבים גדולות מספיק כדי שה-Pod יפעל כצפוי. אם בקשות ה-Pod נמוכות מדי, ה-Pods לא יפעלו כמצופה אחרי ש-GKE יתזמן אותם בצמתים שנוצרו אוטומטית.
הגדרת מטא-נתונים של צומת
GKE גם מגדיר מטא נתונים של צמתים (כמו תוויות, הערות ו-node taints) על סמך דרישות עומס העבודה, כמו בדוגמאות הבאות:
- אם מבקשים את סדרת מכונות N2, GKE מוסיף את תווית הצומת
cloud.google.com/machine-family: n2לכל אחד מהצמתים. - אם בוחרים ComputeClass ב-Pod, GKE מוסיף תווית של צומת עם המפתח
cloud.google.com/compute-classשמוגדר לשם של אותו ComputeClass. - אם ל-Pod יש toleration וגם בורר צמתים לאותה תווית צומת, מערכת GKE מוסיפה taints של צמתים ל-toleration האלה בצמתים שנוצרו אוטומטית.
מחיקה של מאגרי צמתים שנוצרו אוטומטית
היצירה האוטומטית של מאגר צמתים מאפשרת ל-Cluster Autoscaler ליצור מאגרי צמתים וצמתים חדשים כדי להריץ Pods ממתינים נכנסים. אם מספר ה-Pods במאגר צמתים שנוצר אוטומטית יורד, Cluster Autoscaler מקטין בהדרגה את מאגר הצמתים. כשזה אפשרי, GKE מרוקן צמתים שלא נעשה בהם שימוש מספיק במאגר הצמתים, מאחד את ה-Pods בצמתים אחרים ומסיר את הצמתים הריקים.
אם מספר הצמתים במאגר צמתים שנוצר אוטומטית הוא אפס, GKE מוחק את מאגר הצמתים הזה. GKE לא מוחק מאגרי צמתים שאתם מוציאים מהכלל ביצירה אוטומטית של מאגרי צמתים, כמו מאגרי צמתים שנוצרו באופן ידני. למידע נוסף על האופן שבו המידרוג האוטומטי של האשכול מצמצם את מספר הצמתים במאגרי הצמתים, אפשר לעיין במאמר איך המידרוג האוטומטי של האשכול פועל.
העדפות לגבי שינוי גודל ב-GKE
ההעדפות הבאות חלות כשמפעילים ב-GKE התאמה אוטומטית לעומס (automatic scaling) של התשתית:
- צמצום בזבוז של משאבי מחשוב: כדי לקבוע את סוג המכונה שבה צריך להשתמש במאגרי צמתים חדשים, GKE משתמש בקיבולת המשאבים של מאגרי צמתים קיימים שנוצרו באופן אוטומטי באשכול. ככל שהאשכול גדל, GKE מעדיף להשתמש בסוגי מכונות גדולים יותר למאגרי צמתים חדשים, כדי שיותר פודים יוכלו לפעול בכל צומת במאגר הצמתים.
- אופטימיזציה של יכולת ההתאמה והחביון: מערכת GKE תמיד נותנת עדיפות להגדלת מאגרי צמתים קיימים ותואמים, במקום ליצור מאגרי צמתים חדשים. ההעדפה הזו מתחזקת ככל שמספר מאגרי הצמתים השונים באשכול גדל. כשהמספר של מאגרי הצמתים השונים מתקרב למגבלות הנתמכות לזמן אחזור אופטימלי ולשינוי גודל, GKE נותן עדיפות נמוכה יותר ליצירת מאגרי צמתים חדשים.
סדר העדיפויות הזה עוזר להבטיח שימוש יעיל במשאבי מחשוב באשכולות, כמו בתרחישים הבאים:
- באשכולות עם מספר קטן של מאגרי צמתים ושימוש נמוך יותר במשאבים, GKE יוצר מאגרי צמתים חדשים בתדירות גבוהה יותר ומשתמש בסוגי מכונות קטנים יותר עבור מאגרי הצמתים האלה.
- בקטעי קוד שיש בהם מספר גדול של מאגרי צמתים, השימוש במשאבים גבוה. GKE יוצר מאגרי צמתים חדשים בתדירות נמוכה יותר ומשתמש בסוגי מכונות גדולים יותר עבור מאגרי הצמתים האלה, כדי שתזמון ה-Pod יוכל להימשך, וגם כדי להאט את ההתקדמות לקראת יכולת ההתאמה של האשכול והגבלות זמן האחזור.
אתם יכולים לשלוט באופן ידני בגודל המינימלי של המופעים ש-GKE משתמש בהם למאגרי הצמתים שנוצרו אוטומטית, באמצעות ComputeClass שיש לו שדה priorities.machineFamily ואחד מהשדות priorities.minCores או priorities.minMemoryGb.
שיטות להפעלת יצירה אוטומטית של מאגר צמתים
GKE יכול ליצור באופן אוטומטי מאגרי צמתים עבור ComputeClasses ספציפיים או עבור כל עומס עבודה שמשתמש בהגדרה תואמת, בהתאם להגדרת האשכול.
| שיטות הפעלה | |
|---|---|
| ברמת עומס העבודה (מומלץ) | ב-GKE מגרסה 1.33.3-gke.1136000 ואילך, אפשר להשתמש ב-ComputeClasses כדי להפעיל יצירה אוטומטית של מאגר צמתים בלי להשתמש בהקצאה אוטומטית של צמתים ברמת האשכול. GKE יוצר מאגרי צמתים חדשים רק לעומסי עבודה שבהם נבחרו ComputeClasses ספציפיים שהופעלה בהם יצירה אוטומטית. עומסי עבודה קיימים באשכול לא מושפעים. גם בגרסאות GKE מוקדמות יותר מ-1.33.3-gke.1136000, ComputeClasses הן הדרך המומלצת לבקש ולתצור את התשתית של עומסי העבודה. ComputeClasses מספקות יכולות ייחודיות ומאפשרות לכם לשפר את ההתאמה של קנה המידה בצורה גמישה באשכול. מידע נוסף זמין במאמר בנושא מידע על ComputeClasses בהתאמה אישית. |
| ברמת האשכול | הפעלת הקצאה אוטומטית של צמתים לכל האשכול. צריך להגדיר מגבלות למשאבים כמו מעבד (CPU) וזיכרון באשכול. המגבלות האלה חלות על כל האשכול. ההגדרה ברמת האשכול נדרשת כדי להפעיל יצירה אוטומטית של מאגר צמתים בגרסאות GKE קודמות לגרסה 1.33.3-gke.1136000. GKE יכול ליצור מאגרי צמתים חדשים לכל עומס עבודה בהמתנה באשכול באמצעות ComputeClasses או סלקטורים במפרטים של ה-Pod. |
שיטות ההגדרה האלה לא בלעדיות. אפשר להשתמש ב-ComputeClasses כדי ליצור באופן אוטומטי מאגרי צמתים באשכולות שמוגדר בהם Node Auto Provisioning. אם משתמשים בשתי השיטות האלה כדי להפעיל יצירה אוטומטית של מאגר צמתים באשכול, GKE משתמש בסדר העדיפות הבא כדי למצוא את הערך של הגדרת תצורה לשימוש במאגר צמתים:
- מפרט ComputeClass או Pod: אם מציינים הגדרה (כמו סוג מכונה) ב-ComputeClass או במפרט Pod, GKE משתמש בהגדרה הזו.
- ברירת מחדל של הקצאת משאבים אוטומטית של צמתים ברמת האשכול: אם הגדרה לא מצוינת ב-ComputeClass או במפרט של Pod, GKE בודק אם הגדרתם ערך ברירת מחדל להקצאת משאבים אוטומטית של צמתים באשכול. אם קיים ערך ברירת מחדל ברמת האשכול, GKE משתמש בערך הזה.
- ברירת מחדל ברמת האשכול: אם הגדרה לא מצוינת ב-ComputeClasses, במפרטים של Pod או כערך ברירת מחדל להקצאה אוטומטית של צמתים ברמת האשכול, GKE משתמש בערך ברירת המחדל שמוגדר לאשכול ב-Google Cloud.
לדוגמה, נניח ש-GKE מנסה למצוא סוג מכונה לשימוש במאגר צמתים שנוצר אוטומטית. סדר העדיפות שצוין למעלה חל באופן הבא:
- GKE בודק אם בספציפיקציה של ה-Pod או ב-ComputeClass של ה-Pod מצוין סוג מכונה.
- אם במפרט של ה-Pod או ב-ComputeClass לא מצוין סוג מכונה, מערכת GKE בודקת אם הגדרתם סוג מכונה שמוגדר כברירת מחדל להקצאה אוטומטית של צמתים באשכול.
- אם לא הגדרתם סוג מכונה שמוגדר כברירת מחדל להקצאה אוטומטית של צמתים, מערכת GKE משתמשת בסוג המכונה שמוגדר כברירת מחדל באשכול.
ברוב המקרים מומלץ להשתמש רק בשיטה להפעלת ComputeClass. בקטעים הבאים מפורטות כל שיטות ההגדרה האלה, כולל מגבלות ושיקולים.
הפעלה ברמת עומס העבודה באמצעות ComputeClasses
אתם יכולים להפעיל יצירה אוטומטית של מאגר צמתים לכל ComputeClass באשכול שלכם באמצעות אחד מהשדות הבאים במפרט ComputeClass:
-
nodePoolAutoCreation: מאפשרים ל-GKE ליצור באופן אוטומטי מאגרי צמתים לפי הצורך. עדיין אפשר לבצע פעולות במאגרי הצמתים. GKE מיישם רק את ההגדרות או האילוצים שאתם מגדירים. -
autopilot: הרצת עומסי העבודה (workload) שבוחרים את ComputeClass הזה במצב Autopilot. בדומה לאשכול Autopilot, GKE מנהל באופן מלא את הצמתים בשבילכם ומיישם אילוצים והגדרות שונים של Autopilot. אם משתמשים בשדהautopilot, אפשר לדלג על המסמך הזה. מידע נוסף זמין במאמר בנושא עומסי עבודה במצב אוטומטי ב-Standard.
באשכולות שמשתמשים ב-GKE בגרסה 1.33.3-gke.1136000 ואילך, אפשר להשתמש בשדות האלה ב-ComputeClass בלי להפעיל הקצאה אוטומטית של צמתים ברמת האשכול.
אם מגדירים יצירה אוטומטית של מאגר צמתים ב-ComputeClass בלי להפעיל הקצאה אוטומטית של צמתים לאשכול, GKE יוצר מאגרי צמתים חדשים רק עבור עומסי עבודה שמשתמשים ב-ComputeClass. עומסי עבודה אחרים לא מושפעים.
המניפסט הבא של ComputeClass מאפשר יצירה אוטומטית של מאגר צמתים לכל Pod שמשתמש ב-ComputeClass:
apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
name: example-computeclass
spec:
priorities:
- machineFamily: n4
- machineFamily: c4
whenUnsatisfiable: ScaleUpAnyway
nodePoolAutoCreation:
enabled: true
הפעלה ברמת האשכול באמצעות ניהול הקצאות אוטומטי של צמתים
כדי להפעיל יצירה אוטומטית של מאגר צמתים עבור האשכול כולו, מפעילים את התכונה node auto-provisioning באשכול באמצעות Kubernetes Engine API. הקצאה אוטומטית של צמתים מאפשרת ל-GKE ליצור מאגרי צמתים חדשים לפי הצורך לכל עומס עבודה באשכול, על סמך מפרטי Pod או הגדרות ComputeClass. GKE לא מנהל מאגרי צמתים קיימים באשכול, אבל אפשר לסמן מאגרי צמתים בודדים כמאגרי צמתים שהוקצו אוטומטית אחרי שמפעילים הקצאה אוטומטית של צמתים באשכול.
כדאי להפעיל הקצאת משאבים אוטומטית לצמתים במצבים כמו:
- אתם רוצים שאשכול GKE ייצור באופן אוטומטי מאגרי צמתים בגרסת GKE מוקדמת יותר מ-1.33.3-gke.1136000.
אתם רוצים להגדיר באופן ידני מגבלות משאבים ברמת האשכול. בגרסאות GKE מוקדמות יותר מ-1.33.3-gke.1136000, צריך להגדיר מגבלות על משאבים ברמת האשכול גם אם משתמשים ב-ComputeClasses.
רוצים להשתמש בתכונות או בהגדרות ספציפיות שלא נתמכות על ידי ComputeClasses.
רוצים להגדיר ערכי ברירת מחדל של הגדרות צומת לכל האשכול.
אחרי שמפעילים הקצאה אוטומטית של צמתים, אפשר להגדיר ערכי ברירת מחדל להגדרות שונות של צמתים באמצעות Google Cloud CLI או קובץ תצורת YAML.
הגבלות על משאבים ברמת האשכול באמצעות הקצאה אוטומטית של צמתים
כשמפעילים הקצאה אוטומטית של צמתים לאשכול שלם, צריך גם להגדיר מגבלות למשאבים כמו CPU, זיכרון, GPU ו-TPU באשכול. המגבלות האלה חלות על סך קיבולת המשאבים באשכול, כולל מאגרי צמתים ו-ComputeClasses שנוצרו באופן ידני. GKE לא יוצר צמתים חדשים או מאגרי צמתים חדשים אם הפעולה תחרוג מאחת ממגבלות המשאבים האלה.
הגבלות המשאבים ברמת האשכול נדרשות רק אם מפעילים באשכול הקצאה אוטומטית של צמתים. באשכולות שמשתמשים ב-GKE מגרסה 1.33.3-gke.1136000 ואילך, אפשר להשתמש ביצירה אוטומטית של מאגר צמתים ב-ComputeClasses בלי להפעיל הקצאה אוטומטית של צמתים.
אם האשכול שלכם עומד בדרישות האלה, מומלץ להשתמש רק ב-ComputeClasses כדי להגדיר מאגרי צמתים שנוצרים אוטומטית.
הגדרות ברירת מחדל למאגרי צמתים שנוצרו אוטומטית
אתם יכולים לציין ערכי ברירת מחדל ש-GKE יחיל על מאגרי צמתים שנוצרו אוטומטית ברמת עומס העבודה או ברמת האשכול.
- הגדרות ברירת מחדל ברמת עומס העבודה: אפשר להשתמש בשדה
spec.nodePoolConfigובשדהspec.priorityDefaultsבמפרט ComputeClass כדי להגדיר ערכי ברירת מחדל להגדרות ספציפיות של צמתים. ערכי ברירת המחדל האלה חלים רק על מאגרי הצמתים ש-GKE יוצר עבור ComputeClass. - הגדרות ברירת מחדל ברמת האשכול: אתם יכולים להגדיר ערכי ברירת מחדל למאגרי צמתים שנוצרו אוטומטית כשאתם מגדירים הקצאת צמתים אוטומטית. כדי לציין ערכי ברירת מחדל, משתמשים ב-CLI של gcloud או בקובץ הגדרות YAML.
השיטות האלה להגדרת ברירות מחדל לא סותרות זו את זו. אם מגדירים ערכי ברירת מחדל להגדרה ספציפית ב-ComputeClass ולכל האשכול, GKE משתמש בערך של ComputeClass. אם לא מציינים ערך להגדרה הזו ב-ComputeClass, GKE משתמש בערך ברירת המחדל ברמת האשכול במקום זאת.
הגדרות ברירת מחדל ברמת האשכול באמצעות קובץ הגדרה
כשמפעילים הקצאה אוטומטית של צמתים, אפשר להשתמש בקובץ הגדרות YAML כדי לציין הגדרות ברירת מחדל ברמת האשכול למאגרי צמתים שנוצרים באופן אוטומטי. אפשר לציין כמה הגדרות בקובץ תצורה אחד. חלק מההגדרות המתקדמות (כמו הגדרות תיקון אוטומטי) אפשר לציין רק באמצעות קובץ הגדרות.
קובץ התצורה הבא מאפשר תיקון אוטומטי ושדרוג אוטומטי של צמתים לכל מאגרי הצמתים החדשים שנוצרו אוטומטית:
management: autoRepair: true autoUpgrade: trueבקובץ ההגדרות לדוגמה הבא מוגדרות מגבלות המשאבים ברמת האשכול להקצאת צמתים אוטומטית, ומוגדרות כמה הגדרות ברירת מחדל:
resourceLimits: - resourceType: 'cpu' minimum: 4 maximum: 10 - resourceType: 'memory' maximum: 64 - resourceType: 'nvidia-tesla-t4' maximum: 4 management: autoRepair: true autoUpgrade: true shieldedInstanceConfig: enableSecureBoot: true enableIntegrityMonitoring: true diskSizeGb: 100קובץ ההגדרות הזה קובע את ערכי ברירת המחדל הבאים:
- האפשרות הזו מאפשרת תיקון ושדרוג אוטומטיים של צמתים לכל מאגר צמתים חדש שנוצר אוטומטית.
- הפעלת אתחול מאובטח ומעקב אחר שלמות לכל מאגרי הצמתים החדשים שנוצרו אוטומטית.
- מגדיר את גודל דיסק האתחול ל-100 GiB לכל מאגר צמתים חדש שנוצר אוטומטית.
אחרי שמחילים את קובץ ההגדרות על האשכול, GKE משתמש בהגדרות שבקובץ רק עבור מאגרי צמתים חדשים שנוצרו אוטומטית באשכול. ההגדרות החדשות או ששונו שציינתם בקובץ לא חלות על מאגרי צמתים קיימים שנוצרו על ידי GKE באשכול. אם מעדכנים ערך שהוגדר קודם לאשכול, GKE משתמש בערך החדש לכל מאגרי הצמתים החדשים. לדוגמה, אם הגדרתם בעבר את סדרת ברירת המחדל של המכונות ל-N2, ואתם מעדכנים את הערך ל-N4 בקובץ ההגדרות, כל מאגרי הצמתים החדשים ישתמשו בסוגי מכונות N4.
מידע נוסף על שימוש בקובץ ההגדרות ברמת האשכול זמין במאמר הגדרת הגדרות באמצעות קובץ הגדרות של הקצאת צמתים אוטומטית.
תרחישי שימוש ביצירה אוטומטית של מאגרי צמתים
בקטעים הבאים מתוארים כמה תרחישי שימוש פופולריים וציוד נתמך ליצירה אוטומטית של מאגרי צמתים. מידע נוסף על תרחישי שימוש נוספים ועל הגדרות נתמכות מופיע במאמרי העזרה שמתאימים לתרחיש השימוש הספציפי שלכם.
בחירה של סדרת מכונות או סוג מכונה
אפשר לבחור סדרת מכונות או סוג מכונה של Compute Engine לשימוש ב-GKE עבור מאגרי צמתים שנוצרו אוטומטית באחת מהדרכים הבאות:
- ComputeClasses: משתמשים ב-
machineFamilyאו בmachineTypeכללי עדיפות. - מפרטי Pod: בסדרת מכונות, משתמשים בבורר צמתים עבור תווית הצומת
cloud.google.com/machine-family. כדי להגדיר סוג מכונה, צריך להשתמש בתוויות הצמתיםcloud.google.com/machine-familyו-node.kubernetes.io/instance-type. מידע נוסף זמין במאמר בנושא בחירת סדרת מכונות או סוג מכונה.
אם לא בוחרים מכונה באופן מפורש, GKE משתמש בסדרת מכונות E2 או בסוג מכונה שתואם לחומרה שעומס העבודה דורש. לדוגמה, ב-GKE נעשה שימוש בסוגי מכונות GPU עבור מעבדי GPU ובמכונות ייעודיות עבור משאבי TPU.
כשמבקשים סדרת מכונות או סוג מכונה, צריך לוודא שסלקטורים אחרים של צמתים ובקשות משאבים של Pod תואמים למכונה שצוינה. לדוגמה, אי אפשר לבקש GPU וסדרת מכונות N2 בו-זמנית.
סדרות מכונות נתמכות
אתם יכולים לבקש באופן מפורש כל סדרת מכונות או סוג מכונה נתמכים של Compute Engine ב-ComputeClass או בעומס עבודה. הבקשות יכולות לכלול הגדרות חומרה ספציפיות, כמו ארכיטקטורת Arm.
יצירה אוטומטית של מאגר צמתים תומכת בסדרות המכונות הבאות רק בגרסאות ספציפיות של GKE:
- Z3 machine series: 1.29 ואילך.
- סדרת מכונות C4:
- 1.28.15-gke.1159000 ואילך.
- 1.29.10-gke.1227000 ואילך.
- 1.30.3-gke.1225000 ואילך.
-
- מכונות C4A VM:
- 1.30.7-gke.1136000 ואילך.
- 1.31.3-gke.1056000 ואילך.
-
-
c4a-highmem-96-metal: 1.35.3-gke.1389000 ואילך. -
c4a-standard-96-metal: לא נתמך.
-
- מכונות C4A VM:
C4D machine series: 1.32.3-gke.1717000 ואילך.
C4N machine series: גרסה 1.36.0-gke.3009002 ואילך.
סדרת מכונות N4: גרסה 1.29.3 ואילך.
-
- 1.33.12-gke.1208000 ואילך.
- 1.34.1-gke.2037000 ואילך.
N4A machine series: 1.34.1-gke.3403001 ואילך.
סדרות אחרות של מכונות נתמכות בכל הגרסאות של GKE.
בחירת GPU
אפשר לבקש יחידות GPU למאגרי צמתים שנוצרו אוטומטית באחת מהדרכים הבאות:
- ComputeClasses:
- משתמשים בכלל העדיפות
gpuכדי להגדיר את מעבדי ה-GPU. - בקשת משאבי GPU בקבוצות ה-Pod.
- משתמשים בכלל העדיפות
- מפרטים של מכשירי Pod:
- הגדרת מגבלות GPU ברמת האשכול לניהול הקצאות אוטומטי של צמתים.
- משתמשים בבוררי צמתים כדי להגדיר את ה-GPU.
- בקשת משאבי GPU בקבוצות ה-Pod.
GKE בוחר סוג מכונה עם GPU שגדול מספיק כדי לתמוך במספר מעבדי ה-GPU. מספר ה-GPU שבוחרים משפיע על קיבולת המעבד והזיכרון של הצמתים.
דרישות לגבי גרסת GKE ל-GPU
- G4 machine series: 1.34.1-gke.1829001 ואילך.
- A4X machine series: 1.33.4-gke.1036000 ואילך.
- A3 Ultra machine series: 1.31.4-gke.1183000 and later.
בחירת Cloud TPU
אפשר לבקש משאבי Cloud TPU עבור מאגרי צמתים שנוצרו אוטומטית באחת מהדרכים הבאות:
- ComputeClasses: משתמשים ב
tpuכלל העדיפות כדי להגדיר TPU. לאחר מכן, שולחים בקשה לאותו מספר של משאבי TPU ב-Pods. מידע נוסף זמין במאמר בנושא הקצאת TPU באמצעות מחלקות מחשוב מותאמות אישית. - מפרטים של Pod: הגדרת מגבלות TPU ברמת האשכול. לאחר מכן, משתמשים בבוררי צמתים כדי להגדיר את יחידות ה-TPU ולבקש משאבי TPU ב-Pods. מידע נוסף זמין במאמר בנושא הגדרת Cloud TPU.
גם מאגרי צמתים של פרוסות TPU במארח יחיד וגם מאגרי צמתים של פרוסות TPU במארחים מרובים תומכים בהרחבה אוטומטית ובאוטומציה של יצירת מאגרי צמתים. כדי ליצור מאגר צמתים באופן אוטומטי, GKE יוצר מאגרי צמתים של פרוסות TPU עם מארח יחיד או עם כמה מארחים, עם גרסת TPU וטופולוגיה שעומדות בדרישות של עומסי עבודה בהמתנה.
דרישות לגבי גרסת GKE לשימוש ב-Cloud TPU
יצירה אוטומטית של מאגר צמתים תומכת ב-Cloud TPU הבאים רק בגרסאות ספציפיות של GKE:
- TPU v3: גרסה 1.31.0 ואילך.
- TPU v5 ו-TPU v4: גרסה 1.29.0 ואילך.
- TPU Trillium: גרסה 1.32.0 ואילך.
- Ironwood (TPU7x): גרסה 1.34.1-gke.2541000 ואילך.
יש תמיכה בסוגים אחרים של Cloud TPU בכל הגרסאות של GKE. מידע נוסף על גרסאות GKE שזמינות ל-TPU מופיע במאמר בנושא אימות הזמינות של TPU ב-GKE.
שינוי אוטומטי של גודל מאגר הצמתים ב-Cloud TPU
מערכת GKE משנה את הגודל של מאגרי צמתים של Cloud TPU שנוצרו באופן אוטומטי או באופן ידני, שמשתמשים ב-Cluster Autoscaler, באחת מהדרכים הבאות:
- מאגר צמתים של פרוסת TPU עם מארח יחיד: GKE מוסיף או מסיר צמתי TPU במאגר הצמתים הקיים. מאגר הצמתים יכול להכיל כל מספר של צמתי TPU בין אפס לבין הגודל המקסימלי של מאגר הצמתים, כפי שנקבע על ידי דגלי שינוי הגודל האוטומטי
--max-nodesו---total-max-nodes. לכל צמתי ה-TPU במאגר הצמתים יש את אותו סוג מכונה ואותה טופולוגיה. מידע נוסף על יצירת מאגר צמתים של פרוסת TPU במארח יחיד זמין במאמר יצירת מאגר צמתים של פרוסת TPU במארח יחיד. - מאגר צמתים של חלקי TPU עם כמה מארחים: GKE מגדיל את מאגר הצמתים באופן אטומי מאפס למספר הצמתים שנדרש כדי להתאים לטופולוגיית ה-TPU. לדוגמה, אם יש מאגר צמתים של TPU עם
ct5lp-hightpu-4tסוג מכונה וטופולוגיה של16x16, במאגר הצמתים תמיד יהיו 64 צמתים או אפס צמתים. מערכת GKE מצמצמת את מאגר הצמתים אם אין בו עומסי עבודה של TPU. כדי להקטין את מאגר הצמתים, GKE מוציא את כל ה-Pods המתוזמנים ומסיר את כל הצמתים במאגר הצמתים. מידע נוסף על יצירת מאגר צמתים של TPU slice עם כמה מארחים זמין במאמר יצירת מאגר צמתים של TPU slice עם כמה מארחים.
הגדרת מאגר צמתים של Cloud TPU
GKE משתמש בהגדרה ב-Pod או ב-ComputeClass כדי לקבוע את ההגדרה של צמתי ה-TPU. המניפסט הבא הוא דוגמה למפרט פריסה שבו מוגדרות בקשות ל-TPU במפרט של ה-Pod. אם ההגדרה של הקצאת צמתים אוטומטית ברמת האשכול מופעלת,
פריסת ה-Deployment הזה מפעילה יצירה אוטומטית של מאגר צמתים. כשיוצרים את פריסת הדוגמה הזו, GKE יוצר מאגר צמתים שמכיל פרוסת TPU v4 עם טופולוגיה של 2x2x2 ושתי מכונות ct4p-hightpu-4t.
apiVersion: apps/v1
kind: Deployment
metadata:
name: tpu-workload
labels:
app: tpu-workload
spec:
replicas: 2
template:
spec:
nodeSelector:
cloud.google.com/gke-tpu-accelerator: tpu-v4-podslice
cloud.google.com/gke-tpu-topology: 2x2x2
containers:
- name: tpu-job
image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
ports:
- containerPort: 8431 # Port to export TPU runtime metrics, if supported.
securityContext:
privileged: true # Required for GKE versions earlier than 1.28 to access TPUs.
command:
- bash
- -c
- |
python -c 'import jax; print("Total TPU chips:", jax.device_count())'
resources:
requests:
google.com/tpu: 4
limits:
google.com/tpu: 4
ports:
- containerPort: 80
במניפסט הזה, השדות הבאים מגדירים את התצורה של TPU:
-
cloud.google.com/gke-tpu-accelerator: הגרסה והסוג של TPU. לדוגמה, משתמשים ב-tpu7x-standard-4tעבור Ironwood (TPU7x). -
cloud.google.com/gke-tpu-topology: הטופולוגיה עם המספר והסידור הפיזי של שבבי ה-TPU בתוך פרוסת TPU. לדוגמה, משתמשים ב-2x2x2. -
limits.google.com/tpu: מספר שבבי ה-TPU לכל מכונה וירטואלית. לדוגמה, אם משתמשים ב-tpu7x-standard-4t, מספר שבבי ה-TPU לכל מכונה וירטואלית הוא4.
בחירת VM במודל Spot
אפשר לבחור באפשרות Spot VMs כדי ליצור מאגרי צמתים באופן אוטומטי באחת מהדרכים הבאות:
- ComputeClasses: משתמשים בשדה
spotבכלל עדיפות. - מפרטי ה-Pod: משתמשים ב-toleration לתווית הצומת
cloud.google.com/gke-spot="true"עם האפקטNoSchedule. מוסיפים בורר צמתים לתוויות הצמתיםcloud.google.com/gke-spot=trueאוcloud.google.com/gke-provisioning=spot. לחלופין, אפשר לבחור preemptible VMs באמצעות תווית הצומתcloud.google.com/gke-preemptibleב-toleration וב-node selector. עם זאת, אנחנו ממליצים מאוד להשתמש במכונות וירטואליות מסוג Spot במקום זאת.
הגדרת שטח אחסון זמני
GKE משתמש בחלק מדיסק האתחול של הצומת לאחסון זמני של Pod. אפשר להתאים אישית את הגודל של דיסק האתחול ש-GKE משתמש בו לצמתים שנוצרו אוטומטית באחת מהדרכים הבאות:
- ComputeClasses: משתמשים בשדות
storage.bootDiskSizeוב-storage.bootDiskTypeבכלל עדיפות. אתם יכולים להגדיר הגדרות שונות של דיסק האתחול עבור ComputeClass שונים. - מפרטי ה-Pod: משתמשים בשדות
diskSizeGbו-diskTypeבקובץ ההגדרות ברמת האשכול. אי אפשר לשלוט בגודל ובסוג של דיסק האתחול של כל Pod בנפרד באמצעות השיטה הזו.
מידע נוסף זמין במאמר בנושא דיסקים מותאמים אישית להפעלה.
אם לא משנים במפורש את ההגדרות של דיסק האתחול, ברירת המחדל היא נפח pd-balanced בקיבולת של 100 GiB.
GKE יוצר מאגר חדש של צמתים רק אם האחסון הזמני שניתן להקצאה של צומת עם דיסק אתחול שצוין גדול או שווה לבקשת האחסון הזמני של Pod בהמתנה. אם בקשת האחסון הזמני גדולה יותר מנפח האחסון הזמני שניתן להקצאה של צומת, GKE לא ייצור מאגר צמתים חדש וה-Pod יישאר במצב 'בהמתנה'. GKE לא משנה באופן דינמי את גודל דיסק האתחול בהתאם לבקשות שלכם לאחסון זמני של Pod.
הפרדה בין עומסי עבודה
אפשר לבקש ש-Pods ספציפיים תמיד יפעלו בצמתים נפרדים מ-Pods אחרים באותו אשכול. GKE משתמש בnode taints כדי למנוע מעומסי עבודה אחרים לפעול בצמתים האלה. אפשר להגדיר הפרדה של עומסי עבודה במאגרי צמתים שנוצרו אוטומטית באחת מהדרכים הבאות:
- ComputeClasses: הצמתים ש-GKE יוצר עבור ComputeClass ספציפי יכולים להריץ רק Pods שבוחרים את ה-ComputeClass הזה. אין צורך לשנות את מפרטי ה-Pod. אפשר להפריד בין ה-Pods ב-ComputeClass באמצעות זיקה ודחייה בין Pods.
- מפרטים של Pod: אם מפעילים הקצאת הרשאות אוטומטית של צמתים לאשכול, אפשר להגדיר הפרדה של עומסי עבודה באמצעות שדות במפרט של Pod. במהלך יצירה אוטומטית של מאגר צמתים, יכול להיות ש-GKE ייצור מאגרי צמתים עם תוויות וכתמים אם כל התנאים הבאים מתקיימים:
- ה-Pod משתמש בבורר צמתים כדי לבקש מפתח וערך של תווית צומת בהתאמה אישית. אי אפשר להשתמש בתוויות של צמתי מערכת להפרדה של עומסי עבודה.
- ל-Pod יש toleration לאותו מפתח של תווית הצומת.
- האפקט של ההגדרה הוא
NoSchedule,NoExecuteאו לא צוין.
מידע נוסף על הגדרת השדות האלה ועל מגבלות זמין במאמר הגדרת הפרדה של עומסי עבודה ב-GKE.
מגבלות
- כל ההגבלות של הכלי לשינוי גודל האשכול באופן אוטומטי חלות גם על יצירה אוטומטית של מאגר צמתים.
- יכול להיות שבאשכולות עם יותר מ-200 מאגרי צמתים סך הכול, זמן האחזור יגדל במהלך שינוי הגודל האוטומטי. כל הגדרה שמפעילה יצירה של מאגר צמתים חדש, כמו הפרדה של עומסי עבודה או שימוש בכמה ComputeClasses, מגדילה את המספר הזה. מידע נוסף על מגבלות של אשכולות זמין במאמר מגבלות ושיטות מומלצות בקטע 'תכנון אשכולות גדולים'.
- כל מגבלות המשאבים שאתם מגדירים לאשכול כשאתם מפעילים הקצאה אוטומטית של צמתים חלות גם על מאגרי הצמתים ש-GKE יוצר עבור ComputeClasses.
- ההגדרות הבאות לא נתמכות על ידי ComputeClasses:
- שדרוגים בהדרגה (rolling) או שדרוגים כחול-ירוק (blue-green).
- יושרה של הצומת והפעלה מאובטחת.
- כדי להפעיל יצירה אוטומטית של מאגר צמתים ל-ComputeClass בגרסאות GKE קודמות ל-1.33.3-gke.1136000, צריך גם להפעיל הקצאה אוטומטית של צמתים ברמת האשכול. המגבלה הזו לא חלה בגרסה 1.33.3-gke.1136000 של GKE ואילך.
הגדרות שלא נתמכות
GKE לא יוצר מאגרי צמתים חדשים שמשתמשים בהגדרות הבאות:
- GKE Sandbox
- מערכות הפעלה של Windows
- התאמה אוטומטית לעומס (Autoscaling) של נפחי אחסון מתמיד מקומיים.
- צמתים שמשתמשים בכונני SSD מקומיים ייעודיים לאחסון זמני של Pod. עם זאת, GKE יכול ליצור מאגרי צמתים חדשים שמשתמשים ב-SSD מקומי לאחסון בלוקים גולמי.
- צמתים שמשתמשים במסננים ששונו לתזמון בהתאמה אישית.
- ריבוי נימים סימולטני (SMT).
- יחידה למעקב אחרי ביצועים (PMU).
הכלי Cluster Autoscaler יכול לשנות את גודל הצמתים במאגרי צמתים קיימים שמשתמשים בהגדרות האלה.
המאמרים הבאים
- איך מגדירים יצירה אוטומטית של מאגר צמתים
- סקירה כללית על המידרוג האוטומטי של האשכול
- איך מגדירים את התכונה לשינוי גודל אוטומטי של אשכולות
- מידע נוסף על נראות של שינוי גודל אוטומטי של אשכולות
- איך משתמשים בהפרדת עומסי עבודה ב-GKE
- פתרון בעיות שקשורות ל-ComputeClass בהתאמה אישית