‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

משימות Cron

Autopilot Standard

‫CronJobs זמין לכלל המשתמשים (GA) ב-Google Kubernetes Engine (GKE) מגרסה 1.21 ואילך. במאמר הזה מוסבר איך להריץ CronJobs ב-GKE. משימות Cron הן תכונה מובנית של Kubernetes. לפרטים נוספים, קראו את המסמכים של Kubernetes בנושא CronJobs.

סקירה כללית

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

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

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

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

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

מפעילים את ממשק ה-API של Google Kubernetes Engine.

הפעלת Google Kubernetes Engine API

כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז לאתחל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
הערה: אם כבר התקנתם את ה-CLI של gcloud, הקפידו להגדיר את compute/region המאפיין. אם אתם משתמשים בעיקר באשכולות אזוריים, צריך להגדיר את compute/zone במקום זאת. אם מגדירים מיקום ברירת מחדל, אפשר להימנע משגיאות ב-CLI של gcloud כמו השגיאה הבאה: One of [--zone, --region] must be supplied: Please specify location. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

יצירת משימת Cron

אפשר ליצור CronJob באמצעות קובץ מניפסט. לדוגמה, המניפסט הבא של YAML מדפיס את השעה הנוכחית ומחרוזת פעם בדקה, תוך שמירה על ערכי ברירת המחדל של הפרמטרים של CronJob:

# cronjob.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  concurrencyPolicy: Allow
  startingDeadlineSeconds: 100
  suspend: false
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo "Hello, World!"
          restartPolicy: OnFailure

כדי ליצור את ה-CronJob הזה, שומרים את מניפסט ה-YAML בקובץ ומחילים אותו על האשכול:

kubectl apply -f PATH_TO_FILE

מחליפים את PATH_TO_FILE בנתיב למניפסט ה-YAML.

הגדרת CronJob

כשיוצרים CronJob, אפשר לציין את הפרמטרים הבאים:

כשהמשימה CronJob פועלת
מה עושה משימת ה-CronJob
המועד האחרון להפעלת ה-CronJob
האם מותר להפעיל כמה משימות בו-זמנית ב-CronJob
האם משרות חדשות מושעות
כמה הפעלות של CronJob נשמרות בהיסטוריה

הגדרת הזמן שבו משימת ה-Cron תפעל

השדה spec.schedule מגדיר מתי ובאיזו תדירות יופעל CronJob, באמצעות פורמט crontab סטנדרטי של Unix. כל השעות ב-CronJob הן לפי שעון UTC. יש חמישה שדות, שמופרדים באמצעות רווחים. השדות האלה מייצגים את הדברים הבאים:

דקות (בין 0 ל-59)
שעות (בין 0 ל-23)
היום בחודש (בין 1 ל-31)
חודש (בין 1 ל-12)
יום בשבוע (בין 0 ל-6, החל מיום ראשון)

אפשר להשתמש בתווים המיוחדים הבאים בכל אחד מהשדות של spec.schedule:

‫? הוא ערך כללי שמתאים לתו בודד.
‫* הוא ערך כללי שמתאים לאפס תווים או יותר.
/ מאפשר לציין מרווח לשדה. לדוגמה, אם השדה הראשון (השדה של הדקות) מכיל את הערך */5, המשמעות היא "כל 5 דקות". אם השדה החמישי (השדה של היום בשבוע) מוגדר לערך 0/5, המשמעות היא "כל יום ראשון החמישי".

הגדרת הפעולות שמשימת ה-Cron תבצע

הקובץ spec.jobTemplate מתאר מה עושה CronJob, כולל תמונות הקונטיינר שלו, הפקודות שהקונטיינרים מבצעים ומדיניות ההפעלה מחדש של CronJob. פרטים נוספים על מה צריך לכלול ב-spec.jobTemplate זמינים במסמכי התיעוד של Kubernetes CronJob.

ציון מועד אחרון

השדה האופציונלי startingDeadlineSeconds מציין את מספר השניות המקסימלי שנדרש ל-CronJob כדי להתחיל אם הוא פספס את הזמן המתוזמן שלו מסיבה כלשהי. משימות Cron שלא בוצעו נחשבות ככישלונות.

