סקירה כללית על 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 בסביבות שבהן אתם עדיין צריכים שליטה ידנית בתשתית. מידע נוסף זמין במאמר מידע על עומסי עבודה במצב Autopilot ב-GKE Standard.

יתרונות

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

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

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

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

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

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

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

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

  • אשכולות Autopilot: פודים שלא בוחרים חומרה ספציפית משתמשים בפלטפורמת המחשוב הזו כברירת מחדל.
  • אשכולות רגילים: אפשר להציב Pods ספציפיים בפלטפורמת המחשוב שעברה אופטימיזציה לקונטיינרים על ידי בחירה באחת מה-ComputeClasses המובנות של 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 מקצה ומנהל את התשתית המתאימה להרצת עומסי העבודה האלה. לדוגמה, אם מריצים עומסי עבודה של למידת מכונה, צריך לבקש מאיצי חומרה. אם אתם מפתחים אפליקציות ל-Android, אתם יכולים לבקש מעבדי Arm.

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

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

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

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

Networking

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

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

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

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

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

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

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

התאמה להיקף

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

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

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

שיטה מומלצת:

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

אבטחה

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

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

יצירת אשכול

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

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

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

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

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

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

תראו לי איך

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

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

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

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

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

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

אם אתם צריכים למקם Pods באזור ספציפי, למשל כדי לגשת למידע בדיסק אחסון מתמיד (persistent disk) של Compute Engine באזור מסוים, תוכלו לעיין במאמר בנושא מיקום של Pods של GKE באזורים ספציפיים. Google Cloud

זיקה (affinity) ואנטי-זיקה (anti-affinity) של Pod

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

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

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

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

מגבלות על פיזור טופולוגיית ה-Pod

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

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

שיטה מומלצת:

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

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

ניהול של אשכולות 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.

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