一、kubernetes计划任务Job&CronJob
kubernetes按时间处理调度的工作（类似操作系统的定时任务）
一）Job
Job负责处理任务，即仅执行一次的任务。它保证批处理任务的一个或多个Pod成功结束。
apiVersion: batch/v1
kind: Job
metadata:
labels:
job-name: echo
name: echo
namespace: default
spec:
suspend: true # 1.21+
ttlSecondsAfterFinished: 100 # Job在执行结束之后（状态为completed或Failed）自动清理。设置为0表示执行结束立即删除，不设置则不会清除，需要开启TTLAfterFinished特性
backoffLimit: 4 # 如果任务执行失败，失败多少次后不再执行
completions: 1 # 有多少个Pod执行成功，认为任务是成功的，为空默认和parallelism数值一样
parallelism: 1 # 并行执行任务的数量，如果parallelism数值大于未完成任务数，只会创建未完成的数量；比如completions是4，并发是3，第一次会创建3个Pod执行任务，第二次只会创建一个Pod执行任务
template:
spec:
containers:
- command:
- echo
- Hello, Job
image: registry.cn-beijing.aliyuncs.com/dotbalo/busybox
imagePullPolicy: Always
name: echo
resources: {}
restartPolicy: Never
二）CronJob
CronJob其实就是在Job的基础上加上了时间调度：可以在给定的时间点运行一个任务，也可以周期性地给定时间点运行。（类似Linux操作系统的crontab）
一个CronJob对象其实就对应crontab文件中的一行，它根据配置的时间格式周期性地运行一个Job，格式和crontab也是一样的。
1、crontab的格式如下：
分 小时 日 月 周 要运行的命令
- 第1列分钟(0～59)
- 第2列小时(0～23)
- 第3列日(1～31)
- 第4列月(1～12)
- 第5列星期(0～7)（0和7表示星期天）
- 第6列要运行的命令
2、yaml配置范例
apiVersion: batch/v1beta1 # batch/v1beta1 #1.21+ batch/v1
kind: CronJob
metadata:
labels:
run: hello
name: hello
namespace: default
spec:
concurrencyPolicy: Allow # 并发调度策略。可选参数如下
# Allow：允许同时运行多个任务。
# Forbid：不允许并发运行，如果之前的任务尚未完成，新的任务不会被创建。
# Replace：如果之前的任务尚未完成，新的任务会替换的之前的任务。
failedJobsHistoryLimit: 1 # 保留多少失败的任务
jobTemplate:
metadata:
spec:
template:
metadata:
labels:
run: hello
spec:
containers:
- args:
- /bin/sh
- -c
- date; echo Hello from the Kubernetes cluster
image: registry.cn-beijing.aliyuncs.com/dotbalo/busybox
imagePullPolicy: Always
name: hello
resources: {}
restartPolicy: OnFailure # 重启策略，和Pod一致
securityContext: {}
schedule: '*/1 * * * *' # 调度周期，和Linux一致，分别是分时日月周。
successfulJobsHistoryLimit: 3 # 保留多少已完成的任务，按需配置
suspend: false # 如果设置为true，则暂停后续的任务，默认为false。
二、CronJob、ReplicaSets 的保留策略
一）CronJob的保留策略
1、CronJob的默认保留策略
https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/
Jobs History Limits
The .spec.successfulJobsHistoryLimit and .spec.failedJobsHistoryLimit fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 3 and 1 respectively. Setting a limit to 0
默认情况下，CronJob保留3个成功作业和1个失败作业的历史记录。
2、CronJob自定义保留策略
spec:
successfulJobsHistoryLimit 10 ## 成功job保留历史限制
failedJobsHistoryLimit 0 ## 失败job保留历史限制
二）ReplicaSets 的保留策略
1、ReplicaSets的默认保留策略
https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
ReplicaSets 默认保留10个
Clean up Policy
You can set .spec.revisionHistoryLimit field in a Deployment to specify how many old ReplicaSets for this Deployment you want to retain. The rest will be garbage-collected in the background. By default, it is 10.
Note: Explicitly setting this field to 0, will result in
Revision 和 ReplicaSets 的保留数量一样
Revision History Limit
A Deployment's revision history is stored in the ReplicaSets it controls.
.spec.revisionHistoryLimit is an optional field that specifies the number of old ReplicaSets to retain to allow rollback. These old ReplicaSets consume resources in etcd and crowd the output of kubectl get rs. The configuration of each Deployment revision is stored in its ReplicaSets; therefore, once an old ReplicaSet is deleted, you lose the ability to rollback to that revision of Deployment. By default, 10 old ReplicaSets will be kept, however its ideal value depends on the frequency and stability of new Deployments.
More specifically, setting this field to zero means that all old ReplicaSets with 0 replicas will be cleaned up. In this case, a new Deployment rollout cannot be undone, since its revision history is cleaned up
2、ReplicaSets自定义保留策略
kind:
Deployment
spec:
replicas: 3
revisionHistoryLimit: 5
template:
spec: ...
Deployment 对象有一个字段，叫作spec.revisionHistoryLimit，就是 Kubernetes 为 Deployment 保留的“历史版本”个数。所以，如果把它设置为 0，你就再也不能做回滚操作了。