כדי לציין מועד אחרון, מוסיפים את הערך startingDeadlineSeconds לשדה spec של CronJob בקובץ המניפסט. לדוגמה, במניפסט הבא מצוין של-CronJob יש 100 שניות להתחיל:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  startingDeadlineSeconds: 100
  jobTemplate:
    spec:
    ...

ציון מדיניות מקבילות

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

‫concurrencyPolicy מקבל את הערכים הבאים:

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

השעיה של הרצות עוקבות

השדה האופציונלי spec.suspend, כשהוא מוגדר כ-true, מונע הפעלה של משימות חדשות, אבל מאפשר להשלים את ההפעלות הנוכחיות.

ציון מגבלות על ההיסטוריה

משימת Cron יוצרת Pod בכל פעם שהיא מופעלת. במאמר הצגת ההיסטוריה של CronJob מוסבר איך לראות את סטטוס הסיום של ההפעלות האחרונות של CronJob, וגם את היומנים של Pod מסוים.

כדי להגדיר את מספר ההפעלות המוצלחות והנכשלות של CronJob שנשמרות, מציינים ערכים ל-spec.successfulJobsHistoryLimit ול-spec.failedJobsHistoryLimit. כברירת מחדל, הערך של successfulJobsHistoryLimit הוא 3 והערך של failedJobsHistoryLimit הוא 1.

לדוגמה, המניפסט הבא מורה ל-GKE לשמור עד חמש הפעלות מוצלחות של CronJob ועד 10 הפעלות שנכשלו של CronJob:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  startingDeadlineSeconds: 100
  successfulJobsHistoryLimit: 5
  failedJobsHistoryLimit: 10
  jobTemplate:
    spec:
    ...

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

kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  startingDeadlineSeconds: 100
  successfulJobsHistoryLimit: 0
  failedJobsHistoryLimit: 10
  jobTemplate:
    spec:
    ...

בדיקה של משימת Cron

כדי לבדוק את ההגדרה של משימת Cron, משתמשים בפקודה kubectl describe:

kubectl describe cronjob CRONJOB_NAME

מחליפים את CRONJOB_NAME בשם של CronJob שרוצים לבדוק.

הצגת ההיסטוריה של CronJob

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

כדי לראות את ההיסטוריה של CronJob, קודם צריך להציג רשימה של כל ה-Pods. משימות Cron שהושלמו מוצגות עם הסטטוס Completed, ומשימות שנכשלו מוצגות עם הסטטוס RunContainerError,‏ CrashLoopBackOff או סטטוס אחר שמציין כישלון.

NAME                                READY   STATUS              RESTARTS   AGE
hello-1556555640-9bc5r              0/1     Completed           0          3m6s
hello-1556555700-cm6wk              0/1     Completed           0          2m6s
hello-1556555760-62wf5              0/1     Completed           0          66s
hello-1556555820-rl8kl              0/1     Completed           0          5s
hello-failed-1556555820-wrvt2       0/1     RunContainerError   1          5s

אפשר לגרום למשימה להיכשל בכוונה על ידי שינוי מניפסט לדוגמה במאמר יצירת משימת Cron. משנים את השדה args ב-spec.containers לפקודה לא חוקית או לנתיב שלא קיים, ומשנים את הערך של metadata.name לערך שמציין שאתם בודקים אם יש כשלים.

כדי לראות את היומנים של CronJob ספציפי, מריצים את הפקודה הבאה:

kubectl logs POD_NAME

מחליפים את POD_NAME בשם של ה-Pod שרוצים לבדוק.

הפלט אמור להיראות כך:

container_linux.go:247: starting container process caused
"exec: \"/in/sh\": stat /in/sh: no such file or directory"

מחיקת משימת Cron

כדי למחוק CronJob, מריצים את הפקודה הבאה:

kubectl delete cronjob CRONJOB_NAME

כשמוחקים CronJob, כלי איסוף הגרוטאות של Kubernetes מוחק את המשימות המשויכות ומונע את ההתחלה של משימות חדשות.

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

אפשר לקרוא את מאמרי העזרה של Kubernetes בנושא CronJobs.
איך מריצים משימה חד-פעמית