K8s實做cronjob
2022/10/29
Cronjob
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
此設定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
成功執行完Job的Pod保留數量
可保留用來後續查詢log用
預設為1
startingDeadlineSeconds
這個功能為optional
若設定這個功能
本來應該被啟動執行的cronjob因為任何原因沒被執行
超過startingDeadlineSeconds設定的秒數
將會被列為失敗的cronjob
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
短時間一直開開關關也是很耗機器資源