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

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

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

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

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

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

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

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

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

תמחור

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

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

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

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

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

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

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

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

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