סקירה כללית על GKE Autopilot

‫Autopilot הוא מצב פעולה מנוהל ב-Google Kubernetes Engine‏ (GKE). בדף הזה מוסבר על היתרונות של מצב Autopilot, ומופיע בו מידע על תכנון אשכולות, פריסת עומסי עבודה והגדרת רשת ואבטחה. אדמינים, ארכיטקטים ואופרטורים יכולים להשתמש במידע הזה כדי לקבל החלטות מושכלות לגבי התאמה של מצב GKE Autopilot לדרישות התפעוליות של עומסי העבודה שלהם שמבוססים על קונטיינרים.

מידע נוסף על ההבדלים בין מצבי הפעולה ב-GKE זמין במאמר השוואה בין GKE Autopilot לבין GKE Standard.

מהו טייס אוטומטי?

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

אתם יכולים להריץ אשכול שלם במצב Autopilot, כך שהאשכול וכל עומסי העבודה שלו יפעלו בהתאם לשיטות המומלצות של GKE ולהמלצות לגבי שינוי גודל, אבטחה, שדרוגים והגדרת צמתים. אפשר גם להריץ עומסי עבודה ספציפיים במצב Autopilot באשכולות GKE Standard. האפשרות הזו מאפשרת לכם להשתמש בטייס אוטומטי בסביבות שבהן אתם עדיין צריכים שליטה ידנית בתשתית. מידע נוסף זמין במאמר מידע על עומסי עבודה במצב Autopilot ב-GKE Standard.

יתרונות

  • התמקדות באפליקציות: Google מנהלת את התשתית, כך שאתם יכולים להתמקד בפיתוח ובפריסה של האפליקציות שלכם.
  • אבטחה: לאשכולות של Autopilot יש הגדרה מוקשחת כברירת מחדל, עם הגדרות אבטחה רבות שמופעלות כברירת מחדל. ‫GKE מחיל באופן אוטומטי תיקוני אבטחה על הצמתים שלכם כשהם זמינים, בהתאם ללוחות הזמנים לתחזוקה שהגדרתם.
  • תמחור: מודל התמחור של Autopilot מפשט את תחזיות החיוב והשיוך.
  • ניהול צמתים: Google מנהלת את צמתי העובדים, כך שלא צריך ליצור צמתים חדשים כדי להתאים את עומסי העבודה או להגדיר שדרוגים ותיקונים אוטומטיים.
  • שינוי גודל: כשעומסי העבודה חווים עומס גבוה ומוסיפים עוד פודים כדי להתמודד עם התנועה, למשל באמצעות Kubernetes Horizontal Pod Autoscaling, ‏ GKE מקצה באופן אוטומטי צמתים חדשים לפודים האלה, ומרחיב באופן אוטומטי את המשאבים בצמתים הקיימים בהתאם לצורך.
  • תזמון: מצב Autopilot מנהל את האריזה של Pods ב-bin בשבילכם, כך שלא צריך לחשוב כמה Pods פועלים בכל צומת. אפשר לשלוט במיקום של ה-Pod באמצעות מנגנונים של Kubernetes כמו affinity ו-Pod spread topology.
  • ניהול משאבים: אם פורסים עומסי עבודה בלי להגדיר ערכי משאבים כמו CPU וזיכרון, מצב Autopilot מגדיר באופן אוטומטי ערכי ברירת מחדל שהוגדרו מראש ומשנה את בקשות המשאבים ברמת עומס העבודה.
  • רשת: כברירת מחדל, Autopilot מפעיל כמה תכונות אבטחה ברשת, כמו העברת כל תעבורת הנתונים ברשת של ה-Pods דרך כללי חומת האש של הענן הפרטי הווירטואלי (VPC), גם אם התעבורה מיועדת ל-Pods אחרים באשכול.
  • ניהול גרסאות: כל אשכולות Autopilot רשומים לערוץ הפצה של GKE, כך שמישור הבקרה והצמתים פועלים בגרסאות המוסמכות העדכניות בערוץ הזה.
  • גמישות מנוהלת: אם לעומסי העבודה שלכם יש דרישות ספציפיות לחומרה או למשאבים, כמו מעבדי GPU, אתם יכולים להגדיר את הדרישות האלה ב-ComputeClasses. כשמבקשים ComputeClass בעומס העבודה, מערכת GKE משתמשת בדרישות כדי להגדיר צמתים בשביל ה-Pods. אין צורך להגדיר חומרה באופן ידני לצמתים או לעומסי עבודה נפרדים.
  • מורכבות תפעולית מופחתת: אוטופיילוט מפחית את התקורה של ניהול הפלטפורמה, כי אין יותר צורך לעקוב באופן רציף אחרי צמתים, פעולות של שינוי גודל ותזמון.

