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

בדף הזה מוסבר איך לבקש הארכה של זמן הריצה של Pod לפני שהוא מפונה על ידי Google Kubernetes Engine‏ (GKE).

מידע על פינוי Pods ביוזמת GKE

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

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

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

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

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

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

תמחור

אתם יכולים לבקש להאריך את זמן הריצה של ה-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 inter-Pod affinity בפודים עם משך זמן מורחב.
  • בכל פעם שאפשר, GKE ממקם כל Pod עם זמן ריצה מורחב בצומת משלו. ההתנהגות הזו עוזרת להבטיח שאפשר לצמצם אנכית את קנה המידה של הצמתים אם לא נעשה בהם שימוש מספיק.
  • אי אפשר לבקש הארכה של זמן הריצה של Pods שמטרגטים מחלקות מחשוב בהתאמה אישית.

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

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

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

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

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