הארכת זמן הריצה של Autopilot Pods

בדף הזה מוסבר איך לבקש זמן ריצה ממושך יותר ל-Pods לפני שהם מוצאים מ-Google Kubernetes Engine‏ (GKE).

מידע על פינוי של Pod שמתבצע על ידי GKE

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

ל-Kubernetes יש תכונות מובנות שקונטיינרים יכולים להשתמש בהן כדי לטפל בהוצאות בצורה תקינה, כמו PodDisruptionBudgets וgraceful termination periods. עם זאת, יש עומסי עבודה מסוימים, כמו תורים של משימות באצ' או שרתים של משחקים מרובי משתתפים, שצריכים לפעול למשך זמן ארוך יותר לפני שהם מופסקים. תקופת החסד שמוגדרת כברירת מחדל ב-GKE במהלך פינויים שמתבצעים על ידי GKE, עשויה שלא להספיק לעומסי העבודה האלה. במצבים כאלה, אפשר להגדיר ל-Autopilot שלא יסיר עומסי עבודה ספציפיים למשך עד 7 ימים.

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

תרחישים לדוגמה

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

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

תמחור

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

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

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

לפני שמתחילים

לפני שמתחילים, חשוב לוודא שביצעתם את הפעולות הבאות:

  • מפעילים את ממשק ה-API של Google Kubernetes Engine.
    • הפעלת Google Kubernetes Engine API
  • אם רוצים להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
  • מוודאים שיש לכם אשכול GKE קיים.

מגבלות

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

בקשה להארכת משך ההפעלה

כדי לבקש זמן ריצה ממושך יותר לקבוצת Pod, צריך להגדיר את ההערה cluster-autoscaler.kubernetes.io/safe-to-evict של Kubernetes לערך false במפרט של קבוצת ה-Pod.

  1. שומרים את קובץ המניפסט הבא בשם extended-deployment.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: extended-pods
  labels:
    duration: extended
spec:
  selector:
    matchLabels:
      duration: extended
  template:
    metadata:
      annotations:
        cluster-autoscaler.kubernetes.io/safe-to-evict: "false"
      labels:
        duration: extended
    spec:
      containers:
      - name: example-container
        image: registry.k8s.io/pause
        resources:
          requests:
            cpu: 200m

  2. יוצרים את הפריסה:

    kubectl create -f extended-deployment.yaml

ה-Pods ממשיכים לפעול במשך 7 ימים לפחות לפני שמתבצעת הקטנת הקיבולת או שדרוג אוטומטי של הצומת.

שיקולים והמלצות

כשמשתמשים בפונקציונליות הזו, חשוב לקחת בחשבון את הנקודות הבאות:

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

  • יכול להיות ש-Pods עם משך זמן ממושך עדיין יסולקו מוקדם מהצפוי במצבים הבאים:

  • אפשר להשתמש בהערה cluster-autoscaler.kubernetes.io/safe-to-evict באשכולות רגילים, אבל התוצאה לא תהיה זהה. הפודים פועלים ללא הגבלת זמן גם אם מתרחש אירוע של הקטנת קנה מידה, ולכן לא מתבצעת מחיקה של צמתים שלא נעשה בהם שימוש מספיק, ואתם ממשיכים לשלם על הצמתים האלה. בנוסף, פודים לא מוגנים מפני הוצאה משימוש שנגרמת משדרוגים אוטומטיים של צמתים.

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