‫Autopilot מגיע עם SLA שכולל גם את רמת הבקרה וגם את יכולת החישוב שמשמשת את ה-Pods.

מידע על פלטפורמת המחשוב שמותאמת לקונטיינרים ב-Autopilot

ב-GKE בגרסה ‎1.32.3-gke.1927002 ואילך,‏ Autopilot כולל פלטפורמת מחשוב מיוחדת שמותאמת לקונטיינרים לעומסי העבודה שלכם. הפלטפורמה הזו מתאימה לרוב עומסי העבודה למטרות כלליות שלא דורשים חומרה ספציפית, כמו שרתי אינטרנט ועבודות אצווה בעוצמה בינונית.

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

פלטפורמת המחשוב שמותאמת לקונטיינרים מספקת את היתרונות הבאים:

  • התאמה של קיבולת מחשוב לעומסי עבודה: מצב Autopilot מתאים באופן דינמי את קיבולת המחשוב של פלטפורמת המחשוב שמותאמת לקונטיינרים, על סמך גורמים כמו מספר ה-Pods וצריכת המשאבים. כתוצאה מכך, קיבולת החישוב באשכול תואמת לצרכים של עומסי העבודה.
  • זמני שינוי גודל מהירים: במהלך אירועי הגדלה, GKE יכול לשנות את הגודל של הצמתים הקיימים באופן דינמי כדי להכיל יותר Pod או צריכת משאבים מוגברת. הקצאת הקיבולת הדינמית הזו לרוב אומרת שאין צורך להמתין עד להפעלת צמתים חדשים כדי להקצות Pods חדשים. אין תמיכה בשינוי הגודל של הצומת בעומסי עבודה של Arm.
  • תמיכה בריבוי ארכיטקטורות: פלטפורמת המחשוב שעברה אופטימיזציה לשימוש עם קונטיינרים תומכת בארכיטקטורות x86 ו-Arm עבור עומסי העבודה למטרות כלליות. כברירת מחדל, עומסי עבודה משתמשים בארכיטקטורת x86. אתם יכולים להריץ עומסי עבודה בפלטפורמת Arm למטרות כלליות על ידי ציון kubernetes.io/arch: arm64בורר הצמתים, או על ידי בחירה ב-ComputeClasses‏ autopilot-arm או autopilot-arm-spot.

אפשר להשתמש בפלטפורמת המחשוב של Autopilot שמותאמת לקונטיינרים בדרכים הבאות:

תמחור

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

  • תצורות Pod של Autopilot לשימוש כללי: הסוגים הבאים של Pod משתמשים במודל חיוב מבוסס-Pod ומסווגים כתצורות Pod לשימוש כללי:

    • ‫Pods שפועלים בפלטפורמת מחשוב שמותאמת לקונטיינרים באשכולות Autopilot או באשכולות Standard.
    • ‫Pods שבוחרים את ComputeClasses המובנים Balanced או Scale-Out באשכולות של Autopilot.

    מידע נוסף זמין בקטע 'עומסי עבודה של Autopilot למטרות כלליות' במחירון של Google Kubernetes Engine.

  • עומסי עבודה ב-Autopilot שבוחרים חומרה ספציפית: פודים שבוחרים חומרה ספציפית, כמו סדרות מכונות של Compute Engine או מאיצי חומרה, משתמשים במודל חיוב מבוסס-צומת. במודל הזה, אתם משלמים על החומרה הבסיסית ועל פרימיום לניהול צמתים.

    למידע נוסף, אפשר לעיין בקטע 'עומסי עבודה של Autopilot שבוחרים חומרה ספציפית' במחירון של Google Kubernetes Engine.

