kubernetes计划任务Job&CronJob 和 CronJob、ReplicaSets 的保留策略

kubernetes计划任务Job&CronJob 和 CronJob、ReplicaSets 的保留策略

一、kubernetes计划任务Job&CronJob

kubernetes按时间处理调度的工作（类似操作系统的定时任务）

一）Job

Job负责处理任务，即仅执行一次的任务。它保证批处理任务的一个或多个Pod成功结束。

apiVersion: batch/v1kind: Jobmetadata: labels: job-name: echo name: echo namespace: defaultspec: 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/v1kind: CronJobmetadata: labels: run: hello name: hello namespace: defaultspec: 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的默认保留策略

​​History LimitsThe .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的默认保留策略

​​默认保留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 LimitA 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: Deploymentspec: replicas: 3 revisionHistoryLimit: 5 template: spec: ...

Deployment 对象有一个字段，叫作spec.revisionHistoryLimit，就是 Kubernetes 为 Deployment 保留的“历史版本”个数。所以，如果把它设置为 0，你就再也不能做回滚操作了。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。