Cronjob

ref

k8s本身有提供cronjob元件

可以實做排程任務

而Cronjob在設定的時候就是以Pod為單位(可參考下方範例)

所以"每次"執行Cronjob的時候

k8s都會啟動一個新的Pod來執行

Cronjob設定檔

範例

以下範例為每分鐘使用curl對slack webhook發一個Hello World訊息

apiVersion: batch/v1
kind: CronJob
metadata:
  name: test-job
spec:
  # cron expression
  schedule: "* * * * *"
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 3
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: Never
          containers:
            - name: cron-job
              image: node:14-alpine
              imagePullPolicy: Always
              command:
                - /bin/sh
                - -c
                - "curl -X POST -H 'Content-type: application/json' --data '{\"text\":\"Hello, World!\"}' https://hooks.slack.com/services/foobar"

schedule

標準cron expression

concurrencyPolicy

spec.concurrencyPolicy

此設定cron job併發狀況的處理設定

若cron job執行頻率較高且每次執行時間較長

在執行新的Job的時候可能會遇到舊的Job還沒執行完出現併發的狀況

k8s提供三種選項

Allow: 允許併發
Forbid: 禁止併發, 若新的job要開始執行前, 舊的job還未執行結束, 這時候新的job會被跳過不執行
Replace: 取代, 若新的job要開始執行的時候, 舊的job還未執行結束, 這時候舊的job將會被移除直接用新的job取代

successfulJobsHistoryLimit

spec.successfulJobsHistoryLimit

成功執行完Job的Pod保留數量

可保留用來後續查詢log用

預設為3

failedJobsHistoryLimit

spec.failedJobsHistoryLimit

成功執行完Job的Pod保留數量

可保留用來後續查詢log用

預設為1

startingDeadlineSeconds

spec.startingDeadlineSeconds

這個功能為optional

若設定這個功能

本來應該被啟動執行的cronjob因為任何原因沒被執行

超過startingDeadlineSeconds設定的秒數

將會被列為失敗的cronjob

suspend

spec.suspend

當這個值被設定為true

k8s將會暫停cronjob

注意事項

若suspend重新被設定為false(重新啟動cronjob)

而且在沒有設定startingDeadlineSeconds的情況下

在過去暫停時間內本來應該被執行的cronjob將會立即被執行

執行

直接使用kubectl apply -f指定cronjob設定檔即可設定cronjob

Debug

透過kubectl logs指令可查看cron job pod的log

kubectl logs [cron-job-pod-name]

總結

Cronjob雖然使用起來很方便

但如果Cronjob執行頻率太高就不太適合使用k8s的cronjob

畢竟每次執行一此cronjob都會開一個pod啟動新的container

短時間一直開開關關也是很耗機器資源

K8s實做cronjob