אשכולות ועומסי עבודה ב-Autopilot

ב-GKE אפשר להשתמש במצב Autopilot באשכולות שלמים או בעומסי עבודה ספציפיים באשכולות Standard. אשכולות Autopilot הם הדרך המומלצת להשתמש ב-GKE, כי כל האשכול משתמש בשיטות המומלצות של Google כברירת מחדל.

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

בקטעים הבאים מוסבר איך לתכנן וליצור אשכולות של Autopilot. אם יש לכם אשכול Standard ואתם רוצים להריץ חלק מעומסי העבודה במצב Autopilot, כדאי לעיין במאמר מידע על עומסי עבודה במצב Autopilot ב-GKE Standard.

תכנון אשכולות Autopilot

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

תכננו את המכסות ובקשו אותן עבור Google Cloud הפרויקט או הארגון שלכם בהתאם לגודל עומסי העבודה. מערכת GKE יכולה להקצות תשתית לעומסי העבודה רק אם בפרויקט יש מספיק מכסה לחומרה הזו.

במהלך התכנון, כדאי להביא בחשבון את הגורמים הבאים:

  • הגודל וקנה המידה המשוערים של האשכול
  • סוג עומס העבודה
  • פריסת האשכול ושימוש בו
  • פריסה והגדרה של רשתות
  • תצורת אבטחה
  • ניהול ותחזוקה של אשכולות
  • פריסה וניהול של עומסי עבודה
  • רישום ביומן ומעקב

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

Networking

כשיוצרים אשכול Autopilot עם רשת ציבורית, עומסי העבודה באשכול יכולים לתקשר אחד עם השני ועם האינטרנט. זהו מצב ברירת המחדל של הרשת. Google Cloud ו-Kubernetes מספקים מגוון תכונות ויכולות נוספות של רשת שאפשר להשתמש בהן בהתאם לדרישות, כמו אשכולות עם רשת פרטית.

התחום של רשתות ב-Kubernetes ובסביבת ענן הוא מורכב. לפני שמתחילים לשנות את הגדרות ברירת המחדל שמוגדרות על ידיGoogle Cloud , חשוב להכיר את המושגים הבסיסיים של רשתות. בטבלה הבאה מפורטים מקורות מידע שיעזרו לכם להבין את נושא הרשתות ב-GKE בהתאם לתרחיש השימוש שלכם:

תרחיש שימוש משאבים
הסבר על האופן שבו פועלת רשת ב-Kubernetes וב-GKE

אחרי שמכירים את מודל הרשת, כדאי לשקול את הדרישות של הארגון בנוגע לרשת ולאבטחת הרשת. בוחרים GKE ו Google Cloud תכונות של רשתות שעומדות בקריטריונים האלה.

תכנון של הגדרת הרשת ב-GKE

מומלץ להבין את המכסות של הרשת ב-GKE, כמו נקודות קצה לכל שירות ומגבלות על בקשות API. מקורות המידע הבאים יעזרו לכם לתכנן היבטים ספציפיים של הגדרת הרשת:
חשיפת עומסי העבודה
  • כדי לחשוף את האפליקציות לאינטרנט, משתמשים בServices, שמאפשר לחשוף אפליקציה שפועלת בקבוצת Pod כשירות רשת יחיד.
  • כדי להגדיר עומסי עבודה לתקשורת מאובטחת עם Google Cloud APIs, משתמשים באיחוד זהויות של עומסי עבודה ל-GKE.
הפעלת שירותים מחוברים עם זמינות גבוהה בכמה אשכולות משתמשים בשירותים מרובי-אשכולות (MCS).
איזון עומסים של תנועה נכנסת
הגדרת אבטחת רשת של אשכול
  • כדי לשלוט בגישה לאשכול שלכם מהאינטרנט הציבורי או למנוע אותה, אתם יכולים להתאים אישית את בידוד הרשת customize your network isolation.
  • כדי להגביל את הגישה למישור הבקרה לטווחי כתובות IP ספציפיים, משתמשים ברשתות מורשות של מישור הבקרה.
  • כדי לשלוט בתעבורת הנתונים של Pod, משתמשים בכללי מדיניות רשת. אכיפת מדיניות הרשת זמינה ב-GKE Dataplane V2, שמופעל כברירת מחדל באשכולות Autopilot. הוראות מפורטות מופיעות במאמר בנושא מדיניות רשת.
