סקירה כללית על 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 מפשט את תחזיות החיוב והשיוך.
• ניהול צמתים: Google מנהלת את צמתי העובדים, כך שלא צריך ליצור צמתים חדשים כדי להתאים לעומסי העבודה או להגדיר שדרוגים ותיקונים אוטומטיים.
• שינוי גודל: כשעומסי העבודה חווים עומס גבוה ומוסיפים עוד Pod כדי להתמודד עם התנועה, למשל באמצעות Kubernetes Horizontal Pod Autoscaling, ‏ GKE מקצה באופן אוטומטי צמתים חדשים ל-Pods האלה, ומרחיב באופן אוטומטי את המשאבים בצמתים הקיימים בהתאם לצורך.
• תזמון: במצב Autopilot, המערכת מנהלת את האריזה של ה-Pods, כך שלא צריך לחשוב על מספר ה-Pods שפועלים בכל צומת. אפשר לשלוט במיקום של ה-Pod באמצעות מנגנונים של Kubernetes כמו affinity ו-Pod spread topology.
• ניהול משאבים: אם פורסים עומסי עבודה בלי להגדיר ערכי משאבים כמו CPU וזיכרון, מצב Autopilot מגדיר באופן אוטומטי ערכי ברירת מחדל שהוגדרו מראש ומשנה את בקשות המשאבים ברמת עומס העבודה.
• רשת: במצב Autopilot, חלק מתכונות האבטחה של הרשת מופעלות כברירת מחדל, למשל העברת כל תעבורת הנתונים ברשת של ה-Pods דרך כללי חומת האש של הענן הפרטי הווירטואלי (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 חדשים.
• תמיכה בריבוי ארכיטקטורות: פלטפורמת המחשוב שעברה אופטימיזציה לשימוש בקונטיינרים תומכת בארכיטקטורות x86 ו-Arm עבור עומסי העבודה למטרות כלליות, באמצעות ComputeClasses כמו autopilot ו-autopilot-arm, בהתאמה. כברירת מחדל, עומסי עבודה משתמשים בארכיטקטורת x86.

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

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

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

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

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

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

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

Networking

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

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

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

התאמה להיקף

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

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

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

שיטה מומלצת:

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

אבטחה

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

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

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

יצירת אשכול

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

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

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

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

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

• פריסת עומסי העבודה באשכול Autopilot.
• בוחרים ComputeClass של Autopilot כשפורסים את עומסי העבודה באשכול רגיל.

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

תראו לי איך

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

תרחיש שימוש	משאבים
שליטה במאפיינים של צומת בודד כשמשנים את גודל האשכול	יוצרים ComputeClass בהתאמה אישית ומבקשים אותה במניפסט של עומס העבודה. מידע נוסף זמין במאמר בנושא מידע על ComputeClasses בהתאמה אישית.
הרצת עומסי עבודה במצב Autopilot באשכול רגיל	משתמשים ב-ComputeClass במצב Autopilot באשכול Standard. מידע נוסף זמין במאמר מידע על עומסי עבודה במצב Autopilot ב-GKE Standard.
הרצת עומסי עבודה של Arm	לעומסי עבודה לשימוש כללי, אפשר לבקש את ארכיטקטורת Arm ואת autopilot-arm ComputeClass המובנה. כדי לעמוד בדרישות חומרה ספציפיות, אפשר לבקש סדרת מכונות עם מעבדי Arm ב-ComputeClass מותאם אישית. מידע נוסף זמין במאמר בנושא מידע על ComputeClasses בהתאמה אישית.
הפעלת עומסי עבודה מואצים של AI/ML	שליחת בקשה למעבדי GPU ב-ComputeClass או במניפסט של עומס העבודה. מידע נוסף על בקשת מעבדי GPU במניפסט של עומס העבודה זמין במאמר פריסת עומסי עבודה של GPU ב-Autopilot.
הפעלת עומסי עבודה (workloads) עמידים בכשלים, כמו משימות באצווה, בעלויות נמוכות יותר.	שימוש ב-autopilot-spot ComputeClass המובנה. הגדרת מכונות וירטואליות מסוג Spot ב-ComputeClass בהתאמה אישית. בוחרים Spot Pods במניפסט של עומס העבודה. אפשר להשתמש בכל 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 באזורים ספציפיים. Cloud de Confiance

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

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

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

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

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

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

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

פתרון בעיות

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

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

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