Shulou(Shulou.com)06/02 Report--

What is Cron Job?

Cron Job manages time-based Job, that is:

Run only once at a given point in time

Run periodically at a given point in time

A CronJob object is similar to a line in a crontab (cron table) file. It periodically runs a Job according to a specified scheduled schedule

Note: in the scheduled plan, the meaning of the question mark (?) and the asterisk (*) are the same, indicating that the value of the given field is any available value.

Note: ScheduledJob resources were introduced in Kubernetes 1.4, but changed to CronJob since 1.5.

Typical usage is as follows:

Schedule Job to run at a given point in time

Create periodically running Job, such as database backup, sending mail.

prerequisite

When using a Kubernetes cluster, version > = 1.4 (for ScheduledJob), > = 1.5 (for CronJob), when starting API Server (see enabling or closing the API version for the cluster for more information), you can enable batch/v2alpha1 API by passing the option-- runtime-config=batch/v2alpha1=true.

Create Cron Job

Here is an example of Cron Job. It runs a Job every minute, prints out the current time and outputs the greeting hello.

Include code.html language= "yaml" file= "cronjob.yaml" ghlink= "/ docs/concepts/workloads/controllers/cronjob.yaml"}

Download and run the sample Cron Job, and then execute the following command:

$kubectl create-f. / cronjob.yaml cronjob "hello" created

Optionally, create a Cron Job using kubectl run without writing the complete configuration:

Kubectl run hello-- schedule= "* / 1 *"-- restart=OnFailure-- image=busybox-- / bin/sh-c "date; echo Hello from the Kubernetes cluster" cronjob "hello" created

After creating the Cron Job, get its status information with the following command:

$kubectl get cronjob hello NAME SCHEDULE SUSPEND ACTIVE LAST-SCHEDULE hello * / 1 * False 0

As shown above, there is neither a Job for active nor a scheduled Job.

Wait and observe the created Job for about one minute:

$kubectl get jobs-- watch NAME DESIRED SUCCESSFUL AGE hello-4111706356 11 2s

You can now see a Job named hello running. We can stop observing and get the status information of the Job again:

$kubectl get cronjob hello NAME SCHEDULE SUSPEND ACTIVE LAST-SCHEDULE hello * / 1 * False 0 Mon, 29 Aug 2016 14:34:00-0700

You should be able to see that the Job named "hello" is scheduled at the point in time specified by LAST-SCHEDULE. There are currently 0 active (Active) Job, indicating that the Job has been scheduled to run completed or failed.

Now, find the Pod created by the last scheduled Job, and you can see the standard output of one of the Pod. Note that the Job name is different from the Pod name.

# Replace "hello-4111706356" with the job name in your system $pods=$ (kubectl get pods-- selector=job-name=hello-4111706356-- output=jsonpath= {.items.metadata.name}) $echo $pods hello-4111706356-o9qcm $kubectl logs pods Mon Aug 29 21:34:09 UTC 2016 Hello from the Kubernetes cluster delete Cron Job

Once you no longer need Cron Job, you can simply delete it using the kubectl command:

$kubectl delete cronjob hello cronjob "hello" deleted

This will terminate the Job being created. However, running Job will not be terminated and Job or their Pod will not be deleted. To clean up those Job and Pod, you need to list all the Job created by that Cron Job, and then delete them:

$kubectl get jobs NAME DESIRED SUCCESSFUL AGE hello-1201907962 11 11m hello-1202039034 11 8m... $kubectl delete jobs hello-1201907962 hello-1202039034... Job "hello-1201907962" deleted job "hello-1202039034" deleted

Once the Job is deleted, the Pod created by Job is also deleted. Note that all Job created by the Cron Job with the name "hello" is named with the prefix string "hello-". If you want to delete all Job in the current Namespace, you can delete them immediately with the command kubectl delete jobs-- all.

Cron Job restriction

Cron Job probably creates a Job object during each scheduled run time. We say roughly because two Job may be created in a particular environment, or none of the Job may be created. We try to reduce this situation, but we can't avoid it completely. Therefore, the create Job operation should be idempotent.

Based on the parallelism of the Pod it creates, Job is responsible for retrying the creation of the Pod and determining the success or failure of this set of Pod. Cron Job will not check the Pod at all.

Write Cron Job protocol

Like other Kubernetes configurations, Cron Job requires three fields: apiVersion, kind, and metadata. For information on how to implement a configuration file update, refer to the documentation for deploying applications, configuring containers, and using kubectl to manage resources.

Cron Job also requires a .spec section.

Note: all changes to a Cron Job, especially its .spec, will only take effect the next time it is run.

Dispatching

.spec.schedule is a required field in .spec, whose value is a string of Cron format words, such as: 0 *, or @ hourly, which is created and executed according to the specified schedule time.

Job template

.spec.jobTemplate is a required field in another .spec. It is a template for Job. Except that it can be nested and does not have apiVersion or kind fields, it has exactly the same schema as Job. Refer to the preparation of Job specifications.

Duration to start Job (seconds level)

The .spec.startingDeadlineSeconds field is optional. It represents the deadline (in seconds) to start the Job, and if the scheduled time is missed for any reason, the Job that missed the execution time will be considered a failure. If it is not specified, there is no time limit.

Concurrency strategy

The .spec.concurrencyPolicy field is also optional. It specifies how to handle the concurrent execution of the Job created by Cron Job. Only one of the following policies is allowed:

Allow (default): allows Job to run concurrently

Forbid: do not run concurrently. If the previous one is not finished, skip the next one.

Replace: cancel the currently running Job and replace it with a new one

Note that the current policy can only be applied to Job created by the same Cron Job. If there are multiple Cron Job, the Job they create is always allowed to run concurrently.

Suspend

The .spec.fields field is also optional. If set to true, all subsequent execution will be suspended. It has no effect on Job that has already started execution. The default is false.

Job Historical limit

The fields .spec.failfulJobsHistoryLimit and .spec.failedJobsHistoryLimit are optional. They specify a limit on the number of completed and failed Job that can be retained.

There is no limit by default, and all successful and failed Job are retained. However, when you run a Cron Job, it quickly accumulates a lot of Job, and it is recommended that you set the values of these two fields. Set the limit value to 0, and the related types of Job will not be retained after completion.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.