מעקב אחרי תנועת הרשת ב-Kubernetes

כברירת מחדל, במצב Autopilot נעשה שימוש ב-GKE Dataplane V2 למדדים ולניטור .

התאמה לעומס (scaling)

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

כדאי גם לעיין במכסות והמגבלות של GKE, במיוחד אם אתם מתכננים להריץ אשכולות גדולים עם אלפי Pods.

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

שיטה מומלצת:

כדי לבצע התאמה אוטומטית של מספר ה-Pods באשכול, אפשר להשתמש במנגנון כמו התאמה אופקית של קבוצות Pod לעומס של Kubernetes, שמאפשר לבצע התאמה של מספר ה-Pods על סמך מדדי מעבד וזיכרון מובנים, או על סמך מדדים מותאמים אישית מ-Cloud Monitoring. כדי ללמוד איך להגדיר התאמה לעומס על סמך מדדים שונים, אפשר לעיין במאמר התאמה אופקית של קבוצות Pod לעומס.

אבטחה

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

אם אתם מריצים עומסי עבודה של Autopilot באשכולות Standard,‏ GKE מחיל על עומסי העבודה האלה אמצעי אבטחה שונים של Autopilot, כמיטב יכולתו. אתם יכולים לאכוף באופן מחמיר מדיניות אבטחה ספציפית של Autopilot בכל האשכול הרגיל. אם אוכפים את כל כללי המדיניות הזמינים של Autopilot, אז לאשכול הרגיל יש סביבת הפעלה דומה לאשכול Autopilot.

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

יצירת אשכול

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

אם רוצים ליצור את האשכול ללא גישה לכתובות IP חיצוניות, צריך להגדיר את בידוד הרשת.

פריסת עומסי עבודה במצב אוטומטי

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

אפשר להריץ את עומסי העבודה האלה של Autopilot באחת מהדרכים הבאות:

כדי לקבל הדרכה אינטראקטיבית במסוף Google Cloud על פריסה וחשיפה של אפליקציה באשכול Autopilot, לוחצים על תראו לי איך:

תראו לי איך

בטבלה הבאה מפורטות כמה דרישות נפוצות, ומופיעות המלצות לפעולות שצריך לבצע:

תרחיש שימוש משאבים
שליטה במאפיינים של צמתים בודדים כשמשנים את גודל האשכול יוצרים ComputeClass בהתאמה אישית ומבקשים אותה במניפסט של עומס העבודה. מידע נוסף זמין במאמר בנושא מידע על ComputeClasses בהתאמה אישית.
הרצת עומסי עבודה של Autopilot באשכול סטנדרטי משתמשים ב-ComputeClass של Autopilot באשכול Standard. מידע נוסף זמין במאמר מידע על עומסי עבודה במצב Autopilot ב-GKE Standard.
הרצת עומסי עבודה של Arm לעומסי עבודה לשימוש כללי, אפשר לבקש את ארכיטקטורת Arm ואת ComputeClass המובנה autopilot-arm או autopilot-arm-spot. כדי לעמוד בדרישות חומרה ספציפיות, אפשר לבקש סדרת מכונות עם מעבדי Arm ב-ComputeClass מותאם אישית. מידע נוסף זמין במאמר בנושא מידע על ComputeClasses בהתאמה אישית.
הפעלת עומסי עבודה מואצים של AI/ML שליחת בקשה למעבדי GPU ב-ComputeClass או במניפסט של עומס העבודה. מידע נוסף על בקשת מעבדי GPU במניפסט של עומס העבודה זמין במאמר פריסת עומסי עבודה של GPU ב-Autopilot.
הפעלת עומסי עבודה (workloads) עמידים בכשלים, כמו משימות באצווה, בעלויות נמוכות יותר.

