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

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

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

מה זה Autopilot?

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

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

יתרונות

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

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

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

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

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

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

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

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

תמחור

התמחור של Autopilot משתמש במודלים שונים בהתאם לסוג החומרה שבה משתמשים הפודים, באופן הבא:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Networking

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

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

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

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

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

מומלץ להבין את המכסות של GKE בנושא רשתות, כמו נקודות קצה לכל שירות ומגבלות על בקשות API. מקורות המידע הבאים יעזרו לכם לתכנן היבטים ספציפיים של הגדרת הרשת:
חשיפת עומסי העבודה (workloads)
  • כדי לחשוף את האפליקציות לאינטרנט, משתמשים בשירותים, שמאפשרים לחשוף אפליקציה שפועלת בקבוצת Pods כשירות רשת יחיד.
  • כדי להגדיר עומסי עבודה לתקשורת מאובטחת עם ממשקי ה-API של Google Cloud , צריך להשתמש באיחוד זהויות של עומסי עבודה ל-GKE.
הפעלת שירותים מקושרים בזמינות גבוהה בכמה אשכולות משתמשים בשירותים מרובי-אשכולות (MCS).
איזון עומסים של תנועה נכנסת
הגדרת אבטחת הרשת של האשכול
מעקב אחרי התנועה ברשת של Kubernetes

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

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

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

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

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

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

שיטה מומלצת:

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

אבטחה

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

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

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

יצירת אשכול

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

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

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

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

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

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

תראו לי איך

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

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

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

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

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

למידע נוסף, קראו את המאמר הגדרת הפרדת עומסי עבודה ב-GKE.

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

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

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

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

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

ב-GKE, אפשר להשתמש בקרבה ובחוסר קרבה של Pod עם התוויות הבאות ב-topologyKey:

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

אילוצי פריסה של טופולוגיית Pod

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

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

שיטה מומלצת:

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

ההגדרה 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 ואיך לגשת אליהם
  • במאמר אילו יומנים נאספים מוסבר על סוגי היומנים שאנחנו אוספים באופן אוטומטי.
  • כדי לגשת ליומנים ולהשתמש בממשק המשתמש של Cloud Logging במסוף Google Cloud , קראו את המאמר הצגת יומני GKE.
  • במאמר שאילתות שקשורות ל-Kubernetes תוכלו למצוא שאילתות לדוגמה שאפשר להשתמש בהן כדי לסנן את יומני המערכת ועומסי העבודה של Kubernetes.
  • במאמר מידע על רישום ביומן ביקורת של GKE תוכלו למצוא שאילתות לדוגמה שאפשר להשתמש בהן כדי לסנן את יומני הביקורת של פעילות אדמין ושל גישה לנתונים.
  • כדי להגדיר יומנים לסביבות עם כמה דיירים, למשל כשלצוותים יש מרחבי שמות ספציפיים באשכול GKE אחד, אבל לכל צוות יש פרויקט Google Cloud משלו, קראו את המאמר רישום ביומן של כמה דיירים ב-GKE.
מעקב אחרי הביצועים של אשכולות GKE

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

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

פתרון בעיות

כדי לפתור בעיות, אפשר לעיין במאמר פתרון בעיות באשכולות Autopilot.

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