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

צריך להכין את האפליקציות שפועלות באשכולות Google Kubernetes Engine‏ (GKE) להפרעות כמו שדרוגי צמתים ואירועי תחזוקה אחרים. אפליקציות עם מצב (Stateful), שלעתים קרובות צריכות זמן כדי להפסיק את פעולות הקלט/פלט בצורה נקייה ולבטל את הניתוק מהאחסון, פגיעות במיוחד לשיבושים. כדי לשמור על זמינות האפליקציות במהלך השדרוגים, אפשר להשתמש בתכונות של Kubernetes כמו Pod Disruption Budgets (תקציבים להפרעות ב-Pods) וReadiness Probes (בדיקות מוכנות).

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

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

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

זיהוי עומסי עבודה (workload) שפגיעים לשיבושים

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

כש-GKE מזהה עומסי עבודה עם פגיעות לשיבוש

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

סוג משנה של תובנה תיאור פעולה
PDB_UNPROTECTED_STATEFULSET התראות אם קיים StatefulSet שבו אף אחת מהתוויות הקיימות של PDB לא תואמת לתוויות של בורר ה-Pod של StatefulSet. כלומר, אפשר להשבית את כל ה-Pods ב-StatefulSet במהלך אירוע כמו שדרוג של צומת. מוסיפים PDB שהתוויות שלו תואמות לאלה שבשדה של בורר ה-Pod של StatefulSet. ב-PDB הזה מציינים את מידת ההפרעה ש-StatefulSet יכול לסבול. ההמלצה שמשויכת לתובנה הזו מציעה אילו תוויות צריך להגדיר ב-PDB כדי לכסות את ה-StatefulSet שצוין.
PDB_UNPERMISSIVE התראות כשאי אפשר להקפיד על PDB שתואם ל-Pod בפעילויות תחזוקה כלשהן, כמו שדרוג צומת. ב-PDB צריך לאפשר שיבוש של לפחות Pod אחד, ולכן GKE מפר את ה-PDB הזה לצורך תחזוקה נדרשת אחרי שעה. משנים את ההגדרה minAvailable של ה-PDB כך שתהיה קטנה ממספר הפודים הכולל, או משנים את ההגדרה maxUnavailable כך שתהיה גדולה מאפס.
PDB_STATEFULSET_WITHOUT_PROBES התראות כשמגדירים StatefulSet עם PDB אבל בלי בדיקות מוכנות, כך שה-PDB לא יעיל במדידת מוכנות האפליקציה. ה-PDBs מתחשבים בבדיקות המוכנות כשהם בודקים אילו Pods אפשר לספור כ-Pods תקינים. לכן, אם לא מוגדרת בדיקת מוכנות ל-Pod שכלול ב-PDB, ל-PDB יש יכולת מוגבלת לדעת אם ה-Pod תקין או שהוא רק פועל. מוסיפים בדיקות מוכנות ל-Pods ב-StatefulSets עבור ה-PDB שמוזכר בתובנה. מומלץ גם להוסיף בדיקות פעילות.
DEPLOYMENT_MISSING_PDB התראות כשפריסת Deployment קיימת עם סלקטור Pod שלא תואם ל-PDB קיים וגם בפריסת ה-Deployment יש יותר מרפליקה אחת או שהופעלה בה התאמה אופקית של קבוצות Pod לעומס. המשמעות היא שכל ה-Pods ב-Deployment יכולים להיות מושבתים במהלך אירוע כמו שדרוג של צומת. מוסיפים PDB שהתוויות שלו תואמות לתוויות בשדה של סלקטור ה-Pod בפריסה. ב-PDB הזה מציינים את רמת ההפרעה שהפריסה יכולה לסבול. ההמלצה שמשויכת לתובנה הזו מציעה אילו תוויות צריך להגדיר ב-PDB כדי לכסות את הפריסה שצוינה.

הטמעה של ההנחיות לשיפור המוכנות לשיבושים

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

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

אם אתם לא רוצים ליישם את ההמלצה, אתם יכולים להסיר אותה.

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