אפשר להשתמש בכל ComputeClass או בכל תצורת חומרה עם Spot Pods.
הפעלת עומסי עבודה שדורשים מינימום שיבושים, כמו שרתי משחקים או תורי עבודה באשכולות של Autopilot בלבד, מציינים את ההערה cluster-autoscaler.kubernetes.io/safe-to-evict=false במפרט ה-Pod. ה-Pods מוגנים מפני הוצאה (eviction) שנגרמת בגלל שדרוגים אוטומטיים של הצמתים או אירועי הקטנה (scale-down) למשך עד שבעה ימים. מידע נוסף זמין במאמר בנושא הארכת זמן הריצה של Autopilot Pods.
לאפשר לעומסי עבודה להשתמש ביותר משאבים מהבקשות שלהם אם יש משאבים זמינים ולא בשימוש בסכום בקשות המשאבים של ה-Pod בצומת. מגדירים את המשאב limits גבוה יותר מהמשאב requests או לא מגדירים מגבלות משאבים. מידע נוסף זמין במאמר בנושא הגדרת Pod bursting ב-GKE.

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

הפרדה בין עומסי עבודה

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

מידע נוסף זמין במאמר הגדרת הפרדה של עומסי עבודה ב-GKE.

תזמון של Pods באזורים ספציפיים באמצעות טופולוגיה אזורית

אם אתם צריכים למקם Pods באזור ספציפי, למשל כדי לגשת למידע בדיסק מתמשך של Compute Engine באזור מסוים, תוכלו להיעזר במאמר מיקום של Pods של GKE באזורים ספציפיים. Google Cloud

זיקה (affinity) ואנטי-זיקה (anti-affinity) של קפסולות

אפשר להשתמש ב-Pod affinity וב-Pod anti-affinity כדי למקם Pods באותו צומת או כדי לגרום ל-Pods מסוימים להימנע מ-Pods אחרים. התכונות Pod affinity ו-Pod anti-affinity אומרות ל-Kubernetes לקבל החלטה לגבי תזמון על סמך התוויות של Pods שפועלים בצמתים בדומיין טופולוגי ספציפי, כמו אזור או אזור ספציפיים. לדוגמה, אפשר להגדיר ל-GKE לא לתזמן Pods של קצה קדמי לצד Pods אחרים של קצה קדמי באותם צמתים, כדי לשפר את הזמינות במקרה של הפסקת חשמל.

להוראות ולפרטים נוספים, קראו את המאמר בנושא זיקה (affinity) ודחייה (anti-affinity) של Pod.

ב-GKE, אפשר להשתמש ב-Pod affinity וב-Pod anti-affinity עם התוויות הבאות ב-topologyKey:

  • topology.kubernetes.io/zone
  • kubernetes.io/hostname

אילוצים של פיזור טופולוגיית Pod

כדי לשפר את הזמינות של עומסי העבודה (workloads) כש-Kubernetes משנה את מספר ה-Pods, אפשר להגדיר אילוצים של פיזור טופולוגיית Pod. ההגדרה הזו קובעת איך Kubernetes מפזר את ה-Pods שלכם על פני צמתים בתוך דומיין טופולוגי, כמו אזור. לדוגמה, אפשר להגדיר ל-Kubernetes להציב מספר מסוים של פודים של סשנים של שרת גיימינג בכל אחד משלושת התחומים (zones) Google Cloud באזור us-central1.

דוגמאות, פרטים נוספים והוראות זמינים במאמר בנושא אילוצי פריסה של טופולוגיית Pod.

שיטה מומלצת:

אם אתם משתמשים ב-topologySpreadConstraints עם שינוי גודל אוטומטי של אשכולות, מומלץ להגדיר את nodeTaintsPolicy: Honor. ההגדרה הזו עוזרת לוודא שהמידרוג האוטומטי באשכול מדמה בצורה נכונה את העברת ה-Pod במהלך אירועי הקטנת המידרוג, וכך מונע לולאות מידרוג פוטנציאליות. בלי ההגדרה הזו, יכול להיות שהמידרוג האוטומטי יקטין את מספר הצמתים באופן שמפר את האילוצים של פיזור הטופולוגיה, מה שיוביל לאירועי הגדלה מיידיים ולשיבוש בעומס העבודה.

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

ניהול של אשכולות Autopilot ומעקב אחריהם

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

שדרוגים של גרסאות GKE

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

GKE מתחיל את השדרוגים באופן אוטומטי, עוקב אחרי ההתקדמות ומשהה את הפעולה אם מתרחשות בעיות. אתם יכולים לשלוט בתהליך השדרוג באופן ידני בדרכים הבאות:

  • כדי לקבוע מתי GKE יכול לבצע שדרוגים אוטומטיים, צריך ליצור חלונות תחזוקה. לדוגמה, אפשר להגדיר את חלון הזמן לתחזוקה ללילה שלפני האיפוס השבועי של משחק מרובה משתתפים, כדי שהשחקנים יוכלו להיכנס למשחק בזמן האיפוס ללא הפרעות.
  • כדי לקבוע מתי GKE לא יכול להתחיל שדרוגים אוטומטיים במהלך טווח זמן מסוים, משתמשים בהחרגות תחזוקה. לדוגמה, אתם יכולים להגדיר החרגה של תחזוקה למשך אירוע המכירות של בלאק פריידיי וסייבר מאנדיי, כדי שהלקוחות יוכלו לקנות בלי בעיות.
  • כדי לקבל גרסה חדשה לפני שהשדרוגים האוטומטיים יתחילו, משדרגים את מישור הבקרה באופן ידני. ‫GKE מתאים את גרסת הצומת לגרסת מישור הבקרה לאורך זמן.
  • כדי לקבל גרסת תיקון שזמינה רק בערוץ הפצה חדש יותר, אפשר לעיין במאמר בנושא הפעלת גרסאות תיקון מערוץ חדש יותר. לדוגמה, יכול להיות שתצטרכו גרסת תיקון ספציפית כדי לצמצם את הסיכון לחשיפה של פגיעות שדווחה לאחרונה.

מעקב אחרי אשכולות Autopilot

בקטרי Autopilot, השירותים Cloud Logging,‏ Cloud Monitoring והשירות המנוהל של Google Cloud ל-Prometheus כבר מופעלים.

אשכולות Autopilot אוספים אוטומטית את סוגי היומנים והמדדים הבאים, בהתאם לשיטות המומלצות של Google לאיסוף טלמטריה:

יומנים של Cloud Logging

  • יומני מערכת
  • יומנים של עומסי עבודה
  • יומני הביקורת Admin Activity
  • יומני הביקורת Data Access

מדדים של Cloud Monitoring

  • מדדי מערכת
  • מדדים של עומסי עבודה (מתוך השירות המנוהל של Google Cloud ל-Prometheus)

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

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

מעקב יעיל אחר ביצועי האשכול יכול לעזור לכם לבצע אופטימיזציה של עלויות התפעול של האשכולות ועומסי העבודה.

  • אפשר להשתמש בלוח הבקרה של GKE ב-Monitoring כדי להציג את הסטטוס של האשכולות. מידע נוסף זמין במאמר בנושא מעקב אחרי אשכולות GKE.
  • פלטפורמת GKE מספקת גם לוח בקרה של יכולת התבוננות במסוף Google Cloud . פרטים נוספים מופיעים במאמר בנושא צפייה במדדי יכולת התבוננות.
מעקב אחר מצב האבטחה של האשכולות אתם יכולים להשתמש בלוח הבקרה של מצב האבטחה כדי לבדוק את עומסי העבודה הפעילים שלכם בהשוואה לשיטות המומלצות של GKE, לסרוק את מערכות ההפעלה של הקונטיינרים ואת חבילות השפה כדי לזהות פגיעויות ולקבל המלצות מעשיות לצמצום הסיכון. מידע נוסף זמין במאמר מידע על לוח הבקרה של מצב האבטחה.

פתרון בעיות

שלבים לפתרון בעיות מפורטים במאמר פתרון בעיות באשכולות של Autopilot.

